It’s not a problem of software engineering, it’s a property of software engineering.
[deleted]
Requirements volatility is the core problem of software engineering
21–30 of 251 posts
Re: Requirements volatility is the core problem of software engineering
#22Developers who believe they can forsee the future are more dangerous than missing business requirements.
The problem with missing business requirements are that developers often are either to focused on writing the code instead of actually understanding the business.
You cannot build something you do not understand.
Understand small and expand your understanding. Code is not the goal, it never is. It's a means to a goal.
Another thing about software is, that a lot of it should never ever be written. It's the last thing you do, is write code for overcoming a challenge, because rarely you really need it.
Re: Requirements volatility is the core problem of software engineering
#23> 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…
Shameless plug (I’m paraphrasing myself in the “mediocrity” line above): Right to Left: The digital leader’s guide to Lean and Agile https://www.amazon.co.uk/Right-Left-digital-leaders-guide/dp...
Re: Requirements volatility is the core problem of software engineering
#24As someone somewhere said, writing software to a spec is like walking on the water - Easy when it is frozen.
Re: Requirements volatility is the core problem of software engineering
#25It 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 the code is the design. The actual building is done by the compiler (or equivalent). So the important lesson is to budget for iterations of the design and not putting too much effort into the first sketch presented to the customer.
Re: Requirements volatility is the core problem of software engineering
#26Agile 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…
What comes first, feature creep or agile?
I would say that agile has helped create the conditions for the proliferation of tech debt mills, because it empowers product people while disempowering engineers.
"Rapid and flexible response to change" is really just bruteforcing ideas leaving a trail of tech debt that makes developers miserable.
Re: Requirements volatility is the core problem of software engineering
#27Agile 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.
Ask 10 different developers, Agile salesmen, and product owners and you'll get 10 different explanations of what Agile is.
Occasionally you'll come across somebody with a healthy dose of skepticism.
Re: Requirements volatility is the core problem of software engineering
#28I disagree with the title. I've used waterfall and still found engineering hard.
Even you have a bulletproof requirements document, implementation and engineering still produces unforeseen eventualities and unexpected consequences.
I think software engineering is hard primarily because it's the coalface between abstract and concrete.
We're wired to be great at concrete, but capable at abstract. With software it's like we can get ourselves into a perfect storm of intractable-for-us problems.
Other forms of engineering, civil, mechanical, etc are still really hard, but I think we're better wired for them because they're less abstract, more concrete.
But in software, abstraction is part of your bread-and-butter daily-grind tool-kit.
Re: Requirements volatility is the core problem of software engineering
#29Earlier quoted context omitted.
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.
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?
Re: Requirements volatility is the core problem of software engineering
#30Earlier quoted context omitted.
No agile is just micromanagement. Control every task the developer works on, make them report status on a daily basis.
Ask 10 different developers, Agile salesmen, and product owners and you'll get 10 different explanations of what Agile is. Occasionally you'll come across somebody with a healthy dose of skepticism. https://news.ycombinator.com/item?id=5406384
That is an excellent comment, thanks for sharing.
I believe the agile manifesto was written by smart people that knew what they're talking about. But what is known today as agile has nothing to do with what they really meant.
The agile manifesto says "working software over comprehensive documentation", but in practice, all agile projects I have seen put more emphasis on project documentation than working software: kanban boards, sprint burndown charts, the backlog, project planning documents... that's documentation.
The manifesto also mentions "individuals and interactions over processes and tools". Standup meetings, sprint planning, sprint retrospectives, etc. are processes. And agile practitioners I have met put more emphasis on those rather than doing something in the spirit of the manifesto, which is using reason and logic to collaboratively find solutions.