- 616.538.8747
In software development—and large software projects in particular—there’s a pretty big problem. They fail too often. Far too many come in late, over-budget, and lacking any sort of maintainability.
2010 Michigan Agile and Beyond was held last Saturday, and it was all about one of the most popular ways companies are dealing with this issue: Agile Development. I was glad to be able to attend, and very impressed with the presenters and their ability to explain what Agile is really all about.
There’s a lot to be said about Agile— whole books are written on the subject—but I’ll attempt to quickly explain what it does and where it’s an appropriate philosophy. These are the ideas that stuck with me and the ones that mainly revolve around development, though there’s much more to the entire Agile method, especially regarding communication. The main points of the “Agile Manifesto” can be found here: http://agilemanifesto.org/
A commonly cited source of problems is simply that requirements change. At the beginning of a project, developers ask for a full specification of what the customer wants. The customer may even provide a spec that’s pretty complete. But as anyone who has worked long as a developer will know, it is inevitable that these requirements and specifications will change and be misinterpreted. These issues frequently aren’t discovered until the very end of the project when things are supposed to be finished. Customers aren’t really the ones to blame for this. The world simply changes, and large software projects are too complicated and have too many exceptions and rules for any one person (regardless of talent) to be able to visualize it completely, even in a specification document. It’s simply too big.
This problem often reveals itself in the code. If the developers are using a “waterfall” method, where the customer often doesn’t see the product at all until the end, the developers will often have to “hack in” a bunch of changes at the end to fit what the customers want and still stay under deadline. This leads to a messy codebase.
On the other hand, “rapid prototyping”—giving customers a new version of the software to look at very often during the project—often isn’t sufficient to solve these issues either. Those prototypes are usually developed with the mindset of “I’m going to refactor this later and make it more maintainable.” Unfortunately, the refactoring and simplifying rarely actually happens. When it does, it often introduces new bugs as dependencies are forgotten, another symptom of the system being too large for one person to visualize.
Although rapid prototyping isn’t ideal, it can often work better since it at least acknowledges that requirements will change. It gives customers the ability to easily figure out what they want since they will see a working version of the software in front of them. However, as stated previously, on its own it doesn’t always lead to a quality product. To solve this issue, Agile introduces Test-Driven Development to the rapid prototyping process.
Test-Driven Development (TDD for short) is about automating the testing process. In normal development, testing is often confined to just a week or two weeks at the end of a project and is done entirely manually. Not only is this often cut or reduced as projects get closer to the deadline, but it’s a great deal of wasted man hours and must be repeated when changes are made to the system.
The idea behind TDD is that developers write tests for their code BEFORE writing the code itself. Initially, it may seem absurd that one would code something that would fail a test they had written just a few minutes previously. But the benefit of the test is not to ensure the code does what it’s supposed to right then and there; it’s mainly to ensure that the code does what it’s supposed to regardless of what else changes in the future. Large software projects are very interconnected, and changing one small part often has implications for many other parts. The tests ensure that when you change something, you aren’t accidentally breaking the other pieces of your system.
A philosophy of Agile development is that software projects should respond to change, and TDD is a requirement for this to happen. In non-TDD development, a customer will ask for a change to the software or add a new requirement, and the developer (if he’s careful) will have to check through everything that could potentially be affected to ensure that new bugs aren’t introduced. With TDD, he would simply make the change, run the automated tests, and get an immediate report of whether his change broke anything else. He would also be much more confident in immediately showing his change to the customer because he would know that he had not introduced any new bugs.
TDD also allows for greater ability to continuously refactor and simplify the code, which Agile encourages. Refactoring introduces the same issues as making small changes to the code: you don’t know what else in the system might be broken because of changes you make. TDD solves this in precisely the same fashion, because it can automatically test your code once you’ve made changes.
The advantages outlined here come down to this: much less manual testing, the ability to have very maintainable code, and the ability for customers to give constant feedback on the latest version of the software.
It doesn’t come free, of course. Agile is really an investment in coding infrastructure. There’s a good deal of initial work required to ensure the ability to release software to your customers on a regular basis. There’s also an ongoing cost of writing tests for every new piece of code. But this investment really pays off for many large projects that need to respond to change, because you end up finishing more quickly or further under budget due to the reduction in bugs, testing time, and misunderstandings. That’s not to say every project may finish more quickly though. For instance, very small projects may not get their investment back, because the projects might have simple requirements that don’t change.
Finishing more quickly is great, but even if that doesn’t happen on some projects, there are other advantages to this method. Let’s say, for example, that there are two identical projects—one attempted with a waterfall methodology, one attempted with an Agile methodology, and both doomed to go exactly the same amount over budget and past deadline. The advantage for the Agile project is that all parties would have known this outcome was coming much earlier in the process, and so would have been able to plan for it by reallocating resources or canceling the project.
Agile’s goal is to mitigate the risk that’s taken on by every party involved in software projects, and for many projects it’s very effective at accomplishing this. The statistics on software projects in general aren’t pretty, and there’s a lot to be said on the low bar some projects set for “success.” Hopefully, with further adoption of techniques like Agile, software projects can come to be seen as much less of a risky investment.
» This entry was posted on Wednesday, March 17th, 2010 at 12:07 am and is filed under Development, General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a comment, or trackback from your own site.
Elexicon is an interactive design and development agency based in Grand Rapids, Michigan...More>
