Requirements volatility is the core problem of software engineering • Hacker News Board

Re: Requirements volatility is the core problem of software engineering

#201

Post by ntsplnkv2 » Sat, Feb 22, 2020, 8:15 PM UTC

corebit wrote: post #140

austincheney wrote: post #137

Earlier quoted context omitted.

My uncle is a senior partner in a major civil engineering firm and my wife’s best friend is a civil engineer. Everybody who practices civil engineering in Texas must be licensed to be employable. Maybe you could intern without a license, but you wouldn’t be involved with any project related work.

You've just changed the word without actually defining anything. What constitutes practicing? What stops one licensed engineer approve a design nominally created by thousands of unlicensed lower engineers?

Ultimately accountability.

There's a reason we have hard standards for being a PE or an MD. If you just let anyone do it you risk many problems.

Most software simply isn't like this. The valley loves talking about disruption and all and how world changing everything they do is, but the fact of the matter is social media isn't killing anyone like a failed bridge would or a person who isn't qualified as a doctor. Most of the money made in the valley is off of advertising or data. Who cares if the product is shitty? people don't die. rich people make a little less money.

Re: Requirements volatility is the core problem of software engineering

#202

Post by raiflip » Sat, Feb 22, 2020, 8:25 PM UTC

clarry wrote: post #147

mewpmewp2 wrote: post #116

Earlier quoted context omitted.

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

> Didn't we start by trying to plan ahead? There's a reason we have moved to agile. "Everything was waterfall and then came agile" is myth, but yes, it looks like it's fashionable to no longer try to plan ahead. I'm not convinced the reasons are good, and I'm not convinced the craft of planning ahead was ever perfected to the point that anyone could say it doesn't work. Scrum, XP, Agile all date back to the 90s when…

The binary thinking in this thread strikes me as odd. Is it bad to try and plan everything 6 months ahead of time? Yes. Is it also bad to fly by the seat of your pants and only plan 1 week ahead? Also yes. Instead, why don't we plan out by some intermediate time period. Say, 3, 4 weeks ahead of time. Or whatever time horizon ends up being the most efficient.

Re: Requirements volatility is the core problem of software engineering

#203

Post by andrewflnr » Sat, Feb 22, 2020, 8:33 PM UTC

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.

"Developer" is appropriately diffuse in its meaning. It includes all the steps of making software happen, requirements gathering, critical thinking thereon, etc. "Programmer" can sound like just "guy what taps on the keyboard". It can even be faintly perjorative in some contexts.

I'd use "software engineer" if I could in good conscience, but "software developer" is pretty neutral while still being accurate.

Re: Requirements volatility is the core problem of software engineering

#204

Post by temac » Sat, Feb 22, 2020, 8:43 PM UTC

BlueTemplar wrote: post #129

temac wrote: post #54

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…

I guess that slowing down doesn't pay well in an industry where a startup can get from zero to billion in a few years?

Probably that plays a role. However, not everything is a startup. Accumulating technical debt during even just a few years like there is no tomorrow is also a non negligible risk. You can also go from billion to zero in a few years...

Re: Requirements volatility is the core problem of software engineering

#205

Post by robocat » Sat, Feb 22, 2020, 8:45 PM UTC

Nasrudith wrote: post #188

robocat wrote: post #36

Don”t rewrites also fail all the time, even if requirements are not expanded? Rewrites would mostly be successful by the articles premise.

Well rewrites have two conflicting goals - simplifying the code/improving performance and consistency with the old version. Even if the requirements are nominally the same "unwritten" ones pop up

Sure, but “unwritten” requirements pop up all the time for any requirements, so the two situations are still broadly equivalent.

Re: Requirements volatility is the core problem of software engineering

#206

Post by PopeDotNinja » Sat, Feb 22, 2020, 9:06 PM UTC

austincheney wrote: post #121

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

As a web developer with 20 years experience I would argue that one web SPA project is more similar to the next than comparing two bridges and developers still can’t figure it out. One difference is that a license is required to practice civil engineering. Most web developers, on the other hand, require large tools to do theirs jobs for them and recoil in irrational fear and disgust when standard DOM methods are used.…

Also, people spend many millions on bridges. People want a clone of pick-a-software-something for less than 5 figures.

Re: Requirements volatility is the core problem of software engineering

#207

Post by ethanwillis » Sat, Feb 22, 2020, 9:16 PM UTC

jayd16 wrote: post #155

austincheney wrote: post #121

Earlier quoted context omitted.

As a web developer with 20 years experience I would argue that one web SPA project is more similar to the next than comparing two bridges and developers still can’t figure it out. One difference is that a license is required to practice civil engineering. Most web developers, on the other hand, require large tools to do theirs jobs for them and recoil in irrational fear and disgust when standard DOM methods are used.…

>Most web developers, on the other hand, require large tools to do theirs jobs for them and recoil in irrational fear and disgust when standard DOM methods are used I would recoil in disgust if I saw a civil engineer building a suspension bridge by hand as well.

Abstraction can be good. But this reliance on abstraction that does nothing but obscure problems is a weakness of modern software development. And now we're left with no one who can solve them.

Re: Requirements volatility is the core problem of software engineering

#208

Post by thu2111 » Sat, Feb 22, 2020, 9:35 PM UTC

akiselev wrote: post #196

kazinator wrote: post #158

Earlier quoted context omitted.

A marketing person would add this: you invent first what people then want. In other words, the way to create the requirement for something is to build it, not merely to discover existing requirements. The "build it and they will come" hints at that; it's saying that if you build something, people will see the value and then convince themselves they needed it all along.

"Build it and they will come" is a line from a movie about ghosts playing baseball (or the main character hallucinating), not advice applicable to building products.

"Build a better mousetrap and the world will beat a path to your door" then. That's one my mother used to use a lot.

Obviously a lot of products are built by people who never ask anyone what their requirements are. Often those are the most successful products. Steve Jobs being the apogee of that approach to product design.

Re: Requirements volatility is the core problem of software engineering

#209

Post by thu2111 » Sat, Feb 22, 2020, 9:45 PM UTC

clarry wrote: post #186

moron4hire wrote: post #161

Earlier quoted context omitted.

We tried all that. Formal requirements gathering, modeling tools, the works. It was the SDLC/Six Sigma/ISO9000/vendor-certs-are-substitutes-for-degrees era of the late-90s/early-2000s. And it also didn't work. Often times, it's very easy to determine the functional requirements: "Process this billing statement", "Spit out that report." The complexity doesn't come from the requirements. It comes from the constraints:…

> The complexity doesn't come from the requirements. It comes from the constraints: "We only use this ancient version of this database", "We didn't tell you at the start that the users expect to interface with this system via email". Those constraints sound like requirements: we require that only this ancient version of this database is used. We require that users can interface with this system via email. Different t…

There's another problem not really addressed here; when the requirements you get from the customer are wrong/make no sense/could be done better another way/are for things they won't actually use/are a part of some internal political struggle.

This is something that crops up quite frequently in my work. We'll get a requirement like this: "the app should use HTTP like a web browser, not a different protocol". On inquiry as to why it's so important for something that's not a web browser to so strongly resemble a browser, the answer will be something like, "so we don't have to ask IT to open a firewall port". The person deploying the software could just fill out the paperwork, but they find it easier to "require" that the software sneak past their own corporate security controls. This is the sort of requirement that is real in some sense and not in another sense, depending on whether you define the customer as whoever you're talking to on the phone right now or the business as a whole.

Re: Requirements volatility is the core problem of software engineering

#210

Post by kazinator » Sat, Feb 22, 2020, 9:48 PM UTC

akiselev wrote: post #196

kazinator wrote: post #158

Earlier quoted context omitted.

A marketing person would add this: you invent first what people then want. In other words, the way to create the requirement for something is to build it, not merely to discover existing requirements. The "build it and they will come" hints at that; it's saying that if you build something, people will see the value and then convince themselves they needed it all along.

"Build it and they will come" is a line from a movie about ghosts playing baseball (or the main character hallucinating), not advice applicable to building products.

The line has long since been co-opted for that usage.