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

51–60 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#51

Post by cameronbrown »

catmanjan wrote: post #46
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 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

#52

Post by TheOtherHobbes »

chrstphrknwtn wrote: post #49
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

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 and glue.

Engineers have never done themselves any favours with the "engineering" label. In many countries, especially English-speaking ones, the job doesn't get the respect it deserves.

Most people have no idea what the job involves. They literally think it means someone with an oily rag who fixes cars and/or computers and/or drives big machines around to make bridges and tunnels and such - like a house builder, but on a bigger scale.

Re: Requirements volatility is the core problem of software engineering

#53

Post by Noumenon72 »

lifeisstillgood wrote: post #50
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.

My view is software is literacy not engineering or science. It tends to make more sense for me. A book that starts out as a romance is just as hard to convert to a spy thriller half way through as a bridge and a tunnel (Ok not total effort but in terms of percentage of rework)

I think you mean "literature".

Re: Requirements volatility is the core problem of software engineering

#54

Post by temac »

Just to nitpick, there are counter examples of finished but not abandoned software. As usual, Tex comes to mind.

Or they just could. E.g. we could probably take the current Python 3 and freeze it and debug it for 20 years, at which point it would be basically finished, and maintenance could still continue (but way much less would be needed)

IMO a good part of requirement volatility is a self inflicted wound. Some are essential, of course, but some changes are for the sake of changing and giving PM, UI, and software engineers jobs, and I even don't know lot of people who appreciate too many gratuitous changes in e.g. software GUI.

My general advice is to slow down. And fucking finish things before starting new ones. We don't let half-constructed bridges around just because we start to build new ones with fancier materials.

Re: Requirements volatility is the core problem of software engineering

#55

Post by klowner »

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.

Too many companies taking a "McMansion" approach to software and we wonder why everything is constantly broken.

Re: Requirements volatility is the core problem of software engineering

#56

Post by lifeisstillgood »

Noumenon72 wrote: post #53
lifeisstillgood wrote: post #50

Earlier quoted context omitted.

My view is software is literacy not engineering or science. It tends to make more sense for me. A book that starts out as a romance is just as hard to convert to a spy thriller half way through as a bridge and a tunnel (Ok not total effort but in terms of percentage of rework)

I think you mean "literature".

Yeah. I use the term software literacy a lot so my bad

Re: Requirements volatility is the core problem of software engineering

#57

Post by temac »

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…

The funny thing is that most people never even attempt to do that, and then still manage to complain about it being impossible.

Yes in some projects that can be harder, but I'm not buying the ambiant: "in most projects". I actually think in that in most projects, a good part of requirement analysis can be put upfront, and of course a tiny bit will still evolve, but not enough to prevent doing things properly.

That does not impose to have too long projects, btw. Just cut them in phases and/or pieces. Feedback cycles are important, but this is still an equilibrium, and in some projects I don't see how 2 weeks feedback cycles without proper requirement engineering would be any good.

Maybe one problem of software development is that it is an ever growing industry, so the mean programmer is always young and inexperienced. Maybe things will be less impulsive with the eventual end of that growth.

Re: Requirements volatility is the core problem of software engineering

#58

Post by chiefalchemist »

The two most common patterns I've experienced:

1) Poorly communicated goals. Sometimes not communicated at all. If you don't know where you're head and _why_, it's damn near impossible to get there.

2) Wants being confused with actual business needs.

3) Clients / stakeholders not able or willing to put in the time for essential discussions and critical decisions.

Re: Requirements volatility is the core problem of software engineering

#59

Post by j1elo »

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 think it is possible to convert a bridge into a tunnel, to follow with your extreme example.

It's totally possible. The only thing is that when the cost estimation arrives to the hands of decision makers, they open their eyes wide and decide that for that money they better go ahead with a bridge.

So IMHO it's just a matter of cost. Say you go with a bridge but there are some initial wooden stairs, and sometime along the middle of placing them they decide it is acceptable to pay the cost of stopping and replacing them with metallic ones. Could happen.

Biggest change I experienced in the rate of unexpected last-time feature changes in software, was having a project manager that first of all knew how to say "No" (or discuss the sense of the requests), and secondly, was able to communicate the real cost that each change would have (in terms of developer time, which at the end of the day means money). Then it would be the company's boss himself who would decide to discard the most crazy changes that were "mandatory" and coming from the sales people.

Re: Requirements volatility is the core problem of software engineering

#60

Post by matsemann »

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…

I have worked on huge government projects that has been specced and planned for years before arriving at my team's desks. It takes a few days before we will have questions. Things not defined good enough, inconsistencies, glaring holes etc.

I think having all reqs upfront is a utopia that will not happen. Those projects I was involved in would have been better if the reqs and scope was done in conjunction with us implementing it.

Post reply on HN