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

151–160 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#151

Post by austincheney »

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…

Many security practitioners are self taught and the security certifications compensate for that.

https://www.isc2.org/Certifications/CISSP/experience-require...

Re: Requirements volatility is the core problem of software engineering

#152

Post by Jarwain »

newscracker wrote: post #138
AndrewKemendo wrote: post #111

Earlier quoted context omitted.

Seems like that's why startups with a founder that is solving their own problem are more successful than ones doing otherwise.

That doesn’t make sense to me as a reply to the comment above. Such startups should then be useful only for the founder. The GP’s point is to build and get feedback from the users to revise it continuously. That’s how you know you’re solving the problem for someone who seems to have the problem.

The idea is that the founder was once, or still is, the "user". They know the problem because they had the problem, recognized that software could solve the problem, and started a company to make that software a reality.

Because the founder is a user, the founder knows what the solution should look like, and can guide development in the right direction. There's a tighter feedback loop when the user is inside your organization, and is managing the product itself

Re: Requirements volatility is the core problem of software engineering

#153

Post by Ericson2314 »

Honestly the desire for simple unit economics and legacy property rights really fucked it up. People pay for "a software", but what they really need is a change in the collective software commons. Of course, no one expects any change order to be the final one, so the the volitility is natural and expected.

Re: Requirements volatility is the core problem of software engineering

#154

Post by jonahx »

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.

Re: Requirements volatility is the core problem of software engineering

#155

Post by jayd16 »

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

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

Re: Requirements volatility is the core problem of software engineering

#156

Post by moron4hire »

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.

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.

Re: Requirements volatility is the core problem of software engineering

#157

Post by WhompingWindows »

mrdoops wrote: post #148

This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I.e. when a frequently changing business process like a finite state machine for an approval procedure is only change-able by a developer that means there's always the cost of that developer's "need-to-know" for a straight forward change in the business operations. The cost of a give…

I'm not the most experienced, can you highlight why it'd be wrong to do the following. Let's say you use hard-coded business logic, but you clearly document the code and it'd be clear to any experienced programmer what's going on. How is that un-ideal? Yes it's non-transferrable code, but it's so much faster to write purpose-built code, right?

Re: Requirements volatility is the core problem of software engineering

#158

Post by kazinator »

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.

Re: Requirements volatility is the core problem of software engineering

#160

Post by bryanrasmussen »

cjfd wrote: post #32
bryanrasmussen wrote: post #29

Earlier quoted context omitted.

It seems that when I say that requirements seldomly come from the software engineers you have somehow misunderstood me as meaning that requirements do come from the software engineers?

No, it is just that your post sounded to me like you were saying that it is a problem that the requirements are not coming from the software engineers. My post attempts to say that this is not a problem and that it actually is how it should be.

How could you possibly interpret what I wrote in that manner?

I quoted your statement "If changing and complex requirements are a problem, you are doing it wrong" and pointed out that it was not reasonable to say someone is doing Software Engineering wrong due to changing requirements, as the engineers are seldomly in charge of requirements.

Post reply on HN