The spirit of Agile development is to allow changes to happen when they are needed.
The biggest benefit of running a test-driven development process is that the project does not have to stop in order to make a change.
Before thinking about Agile let’s look at another common approach to software development.
The Waterfall Method
The Waterfall method can be extremely efficient. A project is broken into several steps, each step is completed by a specialist in that area and sent on as input for the next step. It provides a high throughput and the results can be high quality.
In the traditional software development life cycle, these steps are generally defined as:
- Requirements
- Design
- Implementation
- Verification
- Maintenance
In the requirements step the analyst will collect all things that need to be done, which will be passed to a software engineer to design a system based on that. The design is then sent to a programmer who will write code as specified.
So, is Agile just a buzzword?
Agile is not the most efficient methodology, the waterfall approach can potentially deliver desired results in less time. So is Agile just a buzzword? When it comes to software development, everything always changes, even constants change. Waterfall is great for mass-production but really bad when modifications are needed, and in the world of software, modifications are always needed. Blaming the initial specification for being wrong does not solve the problem if there is a genuine interest in delivering value and responding to changing requirements.
In software development there is no need for mass-production, due to its digital nature it can be copied at anytime at no additional cost. The focus should be on developing the right thing at the right time, and that is what an Agile approach strives to achieve. In this respect, is very effective.
Let’s consider how we might go about building a car from an Agile paradigm.
Henrik Kniberg created this useful graphic which clearly demonstrates the idea of the Minimum Viable Product, or MVP. He went on to write a hugely influential blog post that literally illustrates the thinking behind the MVP concept. Instead of documenting an extensive list of requirements, we will get the main idea of what is being done: a vehicle to move from point A to point B. We could deliver a skateboard really quickly, and then, based on people’s feedback we can evolve that product towards what is really being requested. It will definitely take longer (less efficient) than building a car straight away but it will also ensure we create what the customer wants (more effective). As an added bonus, the client can already use something (delivered value) from early stages of the project.
It all looks great in theory, but as soon as we start making major modifications to the software in order to respond to changes, it will break. Probably around one week after development started the software will start to get enough complexity that a major change will require major refactoring and features that were working before will stop working: suddenly you are infested with regression bugs everywhere.
To get everything back on track again, the team will have to come to a halt in producing new features (stop adding value) until most bugs are eliminated and the refactoring is complete. When you look back, you spent so many hours refactoring the code to improve its quality but from the customer’s perspective there is no visible change, it looks like a big waste of time. Even worse, people will get afraid of refactoring as it will cause delay, frustration and probably also introduce new bugs.
“Fear leads to anger, anger leads to hate, hate leads to suffering.” – Master Yoda
But worry not, my padawan.
Introducing Test-Driven Development
There is a special technique called “Test-Driven Development” or simply TDD — it states that for every piece of code you write, you should write a simple test that proves why that code is needed.
Like a ratchet, TDD is a process that helps avoid regressions in software. TDD helps teams move their project forwards with confidence.
The benefits include
a) Less bugs – the software will be fully tested as often as you want
b) Better scope – programmers will work on small pieces of code at a time
c) Reduced technical debt – code is constantly refactored and improved
But the main benefit, in my opinion, is: velocity.
Test-driven developers will progress slower than fast-and-furious developers, but after a few cycles are complete, their velocity is similar. Without TDD you may be creating patches much faster than TDD and close a lot more tickets; however, with TDD you will not need to close as many tickets because, well, there are simply less bugs to fix.
Image credits
- Alden Jewell, Volkswagen Beetle Assembly Line, Flickr.com
- Henrik Kniberg, Making sense of MVP, blog.crisp.se
- Peter Kemp & Paul Smith, Waterfall Model of System Development, Wikimedia commons
- Dr. Schorsch, Drawing of a Ratchet, Wikimedia commons
