Act on those broken windows now

“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 (

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.

Posted in Misc | Leave a comment

C#: Why default fall-through in switch statement is not allowed?

I was working on this particular piece of logic which I saw as a multiple sieve like structure. An if-else statement which would check the value of a number and based on the value, it would also execute the code for all the values less than it.

For example, user could submit x number of projects to be processed in one request. User could add a minimum of 1 to a maximum of 5 projects in one request.

Based on the number of projects user added, I had to write a logic to check a certain value in each project form. So if user had added 3 projects, I would check project 1, 2 and 3. Continue reading

Posted in Misc | Tagged , , | Leave a comment

SharePoint 2010 State Machine Workflows with Custom Task Forms (InfoPath) using VS 2010 – Part 3 of 3


In the Part 3 of the tutorial, I will explain the process of sending data from the workflow to the task form (InfoPath). In Part 2 of the tutorial I explained retrieving the data from InfoPath form in the workflow by using the Extended Properties of the Task Properties. We will use the Task Properties object to send the data from our workflow to the InfoPath Form.

Continue reading

Posted in Misc | 2 Comments

Template Id and Template Type mapping

In continuation of the previous post, below is the Template Type and Id mapping

Template Type
Generic list
Document library
Links list
Announcements list
Contacts list
Events list
Tasks list
Discussion board
Continue reading
Posted in Misc | Tagged , , | Leave a comment