“We have found 150 defects in your application, out of which 50 are new, 50 are closed, and 50 are re-opened”.
This is typical scenario that lead 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-open 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 risk assessment early in the development cycle, put in a robust mitigation and a contingency plan in place?
Few years back, I read about 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 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 a 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 lot of fanfare, code analysis check-lists, coding standard documents, and what not. Beautifully written clean code turns to 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 began.
So, idea here is to not live with broken windows i.e. technical debt. Each issue be it defect or a refactoring task, needs to be fixed as soon as they are discovered. This instils the sense of responsibility in development team, and no one wants to be the first one to create a mess.
Easier said than done, right!!
We at Equations Work recently started using 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 passes, and the cycle is repeated until all requirements are developed.
First, by writing test case before the coding, team understands what needs to be built and can come up with strategy on how to build. 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, development team has a target to hit. They now have a check-list for each requirement in form of test cases. The “Definition of Done” can be easily tracked with this close ended check-list. 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 source repository. Once you put a code-analysis check list 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 in 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.
Workflows and more... 