4 ms·

Isn't changing requirements one of the key principles of the Agile manifesto? If so, why do we want to dive so much into requirements that are likely to change

Isn't changing requirements one of the key principles of the Agile manifesto? If so, why do we want to dive so much into requirements that are likely to change anyways? Not saying we should jump into design without understanding the requirements, but sometimes requirements are incomplete or not clearly defined and we cannot sit and wait until a new revision is out or someone becomes available to answer our questions. I guess this really depends on the area we operate. In my business domain we call requirements "wish lists" as the solutions we build are for complex hardware that generally doesn't exist yet and there's a good chance the requirements spec you got today will be rewritten in six months, yet we need to start working as soon as the project is launched. So we have learned to design things that are reasonably easy to adapt, replace and test, we even developed an entire framework for this very purpose that has become some sort of spinoff business as some customers wanted to use it for their in house development.

Chris_Newton 3y ago
Isn't changing requirements one of the key principles of the Agile manifesto? If so, why do we want to dive so much into requirements that are likely to change anyways? Who says all the requirements are likely to change anyway? That’s a whopping great hypothetical on which the entire premise rests, but YAGNI applies to development processes as much as to code! Yes, requirements often evolve and we often start with some gaps or ambiguities in the spec. However, that’s a very different situation to having no detailed requirements at all. In one case, you know where you’re trying to go right now and can set a course that will take you there. Even if the destination is changed a bit during the voyage, you can adjust your course to compensate and still be heading in roughly the right direction. In the other case, you literally don’t know which way to start. Moreover, jokes about skyscrapers turning into spaceships aside, the central requirements for a software project usually evolve relatively slowly. Business priorities or some of the details might change faster, but in most fields the underlying domain concepts and actors that the software models are going to be relatively stable. Big pivots where you’re effectively trying to build a completely different product afterwards do happen. However, a team that pivots so often that it never really understands where it’s trying to get to before changing direction again won’t last long because it can never get far enough in any direction to deliver real value.
- kqr 3y ago
  The tricky bit, in my experience, is that when you straight up ask the customer for requirements you get a list full of details around specific functionality -- basically all the stuff that's going to change in a month. It takes skill and effort to abstract from these detailed wishlists into generalised primitives which remain somewhat constant. This work is similar to the fuzzy logic social scientists work with, and that's exactly the sort of thing most techies are not very good at.
  - Chris_Newton 3y ago
    It takes skill and effort to abstract from these detailed wishlists into generalised primitives which remain somewhat constant. 100% agreed. It’s well worth doing it if you have the chance, though. Understanding how your customer sees their world and what problems they’re really trying to solve is valuable both for building a useful product and for keeping that customer happy!
MichaelRo 3y ago
In 20+ years I don't think I ever worked on a "well-defined problem". It's always a fuzzy nebula and the only way to get insight is to build some prototype, see how it behaves and improve upon it. With the inevitable "suboptimal" early design somehow enduring and adapting through successive iterations, never have time or be able to afford a full rewrite from a business perspective: stuff works for the client, regardless how terrible the engineers view the build process. So people love to lament how awful the early choices were and how far in outer space we'd be, should some shiny late-stage idea have been applied. But it's a lot more like the x86 CPU architecture, in spite of all the detractors, it endures. Ahh, and I've also worked for a company that did rewrites. A lot of them. Like every time the product reached some 80-90% of functionality, they'd throw everything away and redo from start. Never shipped anything in my entire stay there. Again in my life I never seen such a thing, it's like the managers were not right in the head and developers were lacking any common sense. So it shouldn't come as a surprise that now (after some 5+ years of this) they closed and fired everyone.
- camjohnson26 3y ago
  On the flip side the code bases I’ve worked with that were built with exploratory coding, instead of deeply understanding the problem and designing a solution, tend to be buggy, slow, and stressful to work on. I think it’s a balance like anything else.
knodi 3y ago
The changing requirements part is mystifying part of Agile. How do you build the a proper foundation without knowing the base requirements it needs to support day one and plan for day 30/60/90/365 days needs. Its almost like its written by the PO/PM without really understanding anything else but their slice of work and how they can make it easier for them. Money and time (for us humans) are finite, big things at lease have to be targeted precise efforts, a good plan and architecture that maps back and supports the requirements.

Chris_Newton 3y ago

Isn't changing requirements one of the key principles of the Agile manifesto? If so, why do we want to dive so much into requirements that are likely to change anyways? Who says all the requirements are likely to change anyway? That’s a whopping great hypothetical on which the entire premise rests, but YAGNI applies to development processes as much as to code! Yes, requirements often evolve and we often start with some gaps or ambiguities in the spec. However, that’s a very different situation to having no detailed requirements at all. In one case, you know where you’re trying to go right now and can set a course that will take you there. Even if the destination is changed a bit during the voyage, you can adjust your course to compensate and still be heading in roughly the right direction. In the other case, you literally don’t know which way to start. Moreover, jokes about skyscrapers turning into spaceships aside, the central requirements for a software project usually evolve relatively slowly. Business priorities or some of the details might change faster, but in most fields the underlying domain concepts and actors that the software models are going to be relatively stable. Big pivots where you’re effectively trying to build a completely different product afterwards do happen. However, a team that pivots so often that it never really understands where it’s trying to get to before changing direction again won’t last long because it can never get far enough in any direction to deliver real value.

kqr 3y ago
The tricky bit, in my experience, is that when you straight up ask the customer for requirements you get a list full of details around specific functionality -- basically all the stuff that's going to change in a month. It takes skill and effort to abstract from these detailed wishlists into generalised primitives which remain somewhat constant. This work is similar to the fuzzy logic social scientists work with, and that's exactly the sort of thing most techies are not very good at.
- Chris_Newton 3y ago
  It takes skill and effort to abstract from these detailed wishlists into generalised primitives which remain somewhat constant. 100% agreed. It’s well worth doing it if you have the chance, though. Understanding how your customer sees their world and what problems they’re really trying to solve is valuable both for building a useful product and for keeping that customer happy!

MichaelRo 3y ago

In 20+ years I don't think I ever worked on a "well-defined problem". It's always a fuzzy nebula and the only way to get insight is to build some prototype, see how it behaves and improve upon it. With the inevitable "suboptimal" early design somehow enduring and adapting through successive iterations, never have time or be able to afford a full rewrite from a business perspective: stuff works for the client, regardless how terrible the engineers view the build process. So people love to lament how awful the early choices were and how far in outer space we'd be, should some shiny late-stage idea have been applied. But it's a lot more like the x86 CPU architecture, in spite of all the detractors, it endures. Ahh, and I've also worked for a company that did rewrites. A lot of them. Like every time the product reached some 80-90% of functionality, they'd throw everything away and redo from start. Never shipped anything in my entire stay there. Again in my life I never seen such a thing, it's like the managers were not right in the head and developers were lacking any common sense. So it shouldn't come as a surprise that now (after some 5+ years of this) they closed and fired everyone.

camjohnson26 3y ago
On the flip side the code bases I’ve worked with that were built with exploratory coding, instead of deeply understanding the problem and designing a solution, tend to be buggy, slow, and stressful to work on. I think it’s a balance like anything else.

knodi 3y ago

The changing requirements part is mystifying part of Agile. How do you build the a proper foundation without knowing the base requirements it needs to support day one and plan for day 30/60/90/365 days needs. Its almost like its written by the PO/PM without really understanding anything else but their slice of work and how they can make it easier for them. Money and time (for us humans) are finite, big things at lease have to be targeted precise efforts, a good plan and architecture that maps back and supports the requirements.