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

241–250 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#241

Post by cjfd »

bryanrasmussen wrote: post #160
cjfd wrote: post #32

Earlier quoted context omitted.

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.

Ah, now I understand what you are trying to say. Yes, the 'it' in my post is indeed referring to software engineering.

It is not so much that they are doing software engineering wrong due to changing requirements as that the changing requirements make clear that the quality of the engineering is not that great. Another engineer who is working with a higher quality perhaps could have handled the changing and complex requirements without much problems. And in another project the requirements are perhaps quite simple and there is not much requests for changes and both engineers would have done equally well because their skill was not tested much.

Of course, there also has to be some limit in changing and complex requirements beyond which it is no longer reasonable for anyone to be able to keep up...... but we do call it SOFTware as opposed to HARDware because it is supposed to be changeable.... and if that which is supposed to be changeable actually is not, there must be something wrong.....

Re: Requirements volatility is the core problem of software engineering

#242

Post by LorenPechtel »

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…

As a native speaker I had no idea there was a proper order.

Re: Requirements volatility is the core problem of software engineering

#243

Post by LorenPechtel »

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

Quit bothering me with this technical jargon! What is this "weight" garbage, just build the bridge!

Re: Requirements volatility is the core problem of software engineering

#244

Post by Mattasher »

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…

I often use this as an example of an "unknown known" for most English speakers. We know how to order these things, but we don't know about the specific rules that govern their ordering and that we have (implicitly) mastered that.

Re: Requirements volatility is the core problem of software engineering

#245

Post by vanniv »

Requirements are fairly volatile -- but the real problem isn't that the requirements themselves are volatile but that the true requirements are so poorly understood (and, thus, the apparent requirements shift rapidly as understanding of the problem domain changes throughout the software lifecycle).

Re: Requirements volatility is the core problem of software engineering

#246

Post by Rury »

chrstphrknwtn wrote: post #49
catmanjan wrote: post #46

Earlier quoted context omitted.

I often hear people use that logic as a reason why software doesn't qualify as engineering

Do you share the opinion that software doesn’t qualify as engineering? I’ve always thought it is a little bit of a stretch.

I always thought engineering was simply applied math and science. You're not researching and testing new theory explaining the nature behind how phenomena work, or developing new mathematical techniques, that's for scientists and mathematicians. Rather engineers take their work, and apply it to invent things and solve problems.

As so, I'd consider software development can qualify as engineering. If you're taking the work of computer scientists and mathematicians (or any other science fields) and applying it to software, it fits the definition. If you're just laying code to a given spec without much more thought, then you're just a programmer/developer...

Re: Requirements volatility is the core problem of software engineering

#247

Post by dev_hacker »

elteto wrote: post #234
dev_hacker wrote: post #88

Earlier quoted context omitted.

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

I get your point about how people end up doing engineering jobs sans PE certificate, but I would still stick to the position that people without certifications are in fact, not engineers. Maybe they are doing the work, but paralegals who failed the bar aren't lawyers, even if they went to law school, they're paralegals (or whatever lesser title applies). You don't get to be an engineer because you passed a degree program, or got someone to hire you with such a title. You have to demonstrate an objective mastery of a large body of knowledge, etc. This is what the PE actually tests for. This is different than in tech, where getting a degree or a job actually does make you a software engineer. There is no standard exam to pass or anything. Just get any random hiring manager to hire you and you're a software engineer.

Re: Requirements volatility is the core problem of software engineering

#248

Post by cyberbanjo »

austincheney wrote: post #165
jayd16 wrote: post #155

Earlier quoted context omitted.

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

I am not sure what you mean. When are you not writing code by hand or are you reliant on somebody to write it for you?

Always when aided by a compiler or interpreter.

Re: Requirements volatility is the core problem of software engineering

#249

Post by elteto »

dev_hacker wrote: post #247
elteto wrote: post #234

Earlier quoted context omitted.

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

I get your point about how people end up doing engineering jobs sans PE certificate, but I would still stick to the position that people without certifications are in fact, not engineers. Maybe they are doing the work, but paralegals who failed the bar aren't lawyers, even if they went to law school, they're paralegals (or whatever lesser title applies). You don't get to be an engineer because you passed a degree pro…

Well, you can certainly stick to your convictions, no problem with that :) but that doesn’t mean you are right.

You can’t compare against paralegals/lawyers because calling yourself a “lawyer” has legal implications, as in, you must be certified by the bar or you can get in trouble. It doesn’t matter which legal discipline you practice, you must be certified by the bar.

For engineers no such thing as a bar association exists for ALL disciplines. The PE certification only covers a handful of engineering disciplines therefore it can’t be a gatekeeper for all engineers. Moreover, note that certified engineers are called Professional Engineers, not just Engineers! Even the name distinguishes between certified/non-certified, it doesn’t try to take over every meaning of Engineer.

Re: Requirements volatility is the core problem of software engineering

#250

Post by axilmar »

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…

That's way the most appropriate way to develop software is to actually create it piece by piece with the client side-by-side.

Unfortunately, there is such software development platform in which software can be 'sculpted' as if it was a statue, with the client being able to oversee what the software would do at every moment.

In practical terms, here is how software development should go:

1) open an empty canvas (for example in your browser). 2) ask the client what they want. They will say, for example, they want to see a bunch of posts and comments below them. 3) create a list of posts, on the spot. 4) create the ability to add comments below each spot. 5) ask the client 'is this ok?' 6) he/she may say no, so delete the above and restart. 7) otherwise, proceed with the next question 'what else do you want?'.

In the back end, the development mechanism shall create the databases and code needed to handle the tasks in the front end.

After all, the only 4 things we want a computer to do are these: create/search/modify/delete information.

Post reply on HN