“We have found 150 defects in your application, out of which 50 are new, 50 are closed, and 50 are re-opened”. This is a typical scenario that developers of software development teams face as they near the sprint development cycle. On a closer look at the defect report, one realizes that the closed and re-opened defects have gone through multiple cycles from fixed to re-opened and so on. Now this rework is not generally factored in when we estimate the software development effort. This can have major implications on profitability, especially when you are developing custom applications in fixed-cost mode.
So how can we do a risk assessment early in the development cycle, and put in a robust mitigation plan in place?
A few years back, I read about the theory of “Broken Windows”. The theory originally proposed by James Q. Wilson and George L. Kelling in 1982, stated that maintaining and monitoring urban environments to prevent small crimes such as vandalism, public drinking, and toll-jumping helps to create an atmosphere of order and lawfulness, thereby preventing more serious crimes from happening. The theory comes from the following example.
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside. Or consider pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there.
Source (https://en.wikipedia.org/wiki/Broken_windows_theory)
Andrew Hunt and David Thomas, in their book ‘The Pragmatic Programmer’, fit this theory in Software development. Teams start a new project with a lot of fanfare, code analysis checklists, coding standard documents, and whatnot. Beautifully written clean code turns into a refactoring nightmare as there is eventual fire-fighting due to various reasons like deadlines, demos, etc. One broken feature, left unfixed for a substantial period, will encourage an “anything goes” attitude. Eventually, each member of the development team will stop caring about the high standards set for them before the development begins.
So, the idea here is to not live with broken windows i.e. technical debt. Each issue be it a defect or a refactoring task, needs to be fixed as soon as they are discovered. This instills a sense of responsibility in the development team, and no one wants to be the first one to create a mess.
Easier said than done, right!!
We at Equations Work use Test Driven Development (TDD) with our Agile-Scrum practice. And results are encouraging. TDD has its drawbacks, but I believe the advantages outweigh the drawbacks by far.
TDD, briefly is a software application development paradigm that requires the development team to create specific test cases, and then write logic to ensure that a test case passes. As new test cases are written, it is ensured that the older ones do not fail. Code is refactored once the test cases pass, and the cycle is repeated until all requirements are developed.
First, by writing a test case before the coding, the team understands what needs to be built and can come up with a strategy on how to build it. In practicality, the developers start thinking about the logic as they are coding. This introduces avoidable defects and smelly code.
Second, having a bigger picture, in terms of features to be implemented, the development team has a target to hit. They now have a checklist for each requirement in the form of test cases. The “Definition of Done” can be easily tracked with this close-ended checklist. This makes it easier for developers because we only understand the language of 0 or 1. The feature is either done or it is not, we don’t understand may-be!
Third, broken windows are traceable with TDD. Refactoring is important aspect of TDD and ensures that developers fix the smelly code before checking in their code to the source repository. Once you put a code-analysis checklist in place, this becomes a practice and developers have a target to hit.
Often people complain about TDD being time-consuming practice. But I believe, it is an investment of time, which you would do at beginning of your coding cycle. Once the platform is set, the benefits like lower defects, higher code coverage, etc. can be reaped till the very end of project execution.
Click edit to change this text. Lorem ipsum dolor sit amet...
