Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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 :)
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
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.
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?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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?