Earlier quoted context omitted.
Do you share the opinion that software doesn’t qualify as engineering? I’ve always thought it is a little bit of a stretch.
Engineering means using math to model your solution so the first time you build something it works to spec. Or at least it's close enough to only require minor changes, not a fresh redesign. It's essentially applied physics. Software is more like nailing things together in the hope they might work. ML has some modelling, and formal methods are available for mission critical projects. But the rest is mostly nail guns…
Requirements volatility is the core problem of software engineering
81–90 of 251 posts
Re: Requirements volatility is the core problem of software engineering
#82Earlier quoted context omitted.
I often hear people use that logic as a reason why software doesn't qualify as engineering
It can be in some circumstances.. I think that the engineering mindset (adherence to the scientific method, evidence based decisions, planning for the future etc..) is one that is definitely shared by both groups at least. But you can absolutely get away with building software without proper engineering standards. It's not so easy to build bridges that way.
Re: Requirements volatility is the core problem of software engineering
#83If bridges could be replaced in minutes for pennies, we’d build them iteratively too.
Re: Requirements volatility is the core problem of software engineering
#84It is funny to compare that to traditional product design. Let's say your goal is to design a chair. The most important tools in your toolbox are variants and iterations. The worst you could do as a designer is constantly working on one (final) chair. Because every change that goes aginst the initial concept will have you saw pieces away and glue them to other spots till you end up with a completely irrational whole.…
> Also software (like graphic design) is a field where people without any skill tend to have strong opinions about how things should look or work Business too. You do not have to be a good strategist to “succeed” as a VP in a medium or larger sized organization. In fact, you can be downright terrible.
I've been thinking that this is one of the key differences between software and bridges. When you design a bridge, very few people have a "right" to an opinion on the bolt sizing. But when you design an order entry system, the business users (and users of the downstream data) have a valid right to an opinion.
Re: Requirements volatility is the core problem of software engineering
#85Earlier quoted context omitted.
Engineering means using math to model your solution so the first time you build something it works to spec. Or at least it's close enough to only require minor changes, not a fresh redesign. It's essentially applied physics. Software is more like nailing things together in the hope they might work. ML has some modelling, and formal methods are available for mission critical projects. But the rest is mostly nail guns…
That's thereason why I always call myself a Software Developer. It allows me to explain what I do as opposed to the baggage laden "engineer" title.
Depending who I talk to, I use "programmer" or "software engineer" most often.
Re: Requirements volatility is the core problem of software engineering
#86I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".
> I often hear people say that software engineering is a joke compared to civil engineering ... I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do. And it looks like everyone is pushing…
If it were so easy, then we would have done it already that way for the last seven decades. The simile topples over upon further contemplation:
civil engineers:
• client is not a domain expert
• to an overwhelming part, client needs are easy to transport into the mind of c.eng.
• can employ a wealth of standard solutions refined over the course of milleniums
software authors:
• client is a domain expert for the subject matter that the software is supposed to model
• to an overwhelming part, client needs are difficult to express and transport into the mind of s.auth.
• if a standard solution exists, the client would have already bought it off the shelf, so coming to a s.auth. always means customised development
• the entire sector is still in its proverbial baby shoes
We have to come to grips that we unfortunately can't apply what happens to work well for a different sector. The supposed value of non-traditional software methodology lies in that at least the client notices that the requirements are off the needs rather early.
Re: Requirements volatility is the core problem of software engineering
#87Earlier quoted context omitted.
> I often hear people say that software engineering is a joke compared to civil engineering ... I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do. And it looks like everyone is pushing…
> instead of sitting down and figuring out the actual requirements first like any real engineering job If it were so easy, then we would have done it already that way for the last seven decades. The simile topples over upon further contemplation: civil engineers: • client is not a domain expert • to an overwhelming part, client needs are easy to transport into the mind of c.eng. • can employ a wealth of standard solu…
So instead of pushing for more effort & skill for up-front planning and modelling of the requirements and design (and trying to employ modelling tools & formal methods), we're just like fuckit nah let's just implement something and see where that leads us.
It doesn't help that so many of the up-front design failures were not examples of engineers screwing up but sales people selling shit and then having engineers cook it.
We'll be stuck in baby shoes for a long time with this approach.
Re: Requirements volatility is the core problem of software engineering
#88I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".
Re: Requirements volatility is the core problem of software engineering
#89I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".
> I often hear people say that software engineering is a joke compared to civil engineering ... I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do. And it looks like everyone is pushing…
And even when you do have a solid market-fit figured out, you still don't know what your customers will actually want. (And don't get me started on customer research. People lie all the time, and their accuracy on what features are honest-to-$deity blockers.. Nope.) This means that for most parts the incentives are misaligned and work actively against delivering high-quality software.
Underlying the agile manifesto is the need for engineering to be properly aligned with business incentives. Continuous delivery, fast iteration cycles, incremental improvements and rapid deployments are all facets of the same fact: you don't actually know what your customers want (because your customers don't know what they want!), and the only true way to figure it out is to iterate as fast as you can.
It's only when you have an established moat and a practically guaranteed, net-profitable income stream, when you can even imagine at having the opportunity of doing things the way you would assume you want to.
Oddly enough.. the companies who have such moats and guaranteed profits tend to be the same ones that have been the slowest to modernise themselves. Banks - until the modern online-only challengers came along. Insurance, where the regulatory moats are even higher and is only now being "disrupted". Loan brokering. Energy. Water. Public transport (where monopolies and/or charters prevent competition). Healthcare. On and on and on...
And even then, every one of these established, guaranteed-profit machines has the same problems: the moment one good new player enters the field and starts stealing customers, the old guard needs to find a way to either adapt - which is the best-case scenario - or rely on their power structures with politicians and quickly require new regulations to strangle the usurpers.
Software is expensive to make. It's only cheap to deliver. And time spent making the wrong thing is really expensive.
EDIT: I forgot to say this the first time around. Engineering career incentives are also misaligned. Maintenance is not appreciated, only shipping new stuff is. So the developers who would want to improve what exists and make it better will be looked down upon. The promotions and raises go to those who ship something new, even if it ends up setting the world on fire a year later.
Re: Requirements volatility is the core problem of software engineering
#90Earlier quoted context omitted.
> I often hear people say that software engineering is a joke compared to civil engineering ... I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do. And it looks like everyone is pushing…
Goddamn, this is exactly the sentiment I have about software development. Because it's not about bridges or tunnels, common sense is thrown out of the window, people start building something they conjure out of thin air. Few people say 'No!', we don't do anything. Anything. Until we have written a clear business case / usecase, a raison d'être for this project. Agile is often abused to not think, not design and just…