Here’s a thought model that might help you get a better feel for how I understand and evaluate complexity. If you ever find yourself worrying that you might understand your business so well that it’s hard to explain to others, this might also put those concerns to rest.

I hope I don’t offend anyone by posting this. I think it’s small enough that you can’t really make out the details anyway.

This is an example of a real database. Let’s suppose it’s your web site.

This is what we call existing code. Someone else has written it; someone else thought it through; it makes sense to someone else, but that person it’s around anymore. You’ve just hired me. Understandably, you want to be impressed with great price, great speed, and great quality. You want to be wowed. But what is great value? Our definitions of “wow” will be very different if I see complexity differently.

The human brain has surprisingly strict limitations on the amount of information it can process, and there is very little variation between “smart” people and “stupid” people. While raw memory may not vary that much, problem solving approaches vary greatly. Not all men are created equal where complexity is approached, contained, and processed.

I know how to handle complexity. Sometimes it can be ignored, sometimes it can’t. For example, if I know a certain task is going to land me squarely in the middle of this database, I will be reluctant to avoid understanding the database up front. If I’m creating something for you that never touches this database, I’m more likely to be comfortable advising you that it’s okay to ignore it and move forward at full speed. I understand the danger of over-simplifying something that is obviously complex but not yet understood. You need someone who knows the difference.

Let’s suppose you know your business well, and you think this database makes perfect sense. I, being new, will certainly disagree. Where do we go from here? Our choices are not great:

A) Make risky choices for a temporary wow effect

B) Take the time to really understand what is going on, and forego any hope of an immediate wow

These aren’t great choices. A is no good for me, and B is no good for you.

At the end of the day, I may need to pass on this project. Part of my job is to provide you with the necessary and consistent resistance required for you to make good, informed choices. You can’t do that with someone who resists but eventually caves in their supposed area of expertise. What if your heart had a pinhole rupture, and you knew it? And what if you found a doctor who correctly diagnosed it? Now – and imagine with me here – what if you were able to talk the doctor out of his diagnosis? You could never trust that man. He’s not confident enough in his talent.

This database diagram came from a real client. I truly believe that the client understands the complexity, and I think he knows that there is no shortcut. But he’s searching for one anyway. My job is to withstand the test.

I’ll let you know how it goes :)

 

Just like the pre-checks, I also have post-checks to ensure quality. Here they are:

Layout

  • Margins/padding match comp
  • Liquid layout does not introduce gaps on resize
  • Capitalization matches comp
  • Text styling matches comp
  • Coloring matches comp
  • Text leading matches comp
  • Proportions and relative sizes match comp
  • Indentical or downlevel rendering in FF3, Safari, IE7, IE6
  • Navigation does not wrap in small liquid layout
  • Status bar features do not wrap in small liquid layout
  • Links do not wrap in small liquid layout
  • Headings/headers do not wrap in small liquid layout
  • No hard-coded duplicate CSS in views
  • CSS definition blocks are in external files
  • JS functions are included via external links

Wireup

  • All db operations incorporate user id or role in WHERE
  • No input params are trusted to directly control privileged operation
  • Front end is not trusted for security checks
  • JavaScript/Ajax and downlevel compatibility in FF3, Safari, IE7, IE6
  • FireBug console statements are not present or console() function is overridden in case it is not present
  • Database tables, pks, and fks follow mvc-style conventions
  • File uploads stored on disk with UUID referencing database table holding MIME type, original name, posting date, disk file name, and user ID if needed
  • Thumbnails generated dynamically
  • View helpers used where possible
  • Database FK’s indexed
  • No off-screen validation failures are possible
  • Transactions are used only if user’s current work can be restored to the screen upon transaction rollback
  • RESTful routing used
  • Route helpers used for all RESTful paths
  • No hard-coded <a> tags for site paths
  • All calculations in models – none in view or controller
  • Form helpers are used instead of <form> tag
    document.getElementById() is $()

  • Paths to root and core are constants and not hard coded
  • JS functions are included via external links
  • Raw $_REQUEST not used ($params) instead
  • No raw <input> fields
  • No magic values in code
  • File paths refactored and DRY’d into constants
  • TIMESTAMP type not used
  • DATETIME defaults to null if you want it to auto-populate
© 2011 Ben Allfree :: Painless Programming