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

231–240 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#231

Post by qznc »

wpietri wrote: post #182
qznc wrote: post #166

Earlier quoted context omitted.

There are plenty of embedded systems which hit 1.0 and stayed there for years and decades.

In that case, I hope somebody points me at a few of them. My guess is that if we look at the circumstances, they won't hold a lot of lessons for us. As an example, the IRS is still running 60-year-old code: https://www.nextgov.com/it-modernization/2018/04/irs-60-year... Is that because that code and hardware is especially good? Because the initial design and research process was so perfect that people are still entir…

There is no secret. You develop a process, enforce it, and refine it. It becomes bureaucratic, expensive, and boring. Just like the civil engineering people compare against here.

The process is nothing surprising. Write tests, document your code, follow the style guide, etc.

Re: Requirements volatility is the core problem of software engineering

#232

Post by JoeCamel »

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.

To clarify, I use "programmer" when speaking to very non-technical people, usually elderly. Many other languages have a similar word but it might have different connotations, for example, be less negative (pejorative).

Re: Requirements volatility is the core problem of software engineering

#233

Post by qznc »

bostik wrote: post #173
clarry wrote: post #147

Earlier quoted context omitted.

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

Fully agree. I wrote myself a summary at some point: http://beza1e1.tuxen.de/waterfall.html

Re: Requirements volatility is the core problem of software engineering

#234

Post by elteto »

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…

I hope this myth would die. Most engineers don’t ever take a PE exam.

The PE exam is only needed for a handful of disciplines, like civil and HVAC engineering. Even then, you only need the PE certification if you are going to be signing legal documents. You can be a civil engineer without a PE working in a team producing designs and plans that are signed by a single certified PE.

By your logic almost no one that graduated from an engineering discipline would ever be able to call themselves engineer.

Re: Requirements volatility is the core problem of software engineering

#235

Post by kqr »

ntsplnkv2 wrote: post #201
corebit wrote: post #140

Earlier quoted context omitted.

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…

That said, social media and targeted advertising is used to cause far greater (and more subtle) damage, like polarising opinion and influencing elections. Not to mention common patterns of social media usage (which we have developed and incentivised) are proven to strongly correlate with lower quality of life. (I vaguely remember a causal link too, but I won't say that for sure without a reference.)

A bridge hosts what? 400 people at worst (i.e. when there äre passenger trains on it.) Social media easily hosts 400 thousand or million people.

The single bridge-collapsing event is very dramatic and visceral, but digital platforms allow us to cause damage and death by a thousand cuts.

Re: Requirements volatility is the core problem of software engineering

#236

Post by kqr »

api wrote: post #144
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…

One huge issue with introducing licensing in software engineering is the fact that there are a great many very competent self taught software engineers. This breaks the conventional model of how licensing works with its close coupling to university degree programs. The reason you see so many autodidacts is that its one of the few engineering fields where tinkering is both cheap and safe. Civil engineers basically can…

> One huge issue with introducing licensing in software engineering is the fact that there are a great many very competent self taught software engineers. This breaks the conventional model of how licensing works with its close coupling to university degree programs.

Uncle Bob argues that this is why we need to start self-policing and create certification structures that take this into account.

If we don't, the next software-related disaster will force governments to set up regulatory structures the only way they know how -- tied to university degrees. They won't understand the value of a self-taught developer.

We do. We should be the ones to create structures in which such people can be officially recognised for their abilities.

Re: Requirements volatility is the core problem of software engineering

#237

Post by hwayne »

Hendrikto wrote: post #68
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?".

> We don't know exactly what weight it should support yet Or where it should be exactly: "It should be easy to move once it is build, right?" Or what type of vehicles it should handle: "Just build a generic bridge. How difficult can it be." But the time and monetary budget was already negotiated and written in stone: "Oh btw, you got 2 weeks and $537.25 to finish the bridge."

I've met at least two engineers who had to move bridges after they were built.

Re: Requirements volatility is the core problem of software engineering

#238

Post by hwayne »

pilif wrote: post #70
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?".

And no civil engineer will ever have to deal with the update to Gravity 2.0 now even better at 10m/s2

And software engineers don't have to deal with half their tensile bolts having 90% of the tensile strength built they don't know which half, or the bridge collapsing because they mixed brass and zinc bolts[1], or hurricanes...

Turns out that every field of engineering is hard!

[1]: https://www.fastenal.com/en/70/corrosion

Re: Requirements volatility is the core problem of software engineering

#239

Post by hwayne »

nhumrich wrote: post #98
clarry wrote: post #72

Earlier quoted context omitted.

> I often hear people say that software engineering is a joke compared to civil engineering ... I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do. And it looks like everyone is pushing…

Thats because we have tried it the other way. Its called waterfall. The problem is, the process is too slow in such a fast moving industry. If you are building a bridge, you dont have the problem of being half way done and all your customers say, "nah, nvm there is tunnel that just went up, that can kind of solve my needs. I will use that one instead."

Have you talked to civil engineers? I have. This happens all the time.

Re: Requirements volatility is the core problem of software engineering

#240

Post by hwayne »

As part of a project I interviewed a lot of "crossovers": people who worked as both traditional engineers and software engineers. According to everyone I talked to, requirements volatility happens everywhere. Two civil engineers had to move a bridge. One "system engineer" worked for Boeing and was part of a team who's only job was to figure out how to reconcile existing work whenever they changed requirements.
Post reply on HN