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

191–200 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#191

Post by carapace »

The weird thing (IMO) is that computers are already universal machines, so why isn't any programming language already enough for any task?

In other words, why hasn't Excel fully defeated all comers?

It's widely known but seldom appreciated that Excel is the most popular and successful programing language in history. And not just a little. It wins by a large margin. So why do people still pay you and I to "make things go"? (Yes, that's a Pakled reference. https://memory-alpha.fandom.com/wiki/Pakled)

I think to answer this question you have to understand the difference between what we have now and what we could have.

What we have now is a stack: OS, WM, "Desktop" -> Separate "Applications" often with their own GUI (in addition to the OS-provided defaults) -> Web "apps" where anything goes (up to and including "dark patterns" like fake widgets designed to mimic OS-level modal dialogs.) All of this is conceptual overhead that adds nothing to the achievement of the prime tasks (that humans are using computer for in the first place.)

What we could have: I have two examples: The Oberon OS and Jef Raskin's work.

https://inf.ethz.ch/personal/wirth/ProjectOberon/ http://www.projectoberon.com/ Try it live in your browser: https://schierlm.github.io/OberonEmulator/emu.html

https://en.wikipedia.org/wiki/Jef_Raskin https://en.wikipedia.org/wiki/The_Humane_Interface_(Book) https://en.wikipedia.org/wiki/Canon_Cat https://en.wikipedia.org/wiki/Archy

> These ideas include content persistence, modelessness, a nucleus with commands instead of applications, navigation using incremental text search, and a zooming user interface (ZUI).

The core idea is to get "applications" and even modes out of the way, disintermediate as much as possible between the user and the raw computing power of the machine.

In sum, we spend an enormous amount of time and energy working on things that have no intrinsic bearing on the tasks we hope to accomplish, largely due to the lack of awareness that it's possible to dispense with most of what is today considered normal UI. We are "turd polishing".

If you get out of the users' way, they can implement their own requirements.

- - - -

Here's RMS talking about secretaries extending Emacs with Lisp:

> programming new editing commands was so convenient that even the secretaries in his [Bernie Greenberg] office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

https://www.gnu.org/gnu/rms-lisp.html

Re: Requirements volatility is the core problem of software engineering

#192

Post by moron4hire »

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…

A lot of places will never give you access to the people who can answer those questions and will expect you to start work right away and "quit wasting time" or they "put you on a Performance Improvement Plan"/fire you. The problem is not developers doing a bad job, it's management preventing them from doing good job.

Re: Requirements volatility is the core problem of software engineering

#193

Post by Dahoon »

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

>One difference is that a license is required to practice civil engineering

The world would be a better place if developers (or the company they work for) were as much on the hook for bugs in software as en engineer is for a bug in a bridge. How programming can still be the wild west in 2020 is beyond me. I've read some good thoughts about this topic by Poul-Henning Kamp (Varnish, FreeBSD) but can't seem to find it at the moment.

Re: Requirements volatility is the core problem of software engineering

#194

Post by waterlink »

My honest opinion is that software conceptually was created to allow for volatility of the requirements.

If you want to have static requirements (or changing once per 5-10y), then that’s what you have _hardware_ for.

Software has “soft” in the name for that exact reason.

Embrace the constant change.

Re: Requirements volatility is the core problem of software engineering

#195

Post by pbz »

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?

The licensed engineer puts their stamp on that work? If anything happens the licensed engineer is on the hook.

Re: Requirements volatility is the core problem of software engineering

#196

Post by akiselev »

kazinator wrote: post #158
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…

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.

Re: Requirements volatility is the core problem of software engineering

#197

Post by clarry »

moron4hire wrote: post #192
clarry wrote: post #186

Earlier quoted context omitted.

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

A lot of places will never give you access to the people who can answer those questions and will expect you to start work right away and "quit wasting time" or they "put you on a Performance Improvement Plan"/fire you. The problem is not developers doing a bad job, it's management preventing them from doing good job.

Agreed, the industry isn't actually allowing engineers to engineer. https://news.ycombinator.com/item?id=22391047

Re: Requirements volatility is the core problem of software engineering

#198

Post by rossdavidh »

jonahx wrote: post #154
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…

This is spot on and a terrific analogy. There is human behavior and human beings' mental models of that behavior. Your advice generalizes: As an engineer or scientist, never trust the models. At least not wholesale. They're simplified and inadequate, and the inadequacy is invisible to those using them.

Thanks, and good point about the generalization.

Re: Requirements volatility is the core problem of software engineering

#199

Post by rossdavidh »

derefr wrote: post #163
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…

Reminds me of this recent post on the Grammarphobia blog: https://www.grammarphobia.com/blog/2020/02/adjectives-comple... > We wish we could tell you that there’s a predictable pattern here—that certain types of adjectives can always be complemented by both participles and infinitives, while other types are always restricted to one or the other. > Unfortunately, no clear pattern emerges. Different adjectives simply a…

Oof, boy is that true in software requirements as well. Good point.

Re: Requirements volatility is the core problem of software engineering

#200

Post by rossdavidh »

DoingIsLearning wrote: post #142
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…

FIY in Software Engineering this is defined as a formal process with clients or Product Managers called 'Requirement Elicitation'.

Perhaps in some cases it approaches the linguists' approach, but the Requirement Elicitation I have actually witnessed looks more like a group of stakeholders in a room, writing on a whiteboard or something similar. Better is to make an MTP (minimum testable product), and put it in front of the user and have them tell you all the ways it's wrong.
Post reply on HN