Aug 08 2008
Somebody needs to think about the quality
Dare Obasanjo had a great blog post the other day on the second system effect. One of the points he makes is
You Can be Date Driven or Feature Driven but not Both
He goes on to say why you can’t be both, but he doesn’t really touch on the fallout of running a project which is both feature and date driven. I recently worked on a project that was both feature and date driven and when you can’t comprimise features or the deadline, you have to comprimise somewhere else. That somewhere else is Quality.
We ran into a couple of problems mid project that put us about a week behind schedule, but unfortunately we weren’t given any more time and features weren’t dropped. What we ended up doing was getting rid of the unit tests in our code, getting rid of 1 week UAT and there was no documentation.
Now there are people that read this and think "well if you have to ship, you’re going to have to comprimise somewhere", but if these are the places you comprimise you are playing a very dangerous game.
By compromising all these areas, you’re reducing the quality of the work that you produce and it means you’re taking a massive risk.
When you’re working on projects, you need to realise that setbacks are going to arise and almost always the correct course of action isn’t to cut the quality out of what you’re doing because it’s only going to burn you in the long run. You need to sit down and seriously evaluate what this setback means and look at every other area you can comprimise before you start cutting back on quality. Doing so not only increases the quality of the project but increases the chances of having a successful outcome to your project