Radu Ometita from Unit 3 published a comprehensive and very interesting article about Test Driven Development (TDD) using Agile in the 31st issue of Today Software Magazine (TSM).
Radu started by explaining how complexity has been significantly changing the essence of programming in the past years. The need to deal with changes in requirements at ever increasing speeds led to the introduction and proliferation of Agile methodologies, which are now omnipresent in complex projects. Massively concurrent applications also had a fair share in adding to the complexity of the software development process.
Since solutions depend on the level of complexity, the author addressed this issue prior to outlining the appropriate approaches. According to the model from the Cynefin Framework, a problem can be simple, complicated, complex and chaotic. Workflows that have repeatedly met their specific needs and avoided the hidden dangers lying in the way are presented for each of them.
As complex contexts have been added quite recently to the long list of challenges programmers face on a daily basis, downgrading them to complicated came as a natural reaction. While a full adjustment to these contexts will take some time, the emergence of a lot of rules and regulations trying to control the apparent chaos makes it clear specialists are well aware of the complex domains and adjust to them as quickly as possible.
An important idea emphasized in the article is that complex domains require plenty of exploratory drilling, which means that getting to the desired result can only happen with multiple cheap failures. Complex projects can be regarded as experiments that lead to constantly reshaped expectations. Several behaviors must be encouraged throughout the complex project’s lifecycle, such as constant communication, setting constraints within which the system can evolve and reusing solutions.
The following paragraph of the article presents the main uses, strengths and weaknesses of the Waterfall and Agile approaches. The way software developers adopted and applied them is also addressed here and a warning is issued to those who became complacent after their early successes with Agile and TDD. These methodologies cannot simply be reduced to sets of good practices when applied to complex and chaotic contexts. In TDD, functional tests are catalysts for changes to the code base, checking if the code performs the functions it was designed for. The Red / Green / Refactor cycles are warmly recommended for complex problems.
Radu’s conclusion is that we must swiftly adjust to the constantly increasing level of complexity we face in software development, to adapt TDD and Agile to the present, regardless of how well they performed in the past and to never stop learning and improving if we want to belong to the new wave of programmers and testers.