Random Thoughts on deadlines

I've worked in several places where deadlines are tight, who hasn't. Management can help, but they can also hinder so I thought I'd sketch out my ideas of what helps the most and what destroys any chance you may have had in producing a deliverable.

A quick word on methodologies, Agile is great it is fantastic to never lose sight of the actual goal and having weekly sprints whereby a result is actually seen by the major project stakeholder is ideal...however there is a tendency for management types to see a product with the bits they liked that week and can't make the intuitive leap that although those features work the product as a whole is incomplete and so it gets sold.

Also there does have to be buy-in from the ground level all the way up when going agile, if the guys up top are still requesting requirement documentation and things they've missed the point and many of the benefits of agile will be lost.

So back to the issue of deadlines, number 1 is where the deadlines come from, if it's a sale date then how was it decided. More than likely it has been decided by a salesman whom has no clear knowledge of what the solution entails let alone how much work is involved or the resources that will be available, with so many unknowns it's no wonder that the deadlines are incredibly unrealistic.

A clever manager when faced with a, lets say it, stupid deadline, will gather his troops garner opinion from the experienced developers that will after all be sweating buckets to meet the deadline, then and only then will they be able to judge the loading of the team members and produce a realistic, yet usually very tight deadline. If an adjusted deadline from someone with more knowledge is ignored you can pretty safely say it won't be met. Not only will the deadline not be met but because of it's unrealistic nature the psychology of the developers will reach a point of "it's not possible so why bother" this causes projects to actually go slower than if the deadline had been set more reasonably to begin with.

The Carrot or the stick.

Software developers are a lucky breed in that their skills are 100% transferable this means when pissed off they simply jump ship. Too much pressure they jump, not enough money they jump, no respect they jump and bored they jump. Keep the good guys happy and a good supportive team is created. If developers want to do well then they will, if they feel forced or coerced into doing something they feel less inclined to do they won't do well and once again are likely to jump ship.

The same goes for managers to be honest, barking orders makes developers dig their heels in, yet if a developer doesn't want to let the manager down they work harder, this level of respect isn't automatic nor is it bought with bonuses it is developed over time and yes it takes work. Shouting or berating the very people that are doing the actual work is never going to work, trying to pile on more pressure is also never going to work. "what you mean the developers won't work harder for this crust of bread!" it is sad that even to this day there is a falsehood touted that people work harder when they feel their jobs are under threat, that just makes them dislike the job and guess what they leave!

Now the carrot, I've seen bonuses work in the past, usually bonuses on a sliding scale make the damn near impossible to reach deadline have a high bonus then give a far smaller one for meeting the previously thought of unattainable one. Lets face it salesmen get bonuses for landing big sales that sometimes are a result of them enjoying a visit to the pub with the right people. I am not saying sales isn't hard and that the tough ones should be rewarded but they all agree some accounts are easier than others, to the point of not being work at all.

Now the reason that neither of these should be used anyway is that once the stick is used developers bugger off and once the carrot is used too often developers come to expect it and when they don't get it they bugger off! Plus there is of course the product and the customer to think about. At the end of the day the only way an unrealistic deadline is going to be met is if corners are cut. The first thing to go will be the documentation, then the level of testing then the standard of features, then the number of features until eventually a pile of crap the customers didn't want is given to them they complain and either the whole lot needs to be re-worked thus taking us to a point beyond an original realistic estimate or the customer throws toys from pram refuses to pay and maybe sues. This is scary but true.

Estimates

It all starts to go wrong from the moment an uninformed guesstimate of a deadline is given and the recipient believes it.

So how are the estimates made and how can they be so wrong?

It's all to do with the number of unknowns, or variables when estimating, the simpler the item being created the fewer variables and hence the more accurate the estimate can be. Most large sales have countless variables, not only that but they also have unexplored avenues. What I mean by this is that if nothing similar has been created by the team there will be a certain amount of trial and error with their solutions this is perfectly valid and by taking the software through this sort of evolution means that the best solution should be arrived at. The trouble is you don't know that one avenue of development is necessarily better than another for your particular problem given that you've never seen anything similar and the number of avenues can almost exponentially increase the number of unknowns of development.

To explain lets take a chess game as an example, the solution we seek is to checkmate the opponent we start with 20 possible moves at the beginning, that's 2 for every pawn and 2 for each knight. Depending on which move or avenue we investigate next determines the number of possibilities we have next and at this point we're not sure that the one we take is going to help us reach our goal we take an educated guess but we may well need to backtrack to this point before a solution is achieved.