Archive
Set The Price, Or Ask For An Estimate?
This tweet from a #NoEstimates advocate is interesting food for thought:
Let’s say you are one member of a software development team of 5, and each of your salaries is $100K per year. Now, assume that an executive in your org requests that your team build software product “WhizzBang” for $500K. If your team accepts the request, then your deadline date becomes automatically set in stone as one year from the selection date. If you don’t accept the request…. well, then you and your teammates should look for other work.
An alternative approach for getting “WhizzBang” built is for the executive to ask the team for an estimate of how long it will take to get the software built.
I, as a software developer, would prefer the bidirectional “asking for an estimate” approach rather than the unidirectional “setting of a price” approach. Neither approach is ideal, but the “asking for an estimate” approach gives me the opportunity to provide information to the executive that allows him/her to decide whether or not to move forward on his investment.
In either case, history sadly shows that neither approach is likely to lead to the derived deadline being met. In those cases where the deadline is met, the team has most likely worked tons of unpaid overtime over a sustained period of time and has cut quality corners to do so 😦
A Croc O’ Crap
As a software developer, the idea of #noestimates was really appealing to me. I sooo wanted to be convinced of its applicability across the whole landscape. Thus, I originally was on board with, and rooting for, the fledgling movement. However, it’s hard for me to take the #noestimates community seriously when one of its top advocates slams a croc o’ crap like this down on the dinner table.
From what I’ve seen and heard over 2+ years of heated Twitter debates, the case for jettisoning the practice of estimation from the software development life cycle is still so intellectually weak that I consider it a waste of energy whenever I find myself getting sucked into the fray. Now when I scroll through my twitter feed and stumble across yet another vitriolic exchange on the subject, I cross my fingers and pray that I make it past the spew without adding my own crap to the gobbledygook.
The Four “C”s Of Twitter Debates
The debate that reminds me most of the above graph is the one that is centered on #noestimates. As far as I can tell, that fire has been raging along for 2+ years now.
Asstimation!
Here’s one way of incrementally learning how to generate better estimates:
Like most skills, learning to estimate well is simple in theory but difficult in practice. For each project, you measure and record the actuals (time, cost, number/experience/skill-types of people) you’ve invested in your project. You then use your historical metrics database to estimate what it should take to execute your next project. You can even supplement/compare your empirical, company-specific metrics with industry-wide metrics available from reputable research firms.
It should be obvious, but good estimates are useful for org-wide executive budgeting/allocating of limited capital and human resources. They’re also useful for aiding a slew of other org-wide decisions (do we need to hire/fire, take out a loan, restrict expenses in the short term, etc). Nevertheless, just like any other tool/technique used to develop non-trivial software systems, the process of estimation is fraught with risks of “doing it badly“. It requires discipline and perseverance to continuously track and record project “actuals“. Perhaps hardest of all is the ongoing development and maintenance of a system where historical actuals can be easily categorized and painlessly accessed to compose estimates for important impending projects.
In the worst cases of estimation dysfunction, the actuals aren’t tracked/recorded at all, or they’re hopelessly inaccessible, or both. Foregoing the thoughtful design, installation, and maintenance of a historical database of actuals (rightfully) fuels the radical #noestimates twitter community and leads to the well-known, well-tread, practice of:
The #noprograms Revolution
I’ve been developing software in the aerospace and defense industry for 30+ years. Because of the sizes of, and innate System-of-Systems nature of, the solutions in this domain, the processes used to develop them are by necessity, heavyweight. Oh sure, agile/lean techniques can be used effectively in the teeny-tiny-small deep down in the bowels of some of these programs, but to assume “scaling agile” will work in a domain with hundreds of programmers from multiple contractors working on the same distributed system is naive at best, and downright disingenuous at worst.
The most ridiculous examples of inapplicable development practices to the aerospace and defense industry are #noestimates” and “#noprojects“. The “#noprojects” cult is so far off base that they don’t even acknowledge the existence of “programs” – which are a way of organizing a large set of inter-dependent “#noprojects” into, well, a larger grained mission-critical entity worth tens of millions of dollars. It’s like before there were classes and namespaces(packages) added to a programming language to accommodate increasing software system size, there were only “functions” for organizing the structure of a program – and having functions as your only organizing mechanism doesn’t scale well to large software systems.
Hell, the #noprojects people are akin to #noclasses and #nonamespaces people, of which there are thankfully, #nomembers. Really hardcore #noprojects people are perhaps even more loony. They are equivalent to a hypothetical #nofunctionsallowed crowd that demands monolithic, straight-line code only. Line number 1 straight to line number 5,000,000 – and you can’t use loops or “ifs” because they don’t add value and #nofunctionsallowed is all about “maximizing the amount of work not done“.
But hey, if you don’t need any “projects” to build a successful product from the gecko, then by extrapolation you don’t need any “programs” for organizing your projects. Hence, the inimitable BD00 proposes to “scale up” the “#noprojects” movement. We’ll start a revolutionary #noprograms movement, or equivalently, #justcode . We’ll leapfrog both the #noestimates and #noprojects movements at once. W00t!
Thanks, But No Thanks
When it comes down to it, the primary function of management is to allocate finite org resources to efforts that will subsequently increase revenues and/or decrease costs. By resources, I mean people and money (for salaries, materials, tools, training, etc) and time.
Since projects vary wildly in complexity/importance/size, required skill-sets, and they (should) have end points, correctly allocating resources to, and amongst, projects is a huge challenge. Both over and under allocation of resources can threaten the financial viability of the org and, thus, everyone within it. Under-allocation can lead to a stagnant product/service portfolio and over-allocation can lead to an expensive product/service portfolio. Note that either under or over allocation can produce individual project failures.
To correctly allocate resources to projects, especially the “human resources“, some things must be semi-known about them. Besides desired outcomes and required execution skills, project parameters like size and/or complexity should be estimated to some level of granularity. That’s why, for the most part, I think the #noestimates and #noprojects people are full of bullocks. Like agile coaches, they mean well and their Utopian ideas sound enticing. Thanks, but no thanks.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 