Booleangate

Whether it’s an internal or external project, for coworkers or clients, the trap of being the boy who cried “wolf”, or in this case, the developer who cried “done,” is an easy one to fall into. The issue here, besides an elongated development time, is that this trap cuts at our credibility as programmers, even—and especially—when the circumstances are out of our hands. If you say it’s done, it’d damn well better be done. So, to avoid such an incredulous rap, try following these steps to make sure that projects actually get completed on time, the first time.

Understanding the problem

To solve any problem, you must first understand the problem. As programmers, we should all know this, as it is our business to solve problems. However, it’s not always clear to the client or coworker what their problem really is (although I’m sure we can point out a few). In order to finish something once, and to avoid that ridiculous state of being finished finishing, it’s important to have a solid understanding of the problem, and to be able to answer the “Five What’s.”

• What’s the goal
• What’s needed
• What’s not needed
• What can be done with other, existing solutions
• What does the client/coworker expect

First off, what’s the goal? This is deceptively simple, and answers that smack like, “to make a website,” are just begging the question. “To make a website to increase company exposure and generate sales from the Internet market,” is a real answer, and the type we’re after. Be sure to get at specifics, as that is what this whole exercise is about.

Second and thirdly, what is and what is not needed? If the goal of making said website is to drive sales and increase exposure, things like a solid SEO campaign and a web store are needed. But what about a neat-o staff section? That depends on the company and their product. How about customer tracking for Internet sales? I would say so. A contact form? Most definitely. Weather widgets? Bite me. Be realistic with each feature requested. Is it practical and useful, will it be used more than once, will anyone that’s not a local customer “get it” (i.e.: beware of gimmicks), is it worth the time to develop? These are the types of questions that you should ask yourself and your client/coworker when determining the project’s feature-set.

And what about what can be done with other, existing solutions? Don’t forget that there are a lot of out-of-the-box solutions for a wicked variety of things. However, if it will take away from your paycheck and the client can afford it, then as long as it meets the due date, I wholeheartedly encourage your to reinvent the wheel, the pencil, and to make better spatulas until the cows come home. But, for example, if you’re working on some internal project, chances are there may already be another tool that does just what your coworker is asking for. Use it, modify it if necessary, and spend your time doing things that actually need to get done (like reading reddit).

Lastly, what does the client/coworker expect? This “what” leads into my next point, because believe me, we aren’t out of the woods yet. You aren’t the only one that needs to understand the problem. We must also make sure that the client/coworker knows what’s up, and that we’re all on the same page.

Understanding the problem with the user

It may seem a bit redundant, but it’s true. Now that you’ve got all the pieces put together in your head (or on a white board), make sure that the client/coworker understands the problem to the same extent that you do. Often times, you may find that while you thought that you had a firm grasp on the task at hand, the client/coworker was saying one thing but trying to describe something completely different. Chances are the client/coworker is not a programming-savvy person, and that’s okay. The issue is that while a programmer would sit down and think about all the necessary features of some (hypothetical) admin tool, as well as, and more importantly, what might be needed in the future, the client/coworker will probably never try to look beyond their immediate needs. This leads to the painfully familiar situation of being a wee few hours away from finishing this great new tool, when suddenly it needs to have a translation system, tag clouds, region specific data, oven mitts, and an RSS feed to boot.

It’s important that you explain to the client/coworker how you understand their problem, the way you see their vision for this project, what you’ve understood as they’ve explained it to you. Explain to them what you’ll do—not how you’ll do it—and why the features that you will create are necessary. No one will be impressed with your technical jargon if they don’t know what you’re talking about, so unless necessary or well accepted, during all of this explanation be sure to spare the technical details, as it normally only muddles the matter further.

Thinking ahead

As mentioned earlier, clients/coworkers will hardly ever look beyond their immediate needs for a given project. It’s because of this lack of thinking ahead that clients/coworkers are prone to that we must reiterate the problem and its solution to the them in terms that they can understand, while even going as far to speculate about additional features that we think may be necessary now or in the near future. It has often been the case in my experience that while relating my own speculations for the project and my understanding of how the whole shebang is going to work, that many new-to-me but incredibly important features rise to surface.

Multiple perspectives

Today’s topic was spurred from an unfortunate situation that I recently fell into where a project at work has been unduly dragging on for well over two months. Worse yet, it’s still not done. I’ll take responsibility for that, but not for a lack of programming aptitude. Rather, I realized today that this whole mess arose out of underestimation and a lack of understanding of the whole picture as I’ve layed out here in this article. The real leason here is that, as developers, we must understand the whole picture from multiple perspectives: our own, how the client/coworker see it, and how the end-user sees it—but that’s a whole other story. More than that, we must also lead the client/coworker to the same understanding so that we are all on the same page, and to avoid suprises and curveballs further down the project timeline.

Tags: client projects, coworker projects, development cycle, pit falls, progamming cycle, project appraisal, project management, solutions, specifications, thinking ahead, understanding problems

This entry was posted on Monday, July 7th, 2008 at 11:00 am and is filed under Development, Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.