It’s not a problem of software engineering, it’s a property of software engineering.
Requirements volatility is the core problem of software engineering
11–20 of 251 posts
Re: Requirements volatility is the core problem of software engineering
#12It is funny to compare that to traditional product design. Let's say your goal is to design a chair. The most important tools in your toolbox are variants and iterations. The worst you could do as a designer is constantly working on one (final) chair. Because every change that goes aginst the initial concept will have you saw pieces away and glue them to other spots till you end up with a completely irrational whole.…
> Also software (like graphic design) is a field where people without any skill tend to have strong opinions about how things should look or work Business too. You do not have to be a good strategist to “succeed” as a VP in a medium or larger sized organization. In fact, you can be downright terrible.
It is why I ultimately stopped taking on much graphics design work and did more film sound mixing jobs — there is so much less people who think they have the experience to tell you precisely what they want and much more we trust you and do your thing.
I am slowly starting to get the idea behind medival guilds..
Re: Requirements volatility is the core problem of software engineering
#13It is funny to compare that to traditional product design. Let's say your goal is to design a chair. The most important tools in your toolbox are variants and iterations. The worst you could do as a designer is constantly working on one (final) chair. Because every change that goes aginst the initial concept will have you saw pieces away and glue them to other spots till you end up with a completely irrational whole.…
But chairs are made in large runs, 99% of the work is in the factory. So everyone understands that the work of making a prototype is a different thing to the final product.
A better engineering example needs to be completely one-off, like building a movie set, a stadium, or maybe an airport. These also have endless problems with the requirements changing during design & construction.
Re: Requirements volatility is the core problem of software engineering
#14It’s not a problem of software engineering, it’s a property of software engineering.
Yes, that is very true. If changing and complex requirements are a problem, you are doing it wrong. This is the main reason why code quality must be as high as possible. It is the best chance there is to be able to accommodate new and changing requirements in a reasonable time frame. It is also the reason why automated tests are a necessity. Otherwise it is way to easy to satisfy one requirement while not noticing that at the same time one is destroying three others.
Re: Requirements volatility is the core problem of software engineering
#15Agile is about giving developers the illusion of control, so they are more comfortable committing to an endless cycle of nonsense.
No agile is just micromanagement. Control every task the developer works on, make them report status on a daily basis.
Re: Requirements volatility is the core problem of software engineering
#16It’s not a problem of software engineering, it’s a property of software engineering.
Yes, that is very true. If changing and complex requirements are a problem, you are doing it wrong. This is the main reason why code quality must be as high as possible. It is the best chance there is to be able to accommodate new and changing requirements in a reasonable time frame. It is also the reason why automated tests are a necessity. Otherwise it is way to easy to satisfy one requirement while not noticing th…
If the subject is Software Engineering and you said "If changing and complex requirements are a problem, you are doing it wrong" the it in that sentence should be Software Engineering - but the changing and complex requirements seldomly come from the Engineers.
Re: Requirements volatility is the core problem of software engineering
#17This is somewhat triggering for me right now as I am just getting done with a project that is quite a few degrees hotter on the Requirements volatility scale than is currently assumed.
Re: Requirements volatility is the core problem of software engineering
#18Earlier quoted context omitted.
Yes, that is very true. If changing and complex requirements are a problem, you are doing it wrong. This is the main reason why code quality must be as high as possible. It is the best chance there is to be able to accommodate new and changing requirements in a reasonable time frame. It is also the reason why automated tests are a necessity. Otherwise it is way to easy to satisfy one requirement while not noticing th…
If the subject is Software Engineering and you said "If changing and complex requirements are a problem, you are doing it wrong" the it in that sentence should be Software Engineering - but the changing and complex requirements seldomly come from the Engineers.
No, they do not come from the software engineers. It is like being a DJ who is taking requests. You are not playing music for yourself but for other people. It the DJs task to make them sound good. On the other hand, one sometimes also needs to clarify what is wanted because the customers will ask for a rock song with a slight edge of metal in it and as the DJ you will need to know what song fits that description.
Re: Requirements volatility is the core problem of software engineering
#19The article talks about the one contract that had the requirements fixed -- but then fails to talk about how contracts should be laid out to embrace changing requirements.
People have known for a long time that volatile requirements are a core problem, but that typically hasn't really affected the way software and software development services are procured.
This might be different in other parts of the world, but my impression is that even custom development contracts are procured the same way that you would a big shipment of physical goods, which is just insane.
Once you work as a developer in a project that was procured in such a way, it's already too late. The knowledge that requirements will change and will totally disrupt your development process is there, and it doesn't really help you.
Re: Requirements volatility is the core problem of software engineering
#20The 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. (This is not a joke or hyperbole.)
That particular company has trained their own workforce to evaluate acceptance criteria according to their internal workflows and practices. This in turn means that almost all industry regulations are geared not towards functionality, but to make sure the auditing company has the least amount of training to do. As far as I am concerned, this is a particularly perverse form of regulatory capture: it's not even the industry at large writing their regulations, but an already entrenched gatekeeper acting on their own interest, crippling both the regulators and the companies in the industry.
Now, I have no problem with regulations as such, because for most parts the rules tend to make good sense. But I do have a problem with regulations shaped after the desires of this particular auditing company. Instead of focusing on results, quality, transparency, accuracy, recoverability and functionality, they have a fixated view on particularly dubious change management processes.
I am convinced that at some point in history, someone has done extensive research into 70 years of software engineering best practices - and gone to extreme lengths to expressly reject as many of them as possible.
Two examples: they insist that even unit tests MUST NOT be written by the engineers who work on the code; and they are mortally afraid of the idea that engineers who work on a problem could ever understand and evaluate the problem. (Not to mention that the very concept of a workflow tool is completely alien to them.)
The end result is that you can either try to do software well, or you can try to do it according to regulations.