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

171–180 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#171

Post by moron4hire »

After 50 years of activity in attempting to improve software project metrics with little to no improvement, we have to admit that we've been looking in completely the wrong place for effective change.

It's not how the developers work that is the problem. We've changed languages, team sizes, project cycle lengths, everything. Except one thing.

The one thing in common with all of these failed software projects is corporate, top-down management. I would say it's even gotten worse, to counterbalance the real productivity improvements we have actually gained from improved tools. You look at all the companies that can deliver software on time and budget and they have one thing in common: they aren't ran by Harvard MBAs. You look at all the once-great companies that eventually faded away into obscurity and they also have one thing in common: imposition of MBA-imposed corporate management structure to "cut costs" (aka, "throw out the baby with the bathwater"). It killed Bell Labs. It killed Xerox PARC. It killed Apple once, which then was reborn from its own ashes, and is in the process of killing Apple again.

It's impossible to be a great developer in an environment that denies that there can be unique skills and knowledge to individuals. Anywhere developers are "resources" they will be treated as interchangeable cogs.

Re: Requirements volatility is the core problem of software engineering

#172

Post by moron4hire »

jayd16 wrote: post #167
moron4hire wrote: post #156

Earlier quoted context omitted.

Most software projects are nowhere near the scope of a suspension bridge, and the DOM is certainly a lot higher level than "building by hand". Your analogy is terrible.

Hyperbolic perhaps but the idea that civil engineers don't or shouldn't use tools, tooling, or abstraction is bizarre.

And that is my point. The DOM is a tool.

Re: Requirements volatility is the core problem of software engineering

#173

Post by bostik »

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…

Agile as a named methodology may date to 90s, but the concept of rapid iterations, incremental improvement, and constant feedback cycles has been on the books since at least 1950s.

The last time[0] I vented on the subject, I had to dig out the research papers I keep on my desk, because there was more than passing curiosity. Oh yes. I keep these on my desk so I can quote them when needed.

Check out this research paper from your nearest sci-hub entry point:

- DOI: 10.1109/MC.2003.1204375 ; "Iterative and Incremental Development: A Brief History"

---

0: https://news.ycombinator.com/item?id=20563125

Re: Requirements volatility is the core problem of software engineering

#174

Post by qznc »

dev_hacker wrote: post #88
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 there is more to it than process. I'm not an engineer, but I know in the US you usually have to pass the PE exam to be a real certified engineer, plus there is the reality that if your bridge collapses, you are liable, might go to jail, etc. I'm unaware of any similar licensing process in software engineering or liability realities. Even when software kills people, it is usually not prosecuted and the devs ar…

If you build safety-critical software you certainly have some liability.

Re: Requirements volatility is the core problem of software engineering

#175

Post by erik_seaberg »

vvanders wrote: post #143
salty_biscuits wrote: post #65

Earlier quoted context omitted.

As someone who has worked in both worlds, it is just a different sort of nonsense that you have to deal with. Typically the physical engineering thing is "we want you to work out why this weird thing is happening, then fix it, without us having to change anything operationally or spend any money." just a different flavor of the same crap.

A coworker of mine once described engineering as "the ability to design something that can be built for $1 that would normally cost $20".

Any clod can make a bridge stay up, your job is to make a bridge just barely stay up.

Re: Requirements volatility is the core problem of software engineering

#176

Post by WalterBright »

That's true of any form of engineering, not just software. Requirements change because circumstances constantly change, and people simply are unable to imagine it completely beforehand. One has to build it and try it out.

As software engineers, we build things to be adaptable to change. That's why it works to build things out of encapsulated components.

Re: Requirements volatility is the core problem of software engineering

#177

Post by cecilpl2 »

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…

Here's another good example: what is the correct way to order multiple adjectives in English? If you are a native speaker, you probably don't have any idea, you just know that you say "an old big brown cardboard fridge box", rather than "a cardboard brown fridge old big box". The order is very specific and any deviation is obviously incorrect. Try it for yourself!

But any ESL student can tell you the order is quantity, opinion, size, age, shape, color, origin, material, purpose. We'd had to reverse-engineer the rules, and then teach it to newcomers.

Re: Requirements volatility is the core problem of software engineering

#178

Post by ellius »

As an addendum to this, I would frame the problem as "complexity," one aspect or symptom of which is requirements volatility.

Complexity comes from two sources in software projects. The first is the domain. As other commenters have pointed out, domain experts are usually half-aware of their domain requirements because much of the complexity has been buried under their expertise and intuition. Domain requirements also inherently change over time as markets, professional standards, and technology evolve. So the process of development involves a shifting discovery of new aspects of the domain as things which were unconscious become consciously learned.

The other aspect of complexity is the technology applied to the problem. Computer technology is inherently complex, and the imperfect mapping between domain problems and technology adds a third angle.

The best books I've seen for dealing with these problems are "Clean Architecture," "A Philosophy of Software Design," and "Principles of Product Development Flow." The first two explain how to build good systems that encapsulate complexity and are geared towards changeability. Such systems are flexible as new aspects of domain complexity are discovered over time. The latter book takes a higher level view of how to design projects to cope with the discovery process in a way that is economically viable and justifiable to the people financing projects, and also in a way that arranges work so that developers can actually be productive and not become swamped by the complexity problem or bad processes and practices.

Re: Requirements volatility is the core problem of software engineering

#179

Post by carapace »

michaelhoffman wrote: post #141
scruple wrote: post #135

Earlier quoted context omitted.

> One difference is that a license is required to practice civil engineering. I've often wondered about this. Who exactly has to be licensed? Are there management layers in civil engineering firms where the license isn't required? I think my point is pretty easy to follow. I'd love for all of us to be licensed to practice software engineering, but I don't hold any hope that it would fix all of the other compounding p…

There are checkpoints in civil engineering projects that can't be passed without a professional engineer affixing their official seal to a document. If you are a professional engineer and you are found to have done this improperly you will lose your license, which is way worse than being fired because you won't be able to get a job anywhere else either. And civil engineers are indoctrinated into their field's ethics…

> And civil engineers are indoctrinated into their field's ethics culture with lots of reminders of how many people died when current practices were not followed.

E.g. the Iron Ring: https://en.wikipedia.org/wiki/Iron_Ring

> The Iron Ring is a ring worn by many Canadian-trained engineers, as a symbol and reminder of the obligations and ethics associated with their profession. The ring is presented to engineering graduates in a closed ceremony known as the Ritual of the Calling of an Engineer. The concept of the ritual and its Iron Rings originated from H. E. T. Haultain in 1922, with assistance from Rudyard Kipling, who crafted the ritual at Haultain's request.

> The ring symbolizes the pride which engineers have in their profession, while simultaneously reminding them of their humility. The ring serves as a reminder to the engineer and others of the engineer's obligation to live by a high standard of professional conduct.

I didn't see it mentioned in the Wikipedia article, but i was under the impression that the first of these rings were made from the iron of a bridge that failed.

Re: Requirements volatility is the core problem of software engineering

#180

Post by tigerlily »

cecilpl2 wrote: post #177
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…

Here's another good example: what is the correct way to order multiple adjectives in English? If you are a native speaker, you probably don't have any idea, you just know that you say "an old big brown cardboard fridge box", rather than "a cardboard brown fridge old big box". The order is very specific and any deviation is obviously incorrect. Try it for yourself! But any ESL student can tell you the order is quantit…

Then it must be "big old brown cardboard fridge box".
Post reply on HN