The reason these practices are forsaken is clear: "I don't have time for that." This attitude pervades most activities of typical software teams. Management pressure, scope creep, deadlines (real and imagined) all lead to a constant sense of urgency and temptation to cut corners. I believe this is due to a fundamentally flawed perception that a software project is a race. This is wrong; it's a race through a minefield.
We are racing, of course -- against competitors or deadlines or a closing window of opportunity. However, the circumstances of the race are such that it's not a good idea to simply run as fast as you can. For a while, it may feel as if you're making great progress. But this is a false sense. When you hit a mine, the resulting setbacks will be devastating to your overall progress.
Instead of simply running as fast as possible, the correct attitude is to move with deliberate speed. After all, we are racing, so we want to move as fast as we can. But we really need to be sweeping mines as we go.
So why isn't this deliberative approach more prevalent? Unfortunately, teams can be awfully good at denying the truth behind a project's demise. Failure is an orphan and it's easy to obscure reality by pointing the finger at something -- anything -- other than the fact that we, ourselves, didn't keep things well-maintained.
The good news is that if you do what you should be doing (testing, designing, refactoring, talking) when you should do it (right now), ultimately you will arrive at your destination much faster than your competition. That is, unless your competition has already started focusing on quality while you're busy running towards that land mine.
Posts
0 comments:
Post a Comment