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

141–150 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#141

Post by michaelhoffman »

scruple wrote: post #135
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.…

> 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 culture with lots of reminders of how many people died when current practices were not followed.

If a firm is found to have inappropriately (for example, pressuring a professional engineer to affix their seal inappropriately) they will lose their certificate of authorization and then not be able to do any engineering work.

Re: Requirements volatility is the core problem of software engineering

#142

Post by DoingIsLearning »

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…

FIY in Software Engineering this is defined as a formal process with clients or Product Managers called 'Requirement Elicitation'.

Re: Requirements volatility is the core problem of software engineering

#143

Post by vvanders »

salty_biscuits wrote: post #65
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 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".

Re: Requirements volatility is the core problem of software engineering

#144

Post by api »

scruple wrote: post #135
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.…

> 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't tinker beyond maybe building models or using physically realistic simulations, and neither of those is a substitute for really building things at scale. Anyone with a decent computer can tinker endlessly with software with little or no consequence to anyone else when it breaks.

The only other engineering field like this I can think of is electronics, where you also have a lot of autodidacts because components are cheap and unless you are messing with super high voltages it's pretty safe to play around.

There is always a huge pushback against licensing in this field because it would be (accurately I think) seen as a way for universities to erect a mandatory toll booth.

The second huge issue is that we don't have a good theory of good programming practice. There was an attempt to systematize things in the 90s "design patterns" era and all it got us was a ton of monstrous overengineering satirized by the many "hello world, enterprise edition" joke code bases on GitHub. More academic efforts around provable correctness have never managed to cross the practicality gap for widespread adoption.

Re: Requirements volatility is the core problem of software engineering

#145

Post by austincheney »

corebit wrote: post #140
austincheney wrote: post #137

Earlier quoted context omitted.

My uncle is a senior partner in a major civil engineering firm and my wife’s best friend is a civil engineer. Everybody who practices civil engineering in Texas must be licensed to be employable. Maybe you could intern without a license, but you wouldn’t be involved with any project related work.

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?

> You've just changed the word without actually defining anything. What constitutes practicing?

Work for compensation.

Re: Requirements volatility is the core problem of software engineering

#146

Post by jrs235 »

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 business software, on the other hand, is treated as an operation. If you cannot discern the difference between a project (temporary) and an operation (living) your software will never be released as a product to a specified level of quality by a specific date.

I never really thought about that. There is so much truth to it and why so much Saas is a never ending feature factory! I assume Basecamp thinks of their Saas as a project and that's how they are able to escape the never ending Big Ball of Mud software craziness.

Re: Requirements volatility is the core problem of software engineering

#147

Post by clarry »

mewpmewp2 wrote: post #116
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…

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 one server running PHP or Perl (with SQL injections) passed for software and others were still re-inventing basic data structures in C (and then gasp C++ with templates!) from first principles... The methodology, tooling, rigor, and collective experience in software development has taken leaps in the past two to three decades. Likewise, understanding systems and planning ahead has become so much easier. If only people took it seriously and spent as much effort on it as they spend on fad-of-the-year frameworks.

People just stopped trying, and when I look in software projects now, there's hardly ever anything resembling a model of the software that you could use to test new ideas "on paper" to see how they fit the given problem and current application.

People aren't even trying, just like they aren't even trying to achieve correctness: https://news.ycombinator.com/item?id=22224054

The less you try, the harder it will be.

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

I think the vast majority of software is boring and not even meant to be innovative and indeed would be best written using an existing system, but customizing these to the specific needs is just another can of worms. As with bridges, you can't just copy & paste an old bridge to a new location and use it as-it is, you need to design it given the locale and other constraints. It's still probably going to be yet another relatively boring bridge with no innovation.

And indeed a lot of software work is all about using existing systems, but perhaps at a lower level than you posited. Customizing complete off-the-self packages does happen, but it's more common to glue something "new" (but not innovative) using existing frameworks, libraries, services and glue languages.

You still need to design to do it right. But even here people seem to rush ass-first into whatever kit looks fashionable now.

Re: Requirements volatility is the core problem of software engineering

#148

Post by mrdoops »

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 given change is greater than a declarative capability that took into account operational changes in the first place.

That said hard coding business logic is often so much quicker to deploy that in many situations you just want to hard code the logic, deploy, get feedback, then introduce flexible to the kind of change needed then continue. If you have engineers who know how to ask the kind of questions that get to the real requirements (usually not juniors) you can have a maintainable code base. Worst case scenario is if you have the "yes I shall do anything and everything with my new code power" developers who just implement out of eagerness and conflict avoidance; this can be the worst of every world: hard coded business logic so convoluted only the junior knows how to make changes.

Re: Requirements volatility is the core problem of software engineering

#149

Post by bostik »

BlueTemplar wrote: post #117
bostik wrote: post #20

The article mentions how one part of change is that regulations may have changed. I work in a heavily regulated industry, and am dealing with a set of regulators nearly all who depend on just one particular auditing company to ... effectively write their regulations for them. To the point where a new jurisdiction happily refers to their draft regulations as documents prefixed with the auditing firm's name on them. (T…

Understanding and evaluating the problem is the main job of an engineer?!? (Compared to a technician...)

It's definitely part of the job. If you don't understand what the problem is that you're trying to solve, how can you verify that the constraints you are working with actually make sense?

Re: Requirements volatility is the core problem of software engineering

#150

Post by crgwbr »

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…

> 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’ve built systems both ways. Requiring a developer to make changes definitely has costs, but it does have benefits as well. Systems configured in data rather than code will almost invariably be untested and prone to configuration bugs. Overall, I’ve spent probably double or triple the time debugging configuration of complex business rules systems than I would have if it was just written in code and unit tested.

Post reply on HN