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

Re: Requirements volatility is the core problem of software engineering

#181

Post by ClumsyPilot » Sat, Feb 22, 2020, 6:59 PM UTC

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

Yes, I had the option of becoming professionally accredited if I I'd the 4 year instead of the 3 year programm, but its relevance is kinda limited

Re: Requirements volatility is the core problem of software engineering

#182

Post by wpietri » Sat, Feb 22, 2020, 6:59 PM UTC

qznc wrote: post #166

wpietri wrote: post #104

Earlier quoted context omitted.

> figuring out the actual requirements first like any real engineering job would have you do There are no "actual" requirements for most software projects. Software is generally co-evolved with the audience. Bridge designers can work like they do because bridges are hard to change and fundamentally pretty similar. But because software infinitely changeable and infinitely copyable, our field is different. If you're go…

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 entirely happy with it? I'm guessing not.

Re: Requirements volatility is the core problem of software engineering

#183

Post by 29athrowaway » Sat, Feb 22, 2020, 6:59 PM UTC

artsyca wrote: post #31

29athrowaway wrote: post #26

Earlier quoted context omitted.

What comes first, feature creep or agile? I would say that agile has helped create the conditions for the proliferation of tech debt mills, because it empowers product people while disempowering engineers. "Rapid and flexible response to change" is really just bruteforcing ideas leaving a trail of tech debt that makes developers miserable.

You sound like me a couple of years ago until I realized I was the problem the whole while Why was I contributing to this madness when I knew better? So I took the show directly to the client and never looked back I'd love to elaborate but it sounds like you have a journey ahead of you before you can appreciate what I have to say

What you describe makes me think that you pivoted from an engineering role into a product role in order to make agile to work for you. This only reaffirms what I said, because if agile really empowered you as an engineer that transition would not have happened.

Re: Requirements volatility is the core problem of software engineering

#184

Post by Nasrudith » Sat, Feb 22, 2020, 7:05 PM UTC

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…

There is a third issue to licensing that dates back to ancient "law of strongmen" without even lofty claimed principles like divine right, let alone anything worth folllwing of free will; introducing a law that cannot be enforced only breeds contempt for the law. It is hard, expensive, and rare to covertly build infastructure. It isn't the case for software. Just blindly aping it would be draconian and silly.

At best it could be a license for specific safety critical applications but that would be dependent upon the licensed ones actually doing a better job at being safer which is harder for the first two reasons you listed.

Hell certifications are infamous for generally not being that career useful.

Re: Requirements volatility is the core problem of software engineering

#185

Post by __blockcipher__ » Sat, Feb 22, 2020, 7:06 PM UTC

tigerlily wrote: post #180

cecilpl2 wrote: post #177

Earlier quoted context omitted.

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

Incidentally that’s exactly how I would have worded the sentence as a native speaker. But only because “big ol’” is a common phrase by itself

Re: Requirements volatility is the core problem of software engineering

#186

Post by clarry » Sat, Feb 22, 2020, 7:08 PM UTC

moron4hire wrote: post #161

clarry wrote: post #87

Earlier quoted context omitted.

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…

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 term, same thing.

That's in the bucket with the kind of stuff that I'm advocating people should pay more attention to up-front. Gathering these requirements before you start designing anything is a big deal. If you failed to do so, then you failed to do a proper job at the part I called sitting down and figuring out the actual requirements.

Re: Requirements volatility is the core problem of software engineering

#187

Post by amelius » Sat, Feb 22, 2020, 7:08 PM UTC

1234_UUUU_99 wrote: post #73

meagain3 wrote: post #66

Earlier quoted context omitted.

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

I guess you're making the distinction between professional and non-professional engineers? There's not really the class divide in engineering fields that you're suggesting. I have a brother who is an ME, designs power plants (the building sized ones) and is not "professional". I asked him about it and he said it wouldn't change his role or his salary, so he never bothered going through the process. IIRC there's one p…

> IIRC there's one person on the team who is, for whatever formalities are required.

Is that person making more money? Because I've heard stories that these people do, because they are especially valuable to the company.

Re: Requirements volatility is the core problem of software engineering

#188

Post by Nasrudith » Sat, Feb 22, 2020, 7:14 PM UTC

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

Re: Requirements volatility is the core problem of software engineering

#189

Post by [deleted] » Sat, Feb 22, 2020, 7:16 PM UTC

mhotchen wrote: post #35

29athrowaway wrote: post #26

Earlier quoted context omitted.

What comes first, feature creep or agile? I would say that agile has helped create the conditions for the proliferation of tech debt mills, because it empowers product people while disempowering engineers. "Rapid and flexible response to change" is really just bruteforcing ideas leaving a trail of tech debt that makes developers miserable.

This has less to do with agile and more to do with the company culture, processes, and probably the people involved. Agile isn't a cure to these problems, it's a tool used by people who "get it" to communicate effectively and to empower everyone to do their jobs. Thanks to agile I am directly involved in evolving the product I work on and providing information back to the product owner and anyone else involved. I reg…

[deleted]

Re: Requirements volatility is the core problem of software engineering

#190

Post by Syntoniclese » Sat, Feb 22, 2020, 7:21 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.…

I agree with you in principal. When I worked in web development many of my projects were clearly defined and similar.

However when I got into more creative development I found myself faced with unique problems to which the solution was unknown. The development process in this case is less like an implementation and more a exploration of the problem space.

This process is more like sculpting or writing a book or solving a puzzle. As you sculpt the next steps reveal themselves. As you write a story the plot emerges. In order to solve a puzzle box you probe the box.

Solving the unknown in bridge building is working through sets of equations and to solve for variables. It involves doing math.

Solving the unknown in software involves a similar working through. "Doing the math" for code involves executing code. It's faster and easier. Ignoring this is like restricting your bridge planning by avoiding CAD or doing the math by hand.

Yes, once a solution is mapped out the ideal would be a full rewrite. The benefit of software is that it can be modified and finalized directly like baking a sculpt or revising a manuscript.

If a button allowed the working schematic of your bridge to magically materialize, and changing the schematic affected the real world bridge instantly with negligible implementation cost then civil engineering would evolve in the direction of software development. It's not the other way around.