Agile development continues to grow in popularity, but teams often have trouble adopting new techniques. In this...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
interview with the four Net Objectives authors of Essential Skills for the Agile Developer: A Guide to Better Programming and Design, we’ll explore the skills that are most important and some differences between Agile and Waterfall development.
SSQ: This book gives some very specific tips for the software developer on disciplined coding techniques. However, many of these practices can be done regardless of methodology being used, so why are they considered “Agile”?
The practices are all good coding practices that can be followed by all developers, regardless of their development process. However, some practices are much more important in Agile due to the ever changing requirements and the ability to deliver quickly without having a long integration/testing period. So continuous integration and automated testing that ensures that the modules are working together on an on-going basis are critical components in Agile.
In fact, Agile process is not just about responding to change; it actually agitates for it. Part of being Agile is validating frequently with the customer, and when you do this, you often cause them to rethink their decisions and priorities. Thus, these practices have always been important, but could be said to be even more so in an Agile process.
Bottom line, however, is we didn’t call this book Agile Development Skills; we said these were skills (admittedly many not restricted to Agile developers) that were essential for Agile developers. That is, while non-Agile developers will benefit from these skills, Agile developers will have a very difficult time not doing them.
SSQ: Is there anything in the book that couldn’t be done on a team which was using the Waterfall approach to software development?
There are a few practices that are much harder to do in a Waterfall environment. In particular, avoiding over or under design is harder to do in Waterfall. For example, since development proceeds in a sequential manner, you might develop a framework to use prior to actually using it. There will be a tendency to over-design the framework, since its needs are not yet clearly defined. With Agile, the details of the framework are developed as a need arises.
Defining tests up-front, as in acceptance test-driven development, is harder to do, since it requires more collaboration between the customer/business unit, the developer and the tester. In Waterfall, communication between these groups is usually through documents -- requirements, design specification, test plans, etc. -- which do not allow for much collaboration.
SSQ: You advocate the use of test-driven development (TDD), though you say many teams have “shied away from it.” Bob Martin’s book, The Clean Coder, also promotes the use of TDD, despite the nay-sayers, saying quite definitively, “The bottom line is that TDD works, and everyone needs to get over it.” What are the arguments against TDD?
We advocate both acceptance test-driven development (ATDD) and test-driven development (TDD). They are both about understanding a problem to be solved by creating tests for it. With ATDD, the tests are against a requirement. With TDD, the tests are for the functionality of a module.
In TDD, the tests drive the code. However, they do not prove a completely correct program. Relying on those tests to ensure correctness may lead one to miss defects.
Done incorrectly, TDD tests can become unsustainable. For example, using too many mocks can create situations where the maintenance of the mocks to match the behavior of the production modules can be excessive. Or, a single change to the system (due to a new requirement) can cause many tests to fail, requiring excessive maintenance of the test suite. But this is when TDD is done incorrectly; it is not an inherent problem with the technique.
We call this extended TDD, Sustainable TDD. It requires attending to certain design principles that, although well known, are often ignored by many TDDers. We’ve created a blog devoted to this subject called Sustainable TDD.
This interview continues in Software testers on Agile teams shift to exploratory testing and code quality.
This Q&A is based on the book, Essential Skills for the Agile Developer: A Guide to Better Programming and Design by Alan Shalloway, Scott Bain, Ken Pugh, Amir Kolsky