4 ms·

Whenever the manifesto says “X over Y,” it does not suggest this is a strict dichotomy. I have worked in an agile manner on software that had extremely well-doc

Whenever the manifesto says “X over Y,” it does not suggest this is a strict dichotomy. I have worked in an agile manner on software that had extremely well-documented behaviour and all sorts of documented, objective requirements. The expression "Working software over comprehensive documentation” simply emphasizes what matters at the end of the day: Working software. If you need a certain amount of comprehensive documentation to prove that the software works, you incorporate that documentation into your process. It’s the same as emphasizing collaboration over contracts. I worked for a decade in consulting, I assure you there are contracts with clients even when you use Scrum. You don’t refuse to have any hard, contracted, binding commitments. It’s just that you prioritize collaborating with people over setting up solitudes that communicate by throwing contracts over a wall. As for responding to change over following a plan, if you can set up an environment where there are no changes allowed to interfere with the plan, by all means ignore change and follow the plan. But if you actually have changes that matter, you need to deal with them too. But that doesn’t mean don’t plan, or never follow any plan. It just means, respond to changes that matter. For example... What if you discover that the security for a piece of software need to be updated. You’d respond to that, wouldn’t you? You wouldn’t push on to finish what was originally planned with your fingers in your ears? These are guidelines. They’re motivating forces. You are supposed to do it in harmony with the hard requirements of your business and domain.

kuschku 11y ago
Documentation can also be useful without working software. For example, when you have to interface with others. They can work on the software that depends on yours before you have even written a single line of code, and it will work. Software without documentation also can lead to serious issues – as in the "does the train continue running when the signal is broken" question I mentioned a dozen times now. In actual critical projects, Documentation over software. The best software is nothing without documentation. That’s the first point where I have to disagree with it. In many other points, agile leads to teams just carrying the technical debt with them.
- jdbernard 11y ago
  Does the fact that you haven't read all the detailed technical specs for your car prevent you from using it? Do you know the detailed specs for the actually critical braking mechanism in your vehicle? Or is it impossible to use your car because you don't know the tolerances of every nut and bolt in the system?
- braythwayt 11y ago
  > The best software is nothing without documentation You know, it’s not enough to restate your own points, you have to read and absorb the things other people are saying. Once again, “Working software over documentation” does not mean “Working software instead of documentation.” It means that working software is more important than documentation, but both can be important. And it can be that documentation exists to make the software work. If I said “Working software over software patterns,” that wouldn’t mean “Never, ever, ever use the Command Pattern, or Adaptors, or a Facade.” It just means that you use those things to make the software work. And if they are essential to making the software work, they are essential. So you tell me that software is nothing without documentation, and I happen to agree. But software is also nothing without binaries. But that doesn’t mean “binaries over working software.” It just means, “build binaries as part of working software."

kuschku 11y ago

Documentation can also be useful without working software. For example, when you have to interface with others. They can work on the software that depends on yours before you have even written a single line of code, and it will work. Software without documentation also can lead to serious issues – as in the "does the train continue running when the signal is broken" question I mentioned a dozen times now. In actual critical projects, Documentation over software. The best software is nothing without documentation. That’s the first point where I have to disagree with it. In many other points, agile leads to teams just carrying the technical debt with them.

jdbernard 11y ago
Does the fact that you haven't read all the detailed technical specs for your car prevent you from using it? Do you know the detailed specs for the actually critical braking mechanism in your vehicle? Or is it impossible to use your car because you don't know the tolerances of every nut and bolt in the system?
braythwayt 11y ago
> The best software is nothing without documentation You know, it’s not enough to restate your own points, you have to read and absorb the things other people are saying. Once again, “Working software over documentation” does not mean “Working software instead of documentation.” It means that working software is more important than documentation, but both can be important. And it can be that documentation exists to make the software work. If I said “Working software over software patterns,” that wouldn’t mean “Never, ever, ever use the Command Pattern, or Adaptors, or a Facade.” It just means that you use those things to make the software work. And if they are essential to making the software work, they are essential. So you tell me that software is nothing without documentation, and I happen to agree. But software is also nothing without binaries. But that doesn’t mean “binaries over working software.” It just means, “build binaries as part of working software."