3 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 softwar
by lifeisstillgood 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.
Software is more like a novel than a bridge.
Maybe, maybe we can apply engineering terms to machine code or assembly. But the abstract levels we all work at - not a hope.
I mean this is a good thing. It changes how we think about software - engineering has changed the world - and it's in the hands of a few professionals. Imagine software in the hands of ... everyone. It's like Eric Idle gather mud in the Dark Ages imagining what a literate world that reads the New york times will be like
- 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.
- mym1990 5y agoBut the risk is that bad software or a bad bridge can pose as good software or a good bridge until something catastrophic happens. Software might be more like a novel if you are consuming the code/design, but to write a good novel one must be far more than just literate.
- AndyMcConachie 5y agoI tend to agree with you as well. I've also come to the conclusion that conceiving of software as some new 'kind' of non-linear writing is more productive than understanding it through the traditional engineering discipline. But it is both and it is neither. Software is a new thing that we have yet to fully understand.