Thursday, March 17, 2011

Theory of Constraints: Agile Programming

I am on an agile project surrounded by a team of smart developers. Recently, we started mentioning “refactoring” in our stand-ups. The business who participated in our stand-up interpreted “refactoring” as not producing new code for new features. As a result, the business cringes every time we mention the word.

After we learned that the business had concern with our refactoring effort, we tried to come up with some good explanations to convince them that it is a good idea to continuously improve our code. The following is a list of reasons we initially came up with:
  • Reduce code duplication
  • Improve code maintainability
  • Improve code testability
  • Improve code re-usability
  • Improve code quality
The above is a list of agile programming best practices. They make sense to agile developers. To the business, the agile programming best practices are just busy work that prevent them from getting their new features sooner. The business understands the importance of having a good quality software. However, they think it is a long term investment that don’t yield ROI in the near future.

I need a way to layout my thoughts so that I can identify the conflict and common goal. This is where Evaporating Cloud comes in handy. It is one of the six Thinking Processes in Eliyahu Goldratt’s Theory of Constraints. After several tries, I managed to construct the following evaporating cloud:

I will start with the common goal. In order to deliver features faster, I should write new code. I agree. On the other hand, in order to deliver features faster, I should write less code. That makes more sense to me since I am a developer. Code re-usability is a big part of what I do everyday. Next, to the conflict (indicated by lightning bolt). In order to write new code, I should not refactor code. However, in order to write less code, I should refactor code. The conflict is obvious. I cannot refactor code and not refactor code at the same time.

After giving the conflict some thought, it becomes clear to me that it is possible to come up with a compromise. I don’t have to stop refactoring code in order to write new code. In fact, I can do better. If I refactor the existing code, I can write less new code for the new feature. Consequently, I can deliver the new feature faster. What I should have told the business at the stand-up is: Refactor code in feature X to help with new feature Y development. During the next stand-up, I started using the above statement to report my status and the business seemed receptive. The business really sees their ROI when our team starts delivering features faster.

The end result is that the business does not care if we refactor our code or not as long as it helps to deliver new features faster. In return, we promise not to refactor code that does not provide business value. For example, we will not refactor code based on the assumption that it will be re-used in the future. Premature refactoring not only violates YAGNI agile programming principle but also fails to deliver business value. Evaporating cloud is helpful to find a resolution to conflict faced by two parties. It produces win-win solution.

1 comment:

  1. This comment has been removed by a blog administrator.