Anyone who has studied Software Engineering knows that because of inherent complexity in even the simplest software, there are always going to be bugs. What we need to do as developers is make sure that 90% of them are dealt with. The other 10% will always be there but in the normal course of events, they will not interfere with the user. In fact the user will probably never encounter them.
This brings me on to Project Management. In classical PM we learn of the “Triple Constraint” (See diagram) of Cost, Time and Scope. Somehow Quality, which seems to be an inconvenient afterthought, floats into the middle of this triangle and seems to look after itself.
The Theory is that as you increase scope, cost and time will also increase. This is in fact correct and I’m still stunned by the number of PMs who seem to be unaware of this or who choose to ignore it. So what happens? Well I’ll tell you what happens on most projects. The development team is expected to work “harder” and start pulling long hours and start working weekends. Brilliant. There are even a few super keen developers who insist that they are OK with this.
These guys are great, I love having them on my team, but their enthusiasm is misplaced.
Simply this – and this is where classical PM and I cease to agree – no human can maintain an adequate level of concentration when he or she is working longer hours. It’s a simple fact – repeatedly shown by researchers – that developers (and anyone in a high concentration business) can only maintain that level of concentration for 3-4 hours. After that they must have a break. If you are very lucky you can do two of these in one day. Some days I can, most days I cannot. That’s usually OK. You then do emails, documentation, admin and other work related tasks.
This “concentration span” will become less as you get older. By my age most people have moved out of development altogether and have taken on more responsible but less mentally hyper-focused work. I even know of one friend who artificially enhances this “concentration span” with Ritalin. (Not recommended people!)
So where does this lead us? Developers, because of this relatively fixed concentration span, will produced good work, but only a certain amount of it per day. Now we play what-if. What if we push these developers to work extended hours in order to stay within budget yet meet our new extended scope? Well it’s simple and it is a fact. Please feel free to do the research yourself. The Quality of the software will deteriorate. There will be more bugs and – even worse – you could have degraded or poor logic constructs. PMs note – this will lead to higher TCO after the project.
So let’s get back to the Diagram above – what we need here is a fourth constraint to make it more accurate. We need Quality. Whenever we mess with the scope or the time we are messing with quality. Try to fool yourself or your client that despite the increased scope you will still bring the project on-time and in-budget and you will be showing a lack of professional integrity. Whether you like it or not you will be delivering an inferior product. Developers are not production line workers. Good developers are craftsmen and should be treated as such.
Here’s a beautiful little parable to illustrate this. It’s called the “Kings Dinner”. Please read it – it’s worth the time.