This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Super-Coder
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.
Maybe not for a small, solo project, but what about working in a team? What will happen if one of those other programmers on the team (maybe one who hasn't been hired yet) has to change something that your code depends on? Or even changes your code? Perhaps you've moved to another project, so you're not there to change your code perfectly.
Of course, you are not perfect. You will inject defects into your code sometimes. Your teammates will too. And then there are changing requirements, and changing interpretations of requirements, and operating system updates, and library updates... lots of opportunities to write imperfect code or introduce defects when modifying the code.
One way to find those imperfections is manual testing. But this is the 21st century - automate that testing! The first time you run well-written automated tests on "legacy code" (defined as code without automated tests, according to Michael Feathers), you are very likely to find bugs. Often just writing such a test helps me find code-defects, and then I run the test to confirm it. And they are so cheap to run (if written right) that using them to find less-frequent "regression" bugs will pay off.
Story-Test-Driven-Development starts off with the Customer (Product Manager/Domain Expert) defining the expected behavior of a feature using automated acceptance tests. Defining these tests clarify the requirements, which even a perfect programmer can benefit from. Without fully understanding the requirements, any programmer can write the wrong code: a "bug" even though code itself is flawless.
When an expert pair of programmers, familiar with TDD, decided to skip Test-Driven Development, they paid a price. Quoting James Shore:
What we should have done at this point is archive our spike and start over using proper test-driven development. But we didn't. Instead, we kept going, trying more and more ideas, [...] until we didn't have a spike any more. We had a nascent application. One without tests. In other words, we already had a fairly sizable amount of technical debt and the application was only a week or two old.
[...] It's now a month later and progress has slowed to a crawl. In the first month, we were adding significant new features every week, sometimes every day. What happened?
In two words: technical debt. To make progress so quickly, we cut a lot of corners. We didn't implement any tests. We only programmed for the best-case networking scenarios. We let bugs creep in.
[...] we took on technical debt and now we're paying the cost [...]
THAT was a six week project. They planned on paying off that technical debt after initial demo and alpha pre-release. (Which has happened. Check out CardMeeting.) Imagine how bug-ridden and fragile the source code of a 10-year-old product with few or no automated tests can be. If you work for a big company with "version 9.x" product, it's very likely you already know. It doesn't have to be that way. It doesn't have to stay that way.
Previous Topic
