I have long considered it a fallacy to call software development “engineering”. Even though the term technically works for software as “the science, discipline, art and profession of acquiring and applying technical, scientific and mathematical knowledge to design and implement structures, machines, devices, systems, and processes that safely realize a desired objective or inventions” (see Wikipedia), this is not how the term ends up being interpreted and therefore misrepresents how software development actually occurs – since engineering has become synonymous with building physical structures such as buildings, bridges, roads. Recently someone with authority on the subject expressed this opinion much better than I could have, and since he has authority on the subject and in the industry, it means something.
According to Wikipedia, “Tom DeMarco has authored over nine books and 100 papers on project management and software development” and has been intimately involved over the past 40 years in the software industry and the establishment of “structured analysis”, software project management concepts and legendary software development projects such as the first large scale telephone exchange for Bell.
He recently wrote an article titled “Software Engineering: An Idea Whose Time Has Come and Gone?“
The article is well written and there is no value in me repeating it verbatim, so read the original.
The following quotes however are worth me repeating along with my commentary:
“Software development is inherently different from a natural science such as physics and its metrics are accordingly much less precise.”
Software development is not like building a bridge – where the materials, laws of physics and chemistry, labor times etc have all been experienced and practiced thousands of times, can be accurately predicted and correctly planned for, then managed.
“Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.”
If we are writing software, it’s because we’re trying to do something that hasn’t been done before or is different in some way from what already exists, otherwise we’ll purchase the existing software. We are building a solution to a problem – to create value of some kind.
If we’re doing something that hasn’t been done before – either with new technologies, new rules, new performance criteria or whatever it is that makes it unique – then we are doing “research and development” – experimentation. It is not as if a blueprint for a house is given and the construction team comes in to build it as they’ve done 1000 other houses in the same community. Software “architecture” doesn’t work that way. There is never a replicate – because it’s not physical.
Yet business and project management would love it to be – it makes it easier to control, schedule and most critically, budget for.
Tom DeMarco discusses “metrics” in the most detail in the article, about why we spend so much time trying to control software development projects, and particularly the timeline/cost aspect.
He says:
“For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.”
After giving an example of two projects, one creating little value and one creating significant value he states:
“This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.“
Ironically, I’ve generally seen the opposite perspective from business – that the “expensive” projects, the ones typically capable of creating the most value, are the ones where the most control of timeline and cost is desired and therefore the most damage done by “management” as opposed to allowing the necessary experimentation, design, thought, research and development to occur to create the most value out of the software.
Being criticized of being “unable to delivery on time” in software development is not something I can really take personally – when the industry at large struggles so significantly with this, largely because it has tried so desperately to liken software development to a public works engineering project such as building a bridge, a building or a road.
Software development is more like art than most seem willing to accept.
It is driven by creativity, experimentation, research, design and artistic drive.
Is it any wonder that the “transformative” software projects most often come from startups (Apple apparently being the exception with their iPhone OS and demonstrating the amazing culture of design they allow to flourish) and then as they mature become stagnant once quarterly reports drive business as opposed to the development of a product? Or that opensource, where timelines mean nothing, can build great software such as Linux, Firefox and MySQL? Look at what has happened to MySQL over the past 2 years as business “management” has replaced “experimentation” and focus on quality — the key people who built MySQL over the years have left to work on something where strict control is not the focus.
As Tom DeMarco suggests, I hope to be focusing on development where the value is worth allowing the proper time, people, experimentation and development to occur – so that something of true value can be created. If management of “costs” is the most important aspect of the project, the greatest value to be created, I don’t even want to bother. I’d rather work on a project that has the ability to be transformative, and create greater value than the cost of the effort.
software engineering:
An Idea Whose Time Has Come and
Filed under: Management & Leadership
