Andy Milk Interactive

In client services, it’s often beneficial just to get something DONE, and worry about the details later.  I’ve worked with many developers in the past who have hemmed and hawed over the details, documented everything from top to bottom, and delayed in getting something done.

While I do think you should approach any task, fix, upgrade, update, or feature request with a slow, steady, and calcuated pace, you shouldn’t run into analysis paralysis or what I’m just coining now as CompSci Incompetence.  No offense to programmers with multiple degrees from prestigious universities, or engineering consulting backgrounds, but often times the Scientific Method approach to programming can really piss of clients.  That’s mostly because of the time it takes to gather requirements, analyze the system, design a solution, code, test, deploy, review, etc.

Most of my clients need things done immediately when they send a request.  Aside from monetary transactional, senstive security-related, or iron clad brand requirements, I often times will take the most direct and fast path to completion.  If some small details fall through the cracks, they can be fixed soon after deployment, and the errors will likely only be seen by 1% of the viewing audience (or my client), while 99% saw SOMETHING rather than waited for it to be perfect.

Again, quality is very important and this shouldn’t be an excuse to be sloppy, hasty, or to ignore details.  But it ALWAYS makes clients happy to say, “DONE!” and the caveat that there a few things to tweak post-launch or post-deployment.  Sometimes you even get lucky and there’s nothing else to do post-launch.

Too many documents, too many emails, and too much analysis can be like molasses in a Nor’easter.  (it’s snowing in Boston as I write)