We're revisiting the Agile Manifesto in this series of articles, and this item is always of great interest to me. Would anyone ever make a conscious decision to target their docs instead of the product? Outside of a government subcontractor, no. So why did a group of very smart people put this in the manifesto?
I wasn't there, so I'll instead offer my opinion. It's because we spend so much time on the "window dressing" instead of functionality. How often have you used software that just looks incredible, but crashes? (Actually, this reminds me of my iPhone and making phone calls... but I digress.)
Focusing on having great docs for a product, before the product works, is silly. Ensuring a beautiful shiny case for a phone that drops calls? Also silly. You're simply raising expectations before you dash them.
Why do people do this? (Docs, not iPhones.) Because software is hard to get right, and the docs are easier. So we fall back to what feels easier, to something we feel we can accomplish. And that's the docs.
Instead of delving too deeply into why people do this, let's look at a simple way to keep your product running, even while your team is working on it.
The easiest way to keep your product solid is too make sure it's still compiling... compiling within the context of the entire system, not in the context of your desktop. After you check in your changes, that's when we want a clean compile. And a continuous integration system does this for us. ( LINK ) It watches your code repository and does a clean compile after every change. If several people check in changes while a build is still running, it just batches up the changes and runs them all at once.
This eliminates the periodic meeting where we notice daily or weekly that "something" is broken, debate blame, then waste time fixing the problem. Instead the developer who checked in the problematic code is notified and has to fix the problem within minutes, not days.
The next step is functionality. Your customer doesn't care if the code compiles... they care if it runs and if it runs correctly. Since you already have a system watching for compilation errors, let's take the next step and run our automated tests when the compile passes.
Whether you've got an Extreme Programming background and you think unit tests are the only ones worth writing, or you're more of an integration test person, I don't care. I care that the tests you create are automated. They're not good tests if I can't run them from within my continuous integration system, including all database setup, tear down, and clean up.
The problem with test automation has always been the maintenance. Who has time to fix 800 broken tests? No one does. That's why we ditched our automated tests! ;)
But how many of you have time to fix one or two tests? That's most of us... and that's how we should tackle our automated testing. Every time we check in code, the tests run. If something breaks, we do the appropriate thing. Sometimes that means fixing our code, other times it's getting our test back in sync with the newer code.
The way to ensure your test automation effort succeeds? Incremental fixes. Fix breaks as they occur instead of storing them up for a huge bug fixing effort. This, coincidentally, will keep your software running all the time. You may have less time for docs and window dressing, but I think your customers will appreciate the effort.