[guelo]

I can't think of another discipline like software engineering. Most other disciplines where you build things you reach a point where you deliver the product and then you're done with it, there might be some maintenance but the period of major changes is done.

In software you might have a building full of engineers working on the same product for years after it was initially delivered, adding major features, making deep changes. The level of continuos delivery doesn't exist in other fields.

[heartbreak]

Sure it does. It exists in construction. You build a building to spec, and then that building is constantly outfitted for new tenants, remodeled, and renovated for decades if not centuries.

[bdamm]

Yeah, but the original teams that designed or built the building are long gone, and in many cases the tenant/remodel work can happen without any of the original blueprints. Buildings are meant to be modified, and this is why we have building codes, subfloors, ceiling tiles, etc. In commercial software, the startup hurdle is so great, that it usually means only a team that is contiguous with the original construction team can economically extend the original in a meaningful way.

Open source requires a different way of thinking about it; not all software can be open source. Not all buildings can be raised like a barn. In fact there is very little in the construction or civil engineering world that matches what happens in open source software.

[ahayter]

This analogy is one of my personal favorites for software development. The machine that is going to be running the software could be considered our building. The hardware of the machine is designed to exacting specifications by people that typically hold university engineering degrees and is much more reliable than software typically is, it has to be or nobody would use it. Failure of the building is catastrophic to the tenants.

A process could maybe be considered a room within that building and adding functionality to that process is akin to adding furniture to a room, or I guess, doing a buildout for a tenant. You add specific furnishings to help you accomplish specific tasks within that room.

This analogy breaks down pretty quickly, but think about the room here. I can now explain to a non-technical person that this software (a single process in this case) is like a broom closet that we've shoved full of old furniture for the last 5 years. Prior engineers have stacked tables to the ceiling, filing cabinets have locks without keys. We don't even know what's in the back of the closet at this point, and getting a peak at what's in the back will require unpacking everything at the front.

On the other hand you could have a different room. It has doors for egress and ingress. It has glass walls so we can see what's happening at all times. We carefully arrange the furnishings for efficiency, and can swap out old furniture for new in a matter of moments. We regularly clean the room, removing unused/aging equipment etc... When people enter that room to work (end users) the workflow is effortless and intuitive.

So as a software developer/engineer or whatever you call yourself, we're more like the contractors that buildout interiors for specific use cases. We equip the rooms for doing specific jobs. You give us the building or even just one room and we'll make it useful.

[devdas]

Except that hardware fails, but software should stay reliably running in the face of that system.

Think of software more as a neighbourhood, or even an entire city. Rebuilding any given building should not impact the running of the city itself.

[devdas]

Software is the creation of the spec.