About   Slides   Home  

Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
RSS Feed
Recent Thoughts
Recent Comments

Another Example of Thin Slice

On the Protest project when I was building the “integration with Ant” feature, I adopted the same thin slice principle. Following are the thin slices I came up with:

  • Create an Ant task which can call Protest, it simply returns the tests in the same order as given to it. (Essentially was a copy of the JUnit Ant task)
  • Add support for a voter (happened to be Dependency Voter), so that we can actually prioritize the tests based on the dependency algorithm. At this point we went ahead and released this task
  • Add support for multiple voters. By now we had created 3 different voters and we wanted to use all the voters
  • Provide a way to specify weightage for each voter. Some voters should be able to influence the prioritized list of test more than the others
  • Once we have a prioritized list of tests, provide a way to specify what top percentage of that list should be executed. This provides the user tighter control over how much feedback they need depending on the type of change they have just made
  • And so on…

Now we could have sat and first designed how the Ant task should look and later wrote the task and then integrated with Protest. But the problem with this approach is:

  • We won’t have anything functional and usable until we finish all the tasks. Too scary from a feedback standpoint
  • We won’t be able to test anything for real until we finish all the tasks. There is a huge risk involved in this approach
  • Essentially we are building an inventory with each of those tasks that are not used immediately. Turn around time for a feature is high
  • It requires a lot of upfront thinking, which I’m not generally good at. At least we’ll have to think through all the input each voter would need and so on. Right now we don’t even have all the voters in place and this forces us to think about them now or introduces an unwanted dependency now.
  • Lots of people argue that the evolutionary approach will be less efficient (more expensive and time consuming) because it gives an impression of thrashing and rework. In my experience, the big upfront design leads to more rework generally. It creates an illusion of streamlined process but in reality, it is actually lot more work and also leads to a rigid and over-engineered design
  • We can also add all the disadvantages of big upfront design here

I hope this example demonstrates the technique of thin slicing and its advantages over its alternatives.

    Licensed under
Creative Commons License