Time to abandon what has failed
More and more software will be behind schedule, over budget, underpowered, and of poor quality - and there's nothing we can do about it.- Bruce Webster, Byte Magazine 1996
What's surprising - astonishing, in fact - is that many software engineers believe that software quality is not improving. If anything, they say, it's getting worse. It's as if the cars Detroit produced in 2002 were less reliable than those built in 1992.- MIT Enterprise Technology Review, June 17 2002
The mass production paradigm has failed the software industry. The improvements to cost-effectiveness and the reduction in inefficiencies by focusing on methodologies, processes and tools have not materialised.
The characteristics of mass production include repeatability, large infrastructure, organisational gigantism, efficiency, and techno-centrism. Repeatability relies on the interchangeability of parts, including workers. Division of labour fragmented worker occupations into specialised jobs so that a worker could be replaced with a new worker of the same description, in theory, preventing production from slowing down. A large infrastructure with more capacity grows from the pursuit of economies of scale and allows the amortisation of production costs across production volume to provide greater return on capital investments. But a large infrastructure requires a large organization to operate it and this costs more. The best way to reclaim these costs is to keep people continually busy and, in software development, the best way to keep them busy is to have them multi-tasking across lots of projects. Efficiency means keeping the infrastructure operating constantly under full load with the machinery and workers perpetually busy. But the focus on efficiency means there is little tolerance for stopping to correct systemic problems that permit or cause defects. The obsession with efficiency leads to centralisation and departmentalization based on roles and a dependence on after-the-fact detection, remediation and acceptance. It pays lip-service to improving quality and reducing defects. The cost of rework and the loss of flexibility in being able to respond to customers and the marketplace is significant. In their quest to maximize efficiency, organisations adopt more infrastructure and tools but it's really using technology for technology's sake. The software industry likes to look to bigger, faster, more complicated tools as way to meet schedules.
If a little medicine doesn't make the patient better, keep increasing the dosage until it does. The strategies of mass production, which aim to contain chaos through task and worker specialisation, process standardisation, hierarchical structure, and command-and-control management simply don't work. But old habits die hard.
Tags: mass production, efficiency, centralisation
posted by Simon Baker @ permalink
blinklist :
del.icio.us :
digg :
furl :
simpy :
spurl :
reddit
3 Comments:
I would differentiate process standardisation viewing people as just "bodies" versus process standardisation used as a baseline for continuous improvement (a la Toyota Way).
I remember Kent Beck saying something like "I'm an average programmer with good habits". I disagree with the people in our community who have a tendency to assume that Agile is about heroics.
Seems that there's a spookily common train of thought going on. I was discussing this exact same thing with someone last week.
Software is not about economies of scale. Every software project is a new, shiny design. Putting it into a production perspective, a software project is the equivalent of a prototype. The mass production happens when the prototype is "complete" and the bits can be shipped, roughly analagous to burning CDs.
I can hardly believe that you are flogging this dead horse. Your sources are respectively 6 and 11 years old. I partially agree with what you say, but it has been said many times before.
How about some new, WELL QUALIFIED insights? I completely agree with Jason Yip - learn to distinguish - do not compare apples with pears and then blame the apple for being a bad pear.
Agile is not a religion, and requires reason rather than evangelism - it is a pragmatic approach to getting the most value to the business as early as possible. Perhaps it is time that some Agile evangelists makes an effort to present rational arguments rather than half-considered philosophical musings - it might make it easier for "old fashioned" (and seasoned) IT executives to understand and accept.
Post a Comment
Links to this post:
Create a Link
<< Home