Developers see estimation skills as something that the more manager types need to know. The up-all-night-hacking-code attitude seems to be at odds with something like estimating - which sounds too much like administration anyway. Developers need to see estimation skills as a crucial part of their professional toolbox that reduces suffering in the long run.
In the 14th century, the armies of Europe were quite busy – Edward I was battling with the pesky William Wallace, France was getting started on the Hundred Year War and the Ottoman Empire was coming in from the East. It was a profitable time for men-at-arms, the soldiers of the armies, who were consummate professionals – good at what they did, paid a wage and taking whatever other financial spoils from the lands that they ravaged. While fighting expertise was a necessary skill – sword or mace swinging, cannon firing and so on, the ability to survive on the battlefield while being whacked with a sword deserved a bit of attention. So those soldiers spent some of their wages (and spoils) sprucing up their own personal protection to supplement the pitiful standard issue provided by their employers. The armies battled during the summer and were accompanied by a travelling city, with purveyors competing to get their hands on the one shilling per day that the soldiers were paid - distracting the spendthrift soldiers with products catering to both practicalities and vices. There was food, ale, gambling, prostitutes and other recreational activities for purchase but the prudent solider saved up to buy a suit of armor, costing £1 (at least 20 days' pay), and kept it well maintained by the travelling blacksmiths.
So as we fight our own battles, with corporates, credit crunches and call centre IVR scripts, what (in the context of software development) are the core abilities and what makes up the unglamorous practicality of personal body armor? What is our firearm which we wield with skill and what is our bullet-proof vest that allows us to live another day? I think we can have a good guess at what our weapons may be – developers may sculpt creations using C# or database experts lay solid foundations with Oracle. We know what our weapon of choice is and we are passionate about it, wielding it with pride while we storm into the battlefield. We keep our primary weapons sharp and polished – keeping them close to our sides in the event that we are challenged.
The ‘people’ people will urge us to learn other ‘soft’ skills that are necessary to succeed – the ability to communicate, manage time, manage stress and a whole host of other things that engineering types find somewhat wishy-washy and fluffy. I have seen technical rock stars, who should be at the top of their game, sitting disarmed on projects with their heads hung low. They believe that they have communicated, believe that they have managed stress, and maybe they have – but the death-march project has worn them down – leaving a husk of a development warrior. On the other hand I have also seen mediocre developers pushing through with barely a glance at acknowledging ‘soft skills’.
I believe that the personal body armor of a developer is quite simply the ability to estimate
... accurately.
Accurate estimating is more than just a project management requirement – an accurate estimate demonstrates an intrinsic understanding of your craft and, possibly more importantly, your environment. But why the analogy of body armor? To me, the ability to estimate is the single most useful (non coding) skill to reduce the pain, suffering and general abuse that a developer may face on the battlefield project.
Consider the death-march project that everyone has been involved in at some point in time - the project starts of without a fixed end date and then as budget is consumed the anxious parties agree to fix a date. Often this fixed date has no functional dependence on required effort but it is fixed anyway for 'commercial' or 'business' reasons. Developers bleat that the time constraint is impossible and project managers push for working longer hours and generally pressure developers into either being heroes or crashing. When I have enquired about the sequence of events that turn a project into a death-march, some digging reveals that project managers had so little (reliable) information to use in planning which caused things to slip, upset the customer and eventually an 'or else' date was fixed. A development team that has well honed estimation skills greatly reduce the chance that they will land up on a death-march project - and honestly, who wants to land up on one of those projects.
Some developers may argue that Agile processes mean that they don't need estimation skills and in fact the opposite is true. Good Agile teams that have a high velocity and constant flow of successful sprints are that way because they fundamentally understand what can be done in a sprint with the available resources on hand. Most Agile teams improve over time, getting close to their sprint targets as the project progresses - many factors contribute to this increased ability to deliver (team familiarity, technology familiarity, architecture stabilisation) but undoubtedly one of the key factors is, at the sprint/iteration planning stage, to be able to determine what can be done by knowing how long the various items in the sprint backlog will take. What Agile projects may do is reduce the amount or value of long-term planning (as performed by the Project Manager) but this should not be confused with the ability of individuals to accurately estimate whether a task will take 4 hours or 2 days.
While estimating techniques are out of scope for this post it is worth getting a picture of where developer estimates fit in with some of the theory. The image below is from Contrux's article about the Cone of Uncertainty as described by Steve McConnel of Code Complete fame but also a respected author on software estimation. The graphic illustrates the accuracy of the estimate as the project progresses - the important observation that when developers need to estimate their individual tasks for the current sprint that little uncertainty should exist.
I would suggest therefore, that any seasoned developer should be able to estimate with extremely high levels of accuracy when it comes down to implementing a feature that will take a day or two to complete - no excuses! Any inaccurate estimating so far towards the 'certain' side of the cone deserves the pain and suffering that will inevitably result. Obviously the more senior members on the team should be able to improve their accuracy for earlier stages in the project and also be able to reduce variance by better design, quality and moving unknowns to earlier in the development.
So developers, spend some time honing your estimating skills so that you can build up the armor to be able to rise to the challenge and not be pwned because your exposed ass(ets).
If you want me to do some posts on basic real world estimating tricks common sense, email me or comment on this post and I will follow up shortly.
Simon Munro