This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Unknown Requirements
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
In many environments over the years, software projects become so heavily burdened by technical debt (overly crufty code) that continuing enhancements become so fraught with danger and difficult to do that progress slows down to a crawl. This is when many programmers try to talk their management into doing a complete re-write.
One of the problems with a complete re-write is that while it goes on, there are few (or no) resources to maintain the original application, and the end-result is the "same" as before in terms of functionality -- a lot of money gets spent on rebuilding the existing feature-set, and not much has gone into new features.
There have been disasters when companies have attempted grand re-writes, many of them stemming from lost requirements: the existing product does "X" and no one remembers why it does "X". Was "X" a requirement, or was it an accident of history -- maybe even a bug? Either the project reproduces "X", and maybe wastes their time reproducing a bug, or they don't reproduce "X", and then find out from end-users (perhaps disasterously) that it's a requirement.
In a project driven by automated customer tests (and programmer tests), requirements are encoded by the tests. Unlike requirements documents, the automated tests tell you if the software under test is living up to its requirements by passing or failing when executed. These tests serve as examples of what the code can do and how to do it. See also Wayne Allen asserting that these "tests" are more about communication and design rather than testing.
If one wanted to do a complete rewrite of software project, and one had complete suites of tests, a lot of the guess-work is removed. Keep the tests, rewrite the code under test. When all the tests pass (assuming the tests are complete enough), you're done. Refactoring is also best supported by automated tests.
Having this support from tests is also helpful in porting to a new platform (or even a new language). Port the tests as well as the code under test, and having the tests pass gives more than a little reassurance that the code is doing the right thing.
Of course, tests rarely cover ALL possible uses and failure-points for a piece of code (and still run in a reasonable time); there's no magic bullet. However, code that is unit-tested is usually code that is more well-designed than untested code, simply because getting a piece of code under test requires de-coupling and other good design practices. This helps prevent a project from ever getting so burdened by technical debt that a complete rewrite becomes necessary.
Previous Topic
