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

111–120 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#111

Post by AndrewKemendo »

rossdavidh wrote: post #108

I am reminded of how linguists, when trying to document a language from one of the last living native speakers, don't just ask them to tell them the rules of it. They have to task questions like "how would you say this?" Then they try to reverse-engineer the grammar, syntax, etc. In most cases, the people who are giving the requirements either: 1) don't actually know them (e.g. they are in upper management but the so…

Seems like that's why startups with a founder that is solving their own problem are more successful than ones doing otherwise.

Re: Requirements volatility is the core problem of software engineering

#112

Post by BlueTemplar »

JoeCamel wrote: post #85
arvinsim wrote: post #81

Earlier quoted context omitted.

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.

What does the word "developer" mean to other people? If you want to keep it simple, why not "programmer"? Depending who I talk to, I use "programmer" or "software engineer" most often.

Programmer might mean technician too.

Re: Requirements volatility is the core problem of software engineering

#113

Post by BlueTemplar »

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

Huh, I had no idea... So the other people are literally amateur engineers?

Re: Requirements volatility is the core problem of software engineering

#114

Post by BlueTemplar »

jokoon wrote: post #44

This quote is old and explain very well why early software was often high quality: > “Walking on water and developing software from a specification are easy if both are frozen.” ― Edward V. Berard The more you plan ahead and the less you change goals while writing software, the less problems you have. Software is the only field of engineering where you can change things at any point in time. But it doesn't mean you H…

The ongoing discussion in the EU about a legal obligation of X years of update support comes to mind...

Re: Requirements volatility is the core problem of software engineering

#115

Post by PavlovsCat »

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

They don't forget that, that's why they say it's a joke to compare it to actual engineering. Try treating an civil engineer that way, say "we actually wanted a tunnel". If they have the means to, they might sue you into the ground, and if they had the clout and publicity, no other civil engineer, ever, will work for you. Not in 5 years and not in 20, not until you made super clear you changed. In software dev, you just wrap the stupid or dishonest thing in a new euphemism and go harvest a new batch of suckers, with zero real repercussions.

I saw this yesterday and didn't know if I should laugh or cry, starting from the jingle at the very start of the video: https://www.youtube.com/watch?v=YJGCZCaIZkQ&t=20m06s Imagine an architect conference where a vendor proudly expains how in a building the average tenant lifespan increased a lot -- after their automatic turret was moved from lobby to a less frequented room in the basement. I know that's the opposite of a hardcore SW engineering talk, but still. Everybody wants to be nice, nobody wants to get blacklisted, kool-aid makes the dissonance go away. The main issue was that Linus sometimes called people idiots, and that's solved now.

Maybe other professions also started out this way, as cliques of fools making policy based on what they dreamed last night or how the birds flew, with the main driver being greed -- but being hundreds of even many thousands years more developed, they are on a totally different level than software engineering is today, and just calling it something noble and serious doesn't make it so.

Re: Requirements volatility is the core problem of software engineering

#116

Post by mewpmewp2 »

clarry wrote: post #87
bmn__ wrote: post #86

Earlier quoted context omitted.

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

I agree it's not easy, but instead of trying harder to become good at it, it seems like this industry in its proverbial baby shoes threw a tantrum and decided that it doesn't want to learn at all. 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 somet…

Didn't we start by trying to plan ahead? There's a reason we have moved to agile.

In software if you know what you are doing ahead of time you are not really innovating and you might as well be using an existing system. Since everything that is standardised you can just use as libraries.

When building bridges, you can't just use a library that's .buildBridge(...parameters), even though similar things have been done thousands of times before. With code, if something is done enough times that you know how to plan for it, it is likely already a library.

You can plan building a bridge since you have done that and have experience of it thousands times over.

Re: Requirements volatility is the core problem of software engineering

#117

Post by BlueTemplar »

bostik wrote: post #20

The article mentions how one part of change is that regulations may have changed. I work in a heavily regulated industry, and am dealing with a set of regulators nearly all who depend on just one particular auditing company to ... effectively write their regulations for them. To the point where a new jurisdiction happily refers to their draft regulations as documents prefixed with the auditing firm's name on them. (T…

Understanding and evaluating the problem is the main job of an engineer?!? (Compared to a technician...)

Re: Requirements volatility is the core problem of software engineering

#118

Post by pbhjpbhj »

Is it primarily requirement volatility, or primarily ill-defined requirements? (If it's the later, that's some super-irony.)

That would explain at least a couple of further issues mentioned here. Like rewrites: software doesn't always define it's own outcomes well; the requirements don't change they're just poorly defined.

Requirements changing, and feature creep are subtly different too -- with static ill-defined requirements features could change as the requirements in a particular facet of the software become more clearly mapped out further on in the project.

For example, in the Berlin airport situation (in a comment here), adding a new floor could be due to a realisation that a static requirement for floorspace want going to be obtained, because (say) a static requirement for through-flow hadn't been fully defined and expanding the capacity to meet that requirement then limited the available floorspace. None of the requirements needs to have changed.

Perhaps that's to much of a philosophical distinction.

(Not a [software] architect, or project manager or anything, feel free to tell me I'm talking rubbish.)

Re: Requirements volatility is the core problem of software engineering

#119

Post by eropple »

Slikey wrote: post #77
pilif wrote: post #70

Earlier quoted context omitted.

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.

This is hyperbolic. Plenty of completely reasonable tech stacks are over ten years old. You could have started writing a web application in TypeScript, my current language of choice, over five years ago. I can go write a web application in React and Spring Boot (which I also like) that's almost completely recognizable, and could have been carried forward from the state of the art of, 2014. Much older, in terms of the backend; Spring Boot is relatively new but it still uses the Spring that somebody might know from 2010 and builds very incrementally from there. Even that noophile bug zapper, Golang, is most of a decade old now.

New stuff shows up, but that doesn't mean you are compelled to leap upon it.

Re: Requirements volatility is the core problem of software engineering

#120

Post by BlueTemplar »

temac wrote: post #57
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 do…

The number of feedback cycles is pretty much what defines waterfall vs agile.

And it's hard do do a proper waterfall when you hardly have an idea of how to even approach the problem.

Post reply on HN