The ongoing debate (or spat) on Twitter about the “No Estimates” movement had me reaching for the archives.
Some now say that being forced to provide estimates is somehow counter-productive for software developers. I’ve long thought about programming productivity, and the paradox that software is too soft.
Some programmers want special treatment. In effect, “No Estimates” proponents are claiming their particular work is not amenable to traditional metrics and management. Now in a way, they’re right; there is as yet no such thing as software “engineering”. There are none of the handbooks or standards that feature in chemical, mechanical and electrical engineering. But nevertheless, if a programmer knows what they’re doing – if they know their subject matter and how their code behaves – then providing estimates is not all that difficult. Disclaiming one’s ability to predict how long a task will take is a weird way to try and engage with the business.
Software is definitely a difficult medium. It’s highly non-linear, and breeds amazing complexity. But a great many of today’s problems, like the recent #gotofail and Heartbleed scandals, are manifestly due to chaotic development practices.
As such, programmers are part of the problem.
I once wrote a letter to the editor of ComputerWorld about this …
IT Governance
Yes indeed, IT is made the scapegoat for a great many project disasters (ComputerWorld 28 September, 2005, page 1). But it may prove fruitless to force orthodox project management and corporate governance methodologies onto big IT projects. And at the same time, IT “professionals” are not entirely free of blame.
So the KPMG Global IT Project Management Survey found that the vast majority of technology projects run over budget. In the main, “technology” means software, whether we build or buy. The “software crisis” – the systemic inability to estimate software projects accurately and to deliver what’s promised – is about 40 years old. And it’s more subtle than KPMG suggests in blaming corporate governance. It is fashionable at the moment to look to governance to rectify business problems but in this case, it really is a technology issue.
Software project management truly is different from all other technical fields, for software does not obey the laws of nature. Building skyscrapers, tunnels, dams and bridges is relatively predictable. You start with site surveys and foundations, erect a sturdy framework, fill in the services, fit it out, and take away the scaffolding. Specifications don’t change much over a several year project, and the tools don’t change at all.
But with software, you can start a big project anywhere you like, and before the spec is signed off. Metaphorically speaking, the plumbing can go in before the framework. Hell, you don’t even need a framework! Nothing physical holds a software system up.
And software coding is fast and furious. In a single day, a programmer can create a system more complex than an airport that might take 10,000 person-years to build. So software development is fun. Let’s be honest: it’s why the majority of programmers chose their craft in the first place.
Ironically it’s the rapidity of programming that contributes the most to project overruns. We only use software in information systems because it’s fast to write and easy to modify. So the temptation is irresistible to keep specs fluid and to change requirements at any time. Famously, the differences between prototype, “beta release” and product are marginal and arbitrary. Management and marketing take advantage of this fact, and unfortunately software engineers themselves yield too readily to the attraction of the last minute tweak.
The same dynamics of course afflict third party software components. They tend to change too often and fail to meet expectations, making life hell for IT systems integrators.
It won’t be until software engineering develops the tools, standards and culture of a true profession that any of this will change. Then corporate governance will have something to govern in big technology projects. Meanwhile, programmers will remain more like playwrights than engineers, and just as manageable.