Requirements volatility is the core problem of software engineering
stackoverflow.blog
Requirements volatility is the core problem of software engineering
1–10 of 251 posts
Re: Requirements volatility is the core problem of software engineering
#2Greg Young described a good way to deal with requirements volatility: optimize from the beginning to be able to delete your code, and structure your code so that any part of it is no bigger than 1 week's worth of coding. So that any part can be re-written in 1 week.
Re: Requirements volatility is the core problem of software engineering
#3> Requirements change. Every software engineering project will face this hard problem at some point.
> There is really only one answer to this: you need to find a way to match the requirements-development-delivery cycle to the rate at which the requirements change.
Honestly, I believe that much of the problem is with the word “requirements” and I so wish we could kill this use of the word. Bottom line, for systems built for humans, ploughing through backlogs of requirements is the path to mediocracy (or worse) – as the OP discovered.
A less misleading framing: you need to find a way to match the delivery cycle to the rate at which understanding changes. In other words, your development process is a learning process.
Re: Requirements volatility is the core problem of software engineering
#4[deleted]
Re: Requirements volatility is the core problem of software engineering
#5Agile is about giving developers the illusion of control, so they are more comfortable committing to an endless cycle of nonsense.
Re: Requirements volatility is the core problem of software engineering
#6It 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.
The problem is of course, that a low effort design prototype still looks and feels like a low effort design prototype. But the customer sees 5 variants of the low effort prototype and can decide which one is iterated on further.
If you program a low effort software prototype, it should still kinda work and this is where the customer would decide to run with it.
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, which makes manipulazing the customer into taking a decent solution part of the job.
Re: Requirements volatility is the core problem of software engineering
#7It 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.
Re: Requirements volatility is the core problem of software engineering
#8> Requirements change. Every software engineering project will face this hard problem at some point. > There is really only one answer to this: you need to find a way to match the requirements-development-delivery cycle to the rate at which the requirements change. Honestly, I believe that much of the problem is with the word “requirements” and I so wish we could kill this use of the word. Bottom line, for systems bu…
100% agree learning is the core problem people in large organizations really don't know how to learn and the typical corporate environment is the perfect quasi academic environment geared towards pursuing metrics that amount to chasing grades
Re: Requirements volatility is the core problem of software engineering
#9Agile is about giving developers the illusion of control, so they are more comfortable committing to an endless cycle of nonsense.
That’s a really interesting perspective. I’m doing a waterfall on my current project and it just feels more right
Re: Requirements volatility is the core problem of software engineering
#10Agile is about giving developers the illusion of control, so they are more comfortable committing to an endless cycle of nonsense.
That's when done in a factory feature farm where you've already sold your control for the safety of a steady paycheck
Try selling a really agile methodology to a client of your own before you jump on the turnip truck
When done properly it gives the client immediate results with little up front commitment or risk and gives you all the control you could want as long as you don't mind being untethered from the communal trough and putting your reputation on the line at every iteration