It’s common to illustrate the software development process in parallels with how the construction world works. It is a discipline of “engineering” after all, and what’s a better known field of “engineering” than constructing a building or a house.
Unfortunately, while a lot of it is helpful to put things into perspective, it also causes some misconceptions and possibly encourages unproductive notions as to what can and can’t be done with software. I’d say it’s served its purpose until now, but at this point, it may be best to stop using construction metaphors when describing software development.
Why construction metaphors?
I don’t actually know, for sure. My best guess is that these metaphors are what it took to get the anarchic programmers of old to realize better practices were necessary. This pushed the transition from being “programmers” to “software engineers”. And it worked. I’ve often used these metaphors myself to instill this mindset when I train new engineers or when I taught software engineering in school.
Additionally, it must have seemed an effective way to get clients and non-technical stakeholders, likely better acquainted with the cost and processes of civil construction, to gain a better perspective into the value of the work we do.
We’ve come a long way since then though and seeking out best practices have become almost a given. By now, we’re also at a point where the best practices of construction may not be considered as applicable to software development. So while it’s been useful to ingrain a fundamental discipline in trigger-happy coders, I’m afraid the metaphor is now a little outdated and potentially sets wrong precedence for how people develop software.
Likewise, cost models aren’t quite the same as when we started out. Pricing in the way you would a house just doesn’t seem to work to any acceptable degree of success. Essentially, setting this expectation with a client may result in a worse misalignment than when you started.
What’s so different about software?
Several things, which I will outline below. Before anything though, I want to say that “The Nature of Software Development” by Ron Jeffries is an excellent book that describes what makes software unique. Admittedly, I haven’t read it from cover to cover, but the excellent illustrations have been used in several workshops I’ve attended. Every time, those illustrations effectively remind me on how best to see modern software development. Highly recommended read! (Click here to buy it on Amazon.)
Software re-do’s don’t cost as much as construction re-do’s.
This isn’t to say software re-do’s aren’t costly. They are and if you can avoid them, just do it. On the other hand, the level of fear that typically comes with moving on to the next step of the process is not at all justified. When constructing a house, having to re-do the layout of rooms could definitely blow your budget. Same goes for hardware design, which I suspect is where the fear in software directly originates. When you’ve made an order for 500,000 chips and realize near the end of production that you need a re-design, some heads are likely to roll.
The fact is, however, that software is value coming from almost nothing. You don’t have raw materials and tooling to worry about. Sure, the cost of work is pretty steep, but work you put into software, no matter how inadequate, always has some value for a while as long as it gets to the user. It’s hardly ever a complete waste of time.
Code in progress is not as visible.
Unless you’re a developer working in the team, code in progress won’t be as tangible as a house in progress. When you look at a house being built, you can easily grasp an idea of how the work is going. On the other hand, the amount of important code that, in the eyes of a user, does almost nothing is hard to conceive.
This often results in dissatisfaction for the user or client, and it’s hard to blame them. People who sell software should keep this in mind and manage expectations accordingly. Of course, the whole point of agile is to demonstrate high value as early as possible, so this addresses part of the problem. In any case, it’s never going to fully show how much of the dirty work has already been done at any point.
Standards are less established in software…
… and it will likely always be that way. Software engineering evolves rapidly, and what’s considered good now may not be as desirable a year or so from now. With construction and many other fields like accounting and human resources, you have the advantage (and, ironically, burden) of having a firm set of regulations and standards that you need to meet. In an ideal world, you can trust those regulations will ensure your work is of acceptable quality.
You really don’t have much of those in software (except in a few select industries, which for the purpose of simplicity, I’ll ignore completely). So if you’re trying to set “gates” to make sure quality is good, to what standard do you hold yourselves to? In the end, the quality of software lies on whether it gives value to the user and timing can be a big factor in that. A few bugs will probably not make that big a difference, as long as it doesn’t take away any major value from the user.
But I need metaphors!
At this point in time, do you really? Software is now ubiquitous, to a level where the untrained have a pretty solid understanding of how it works. There’s hardly a need to abstract it. Admittedly, you will occasionally encounter someone who will refuse to understand why you can’t build their software for free. This is where I feel the software as a service concept becomes useful as a cure for ignorance.
The traditional way of viewing software was as a product. In the 90s and early 2000s, software came in boxes, with a printed user manual and sold at retail stores. (Fun fact: One of the first times I held a “box of software” in my hands was a copy of Microsoft FrontPage my uncle owned. To a 10-year-old me just starting to use computers, it was majestic.) Looks like a product, feels like a product – maybe it is a product?
Software as… an employee?
When you think about it a little more though, what software actually does is substitute for some of the work that you do or would otherwise hire other people to do. Unlike a product, you don’t “run out” of it and it’s not “consumed”, though it may eventually become redundant. Taking on this perspective, you don’t actually buy software, you hire software.
That’s why the subscription model for software just makes a whole lot more sense compared to one-time licenses. You may not need certain services forever, so why pay for it permanently? I think looking at software as a service (or *metaphor alert* an employee, if you will) sets good precedence on how to create value the right way. Like any good employee, good software is self-aware. It may occasionally make mistakes but it continues to improve. It may also not be immediately productive the moment you hire it but you’re right to expect real value in due time.
More importantly (for your livelihood’s sake), good software, like a good employee, doesn’t come cheap and you can explain that to your customers. In the end, if they can’t see the value of a good employee in the same light as a well-built house, they may not be the right clients for you.
Looking to start your own “software as a service” project? ATeam Business Software Solutions Co. can make it happen and take care of building the software for you. Visit our site here and let us know what you have in mind!
Dexter is an engineering manager at Synacy, a co-founder of ATeam Business Software Solutions, and founder of TechManagement.Life. He loves to share his experiences and thoughts on managing software teams and running businesses.
3 thoughts on “Do Construction Metaphors Still Work For Software?”