From Kodumaro.
It’s very common the analogy between software “factory” and the civil sector: buildings are made brick by brick, a patient and homœopathic work to build a huge and solid structure, while software are made code by code, a patient work too.
Nothing could be futher from reality.
Still inexact, but closer to the real thing, it’s the analogy with a transport vehicle (not its factory!)
A software is like a tractor: when the tires are bald, you change them. If the engine is broken, you fix it, otherwise you change it. When the tractor is obsolete, you change the whole thing.
So are the software.
When some parts are malfunctioning, you change them. If its core is broken, you fix it, otherwise you change it. When the software is overpast, you change the whole thing.
Mind that the code is to the software as the tractor hardware is to its feature. Change the code isn’t change the software.
More precisely, the software is a live thing, that grows, evolves, and eventually dies. It’s information, not a hard brick.
Image credits: pngtree @ Pinterest
Top comments (8)
it's compared to building processes because your way to work is the same.
Let's say for example you want or need to build a music conservatory.
Yo want a quick construction? take some prefabricated blocks (libraries, packages, frameworks...), join them together and you'll end with a full building (an App) for what it was planned for.
You may want (the architect) for making it more precise to the job it's intended for so you can build it from scratch using few or zero prefabricated blocks then you end with a brand new one, maybe you defined a new architecture or design that solves issues that prefabricated based ones have so your product is better, but at a higher cost.
The issue comes when the people who pays you wants to add bedrooms, a restaurant, a parking lot and two gas stations inside this hypothetical music conservatory.
Parts on your initial design don't fit well with this new features so you'll need to refactor some parts (like home renovations/ammendings/extensions), maybe you'll need to break down an entire wall, on another you'll need to break a part to add a door and so (rebuild, refactor).
By the way buildings are not usually build brick by brick but component by component such as on IT (they use big molds to create bigger pieces to speed up the construction, we create reusable components that analogically are the molds to speed up the building of different components with the same basis).
The analogy with the tractor could be better done with buildings:
Not only you maintain the building structure by checking it periodically, also you test any change you do on the building after doing works on it (which on IT those are unit tests). You also may want to keep the building clean as you may want your code to be clean too.
If a light bulb stops working you replace it with a new one, if you need more light on there you will put a higher wattage one. If you need more seats on a room, you may need to reallocate your current ones for the new ones to fit into the same room.
You also can paint the walls, change the windows, the chairs, the tables, tiles and so (UI re-design).
The information are objects living, being stored, and moving along that building, not the building itself.
You build something for threaten data that makes this data change on one of another manner, this data does not change the structure; when you show a view or another depending on data it's simply another room of the same building (APP).
For all these reasons there's any best analogy for software projects than building construction sector.
I disagree with your opinion. Buildings are static rocks, Software are alive and soft. There’s no analogy.
Yet your voice is welcome. 😉
An analogy covers conceptual similarities between the noun and the original "something", I catch your analogy with the tractor and your reasons, but software isn't moving anywhere, it's hosted quietly on a place, distributed or not and it's structure is more solid than you ensure. You can't change the framework, language or hosting easily, it's a hard job that takes time and sometimes it's near impossible.
I can bet on your point of view on a little project but on a big one things are not that soft "as is", that's the reason to be of micro services and their architecture and patterns that makes this theoretical building to become a city of little buildings, each one with it's responsibilities, which is more accurate (now thinking on a bunch of little tractors as comparison I remembered this scene of Cars and I'm laughing my ass off: youtube.com/watch?v=HF0s-pXOHck)
Oh and... nope. Software is not alive, it's a product made by developers, just like a handmade chair, nothing special into it.
Well… “software isn’t moving anywhere” is not a crossed bridge… ¯\_㋡_/¯
And I thought the “conceptual similarities” was clear in my text, if it’s not, I apologise.
About your “betting,” I “bet” I’ve been through a lot of “big projects” in my career, and they endorse my point.
I would like to understand the origin of your point of view, why do you say software is "alive" and "soft"?
OK, that’s a very good point!
The “building”-like software perception leads to the idea of a hard thing, something static. That vision has been coined a long ago, and consolidated in the 90’s, when you got “final” releases that shouldn’t change. Any changes would come in the next releases.
Google and Ericsson, among others, realised the software is “soft”, it can grow and change anytime, like a living being – the perpetual beta.
That vision has changed the way we look to software, taking it away from the building-like.
It's a good point, I keep seeing it as building-like but just like a separate concepts on structure and interior design, I'll reflect about that later :)
I've argued against this persistent Taylorism in the software world almost endlessly, at all levels.
Do you have any sources for when this was consolidated in the 1990s?