2 ms·
> My two cents: Software is a form of literacy not engineering. One good bridge looks and acts almost exactly like every other bridge in the world. Good softwa
by hwayne 5y ago
> My two cents: Software is a form of literacy not engineering. One good bridge looks and acts almost exactly like every other bridge in the world. Good software that does a given job can be unrecognisable compared to other good software that does exactly the same job.
1. This is false. One of the reasons making bridges is so expensive is because each bridge is a precious special snowflake with lots of challenges specific to that bridge project and no other bridges.
2. Bridge building is a very small part of civil engineering, and civil engineering is a very small part of traditional engineering. Maybe software is more like process engineering, or chipset design, or subsystem integration, or workflow optimization.
- lifeisstillgood 5y ago1. I agree bridges have special challenges, but ... well for 2,000 years there was a keystone, and an arch. Yes the soil and the land were challenging, but I find it hard to argue that every stone bridge was a special snowflake. Snap a supporting cable on any suspension bridge and they all have the same failure mode. I think we are stretching analogies - is "build a CRM for the sales department" simple as in "there is a keystone data design common across all CRMS - and all the rest is "shifting sands of the river are same as shifting alliances in the boardroom" I just try to keep this simple. Coding uses symbolic representation to describe a model - this is what language is. Compilers do / can do things that simply don't exist conceptually in Engineering. Coder manipulate symbols. It really is a language thing. 2. yes. I was just using bridges as an example of engineering. As CRUD websites are an example of software engineering.
- lolinder 5y ago> I just try to keep this simple. Coding uses symbolic representation to describe a model - this is what language is. Compilers do / can do things that simply don't exist conceptually in Engineering. > Coder manipulate symbols. It really is a language thing. What is conceptually different here between software engineering and civil or mechanical engineering? Engineers use symbolic representations (math, diagrams, computer models, etc.) to describe a model of what will eventually be manufactured or built in the real world. They're typically not the people who actually build the thing, they're the ones who describe it in sufficient detail that someone else can build it. This is as much a language problem as it is in software. The designs need to be readable by the entire team of engineers as well as the people who will make the design real. The primary difference I see is that in software engineering, the "someone else" who will build the thing is a computer program called a compiler rather than a factory worker or a construction crew.