Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Requirements volatility is the core problem of software engineering

stackoverflow.blog

Post reply on HN
Print view View original

71–80 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#71

Post by 1234_UUUU_99 »

cameronbrown wrote: post #51
catmanjan wrote: post #46

Earlier 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.

> It's not so easy to build bridges that way.

I'd wager that it is but the stakes for failure are too high to wing it (hopefully).

Imagine:

We want to build a bridge that spans N meters. We don't know how to do it but we can go look at an existing bridge and copy it. We might not understand metallurgy / physics that well, but we talk to suppliers and ask for "steel of this shape and size". Ditto cables, concrete and everything else.

Probably, provided we're not scaling up or changing the design too much, it would work just fine.

Re: Requirements volatility is the core problem of software engineering

#72

Post by clarry »

kabes wrote: post #45

I 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 it more into this ass-first direction with agile. Let's not even try to plan ahead! You know what you want next week, so this short-sighted focus leads to chaotic development and once the real requirements are figured out 9 months into the project, well too bad it's too late to redesign and rewrite it all properly. So it's forever going to be a bumpy and crooked bridge on the verge of collapse, held together by more and more duck tape, hot glue and occult ceremony. And there's a plastic tunnel hanging underneath it. Only the brave will crawl through.

Re: Requirements volatility is the core problem of software engineering

#73

Post by 1234_UUUU_99 »

meagain3 wrote: post #66
chrstphrknwtn wrote: post #49

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.

Real engineers in north America must write technical and ethical exams, have at least 4 years of continuous and proved experience before they can call themselves engineers. Is indeed sad that people with no knowledge of thermodynamics or strength of materials can call themselves engineers as well...

I guess you're making the distinction between professional and non-professional engineers?

There's not really the class divide in engineering fields that you're suggesting. I have a brother who is an ME, designs power plants (the building sized ones) and is not "professional".

I asked him about it and he said it wouldn't change his role or his salary, so he never bothered going through the process. IIRC there's one person on the team who is, for whatever formalities are required.

Re: Requirements volatility is the core problem of software engineering

#74

Post by jefftk »

EliRivers wrote: post #40

The only software project I ever worked on in which the customer didn't report so much as a single bug had the requirements done properly, up front, and agreed all round. Of the thousands of identified requirements, I think less than ten changed over the lifetime of the project, and each change underwent significant examination for consequences. The project was waterfall all the way. The quality of software that can…

"Take a government contract I worked on years ago. It is undoubtedly the most successful project I’ve ever worked on, at least from the standpoint of the usual project management metrics: it was completed early, it was completed under budget, and it completed a scheduled month-long acceptance test in three days.

This project operated under some unusual constraints: the contract was denominated and paid in a foreign currency and was absolutely firm fixed-price, with no change management process in the contract at all. In fact, as part of the contract, the acceptance test was laid out as a series of observable, do-this and this-follows tests that could be checked off, yes or no, with very little room for dispute. Because of the terms of the contract, all the risk of any variation in requirements or in foreign exchange rates were on my company.

The process was absolutely, firmly, the classical waterfall, and we proceeded through the steps with confidence, until the final system was completed, delivered, and the acceptance test was, well, accepted.

After which I spend another 18 months with the system, modifying it until it actually satisfied the customers needs."

Re: Requirements volatility is the core problem of software engineering

#75

Post by tsss »

TheOtherHobbes wrote: post #52
chrstphrknwtn wrote: post #49

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…

But how many mech/civil engineers actually do any math beyond napkin calculations in their day-to-day work? It's way too complicated and all the math is now done by computers. In fact I'd argue that outside of research more computer scientists are doing mechanical engineering math than actual mechanical engineers, because they have to write the CAD software that the latter use. At the end of the day the vast majority of mechanical, civil, electrical engineers and computer scientists work on stuff that doesn't require math at all.

Re: Requirements volatility is the core problem of software engineering

#76

Post by richie5um »

drenginian wrote: post #11

It’s not a problem of software engineering, it’s a property of software engineering.

100% agree. I realised many years ago that to try to restrict/fix requirements was futile - or, you can try, but to what end. It’s like swimming upstream.

The hard part is that being adaptive to change increases the complexity exponentially with size (of project, of people, etc...).

Therefore the only way out of this formula is to reduce ‘size’, and iterate with (/alongside) the customer (even if that is an internal _customer_).

It is basic math(s).

Re: Requirements volatility is the core problem of software engineering

#77

Post by Slikey »

pilif wrote: post #70
kabes wrote: post #45

I 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?".

And no civil engineer will ever have to deal with the update to Gravity 2.0 now even better at 10m/s2

So much this. I want a civil engineer try and build a bridge over 6 tectonic plates with pretty much all physical constants constantly changing. That would be the equivalent of working with an ever moving tech stack.

Even the language and best practise change constantly. Looking at possibly the most stable language C, we have entirely different best practise pattern from community to community.

Re: Requirements volatility is the core problem of software engineering

#78

Post by louwrentius »

clarry wrote: post #72
kabes wrote: post #45

I 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…

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 follow the whims of the customer. Nice for billable hours, but long term?

Do you produce anything of value?

Re: Requirements volatility is the core problem of software engineering

#79

Post by [deleted] »

TheOtherHobbes wrote: post #52
chrstphrknwtn wrote: post #49

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…

[deleted]

Re: Requirements volatility is the core problem of software engineering

#80

Post by JoeCamel »

TheOtherHobbes wrote: post #52
chrstphrknwtn wrote: post #49

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…

* "Engineering is the use of scientific principles to design and build machines, structures, and other items"

* Mathematics isn't only about calculation and applied physics. When you write a simple algorithm and convince yourself with a logical argument about its correctness, time complexity, etc. that is math too. You also do calculations when you design various systems (latency, throughput, etc.)

* I know a dozen mechanical, structural, and electrical engineers. They almost never model anything from first mathematical principles, they use well known tools and methods they learned. Their "nail guns and glue". Actually I think most of them don't understand math/physics behind it very deeply. So even if those methods are underpinned with mathematics and physics, it's abstracted away most of the time which is good for practical purposes.

Even in "user-interface programming", I often had to use math, algorithms, etc. In other parts of software engineering I used it much more.

Post reply on HN