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