The Development Dilemma

It seems to be the eternal struggle for developers: racing against project deadlines while simultaneously trying to produce quality code. As developers, it’s clear the world is conspiring against us. The sales team wants to minimize the budget to help sell a project, the project manager wants to minimize resources and finish on schedule, and the client wants to change the requirements. Oh, and by the way, your code needs to be clean, well documented, and needs unit tests.

Writing clean code, comments, and unit tests all take more time – time we don’t have. In the face of pressing deadlines, it seems all too logical or even necessary to postpone all non-critical work in order to complete the required features by the required date. Project circumstances tend to boil down to the question, “Do you want it done fast, or do you want it done right?”  Or so it seems…

If I can help just one developer deal with this conundrum, I’ll be satisfied that I’ve done a good thing. So here’s my morsel of wisdom: it’s all a shell game.  All of this extra work is the ball. You can hide it under any shell you want, you can shuffle your shells around until you’re dizzy, but in the end the “extra work” ball is still there.

The problem is that sooner or later, you’re going to have to clean up your code. You’re going to have to write those comments. You’re going to have to write the unit tests. The work isn’t going away. (I’m operating under the assumption here that delivering crappy, undocumented code isn’t an option). So hiding the “extra work” ball under a shell until later in the project is really just creating the illusion of being done. You might fool your project manager and you might even fool yourself, but eventually the ball will be revealed.

Postponing the work isn’t going to help the project finish sooner, nor is it going help the budget. In fact, hiding the “extra work” ball until later in the project can create a very serious risk for the success of the project. If you have successfully fooled your project manager, he or she will likely be surprised at the end of the project when the shell game is exposed and they discover a big ball of work to clean up code, write comments, and create unit tests. When extra work arises late in a project, a project manager has little time to make adjustments to keep the project on schedule. There is no time to recover. Delayed delivery or client acceptance is often the result.

So, if you can’t find another alternative to pushing the “extra work” ball until later in project, my advice is don’t keep it a secret. Don’t fool yourself, and most importantly don’t try to fool your PM. Make sure everyone knows where the ball is and can plan accordingly. I know, it’s tough and often unpleasant, but in the end it’s better than the alternative.