Agile India.

Starting with the obvious forms of duplication like Cltr+C & Cltr+V pattern to more subtle forms of duplication:

• Literal Duplication. Ex: Same for loop in 2 places
• Semantic Duplication: In essence the code does the same thing, but is syntactically different. Again there are sub-levels:
  • 1st Level: Ex: for and foreach loop

     for(int i : someList)
        stack.push(i);

    v/s

     for(int i=0; i < someList.size(); i++)
        stack.push(someList.get(i));

  • 2nd Level: Ex: Looping over an array of elements instead of each element in a different line

     stack.push(1);
    stack.push(3);
    stack.push(5);
    stack.push(10);
    stack.push(15);

    v/s

     for(int i : asList(1,3,5,10,15))
        stack.push(i);

  • 3rd Level: Ex: Loop v/s Recursion
• Data Duplication. Ex: Some constant declared in 2 classes (test and production)
• Structural Duplication: Ex: Parallel Inheritance Hierarchy
• Conceptual Duplication: Ex: 2 Algos to Sort elements (Bubble sort and Quick sort)
• Representational Knowledge Duplication: Commonly know at WET (violation of DRY - Don’t Repeat Yourself)
• Duplication of logical steps: Same set of steps repeat in different scenarios. Ex: Same set of validations in various points in your applications
• Duplication of statement fragments: Same sections of a statement repeating. Ex:

   Assert.IsTrue(response.HasHeader);
  Assert.IsTrue(response.HasMessageId);
  Assert.IsTrue(response.Has("X-SenderIP: " + senderIp));
  Assert.IsTrue(response.Has("X-SenderDomain: " + senderDomain));
  Assert.IsTrue(response.Has("X-recipientDomain: " + recipientDomain));
  Assert.IsTrue(response.Has("X-SPF: " + spfValue));
  Assert.IsTrue(response.Has("X-1stClassification: " + firstClassificationResult));
  Assert.IsTrue(response.Has("X-2ndClassification: " + secondClassificationResult));
  Assert.IsTrue(response.Has("X-3rdClassification: " + thirdClassificationResult));
  Assert.IsTrue(response.Has("X-MANUALLY-CLASSIFIED: " + manuallyClassified));

  Once we clean this up, it might look like:

   lets.checkThat(response).HasHeader.HasMessageId.Has + "X-SenderIP" = senderIp + "X-SenderDomain" = senderDomain
          + "X-recipientDomain" = recipientDomain + "X-SPF" = spfValue + "X-1stClassification" = firstClassificationResult
          + "X-2ndClassification" = secondClassificationResult + "X-3rdClassification" = thirdClassificationResult + "X-MANUALLY-CLASSIFIED" = manuallyClassified;

Thanks to Corey Haines and the folks who participated in the Biggest Stinkers session @ the Simple Design and Testing Conference 2009. Most of this information was discussed during that session.

At the SDTConf 2009, Corey Haines & I hosted a session called Biggest Stinkers. During this session we were trying to answer the following two (different) questions:

• As an experienced developer, looking back, what do you think is the stinkiest code smell that has hurt you the most? In other words, which is the single code smell if you go after eradicating, *most* of the design problems in your code would be solved?
• There are so many different principles and guidelines to help you achieve a good design. For new developers where do they start? Which is the one code smell or principle that we can teach new developers that will help them the most as far as good design goes (other than years of experience)?

Even though the 2 questions look similar, I think the second question is more broader than the first and quite different.

Anyway, this was probably the most crowded session. We had some great contenders for Smelliest Code Smell (big stinker):

• Corey Haines suggested, Duplicate Code
• I suggested, Primitive Obsession (Dealing with low level data structures/data types when higher order abstractions can reduce complexity n-fold. This is not specific to OO. Its about lack of abstractions at the right level)
• Matt Van Vleet suggested, Single Responsibility Principle
• Venkat Subramaniam suggested, Don’t write code
• Jim Weirich (was not present at the conference) suggests, Connascence

We all agreed that Don’t write code (write new code only when everything else fails) is the single most important lesson every developer needs to learn. The amount of duplicate, crappy code (across projects) that exists today is overwhelming. In a lot of cases developers don’t even bother to look around. They just want to write code. This is what measuring productivity & performance based on Lines of Code (LoC) has done to us. IMHO good developers are 20x faster than average developers coz they think of reuse at a whole different level. Some people confuse this guideline with “Not Invented Here Syndrome“. Personally I think NIHS is very important for advancement in our field. Its important to bring innovation. NIHS is at the design & approach level. Joel has an interesting blog post called In Defense of Not-Invented-Here Syndrome.

Anyway, if we agree that we really need to write code, then what is the one thing you will watch out for? SRP and Connascence are pretty much helping you achieve high Cohesion. If one does not have high cohesion, it might be easy to spot duplication (at least conceptual duplication) or you’ll find that pulling out a right abstraction can solve the problem. So it really leaves Duplicate Code and Primitive Obsession in the race.

Based on my experience, I would argue that I’ve seen code which does not have much duplication but its very difficult to understand what’s going on. Hence I claim, “only if the code had better abstractions it would be a lot easier to understand and evolve the code”. Also when you try to eliminate duplicate code, at one level, there is no literal code duplication, but there is conceptual duplication and creating a high order abstraction is an effective way to solve the problem. Hence I conclude that looking back, Primitive Obsession is at the crux of poor design. a.k.a Biggest Stinker.

It appears to me that the Agile Community is falling behind the innovation curve. At conferences, user groups, mailing list, etc, we see the same old same old stuff (may be I’m missing something). So where is the real innovation happening? What space should I be watching?

These were the questions I posed to the group @ the SDTConf 2009. Later, during our discussion at the conference we tried answering them. After a wonderful discussion we come up with some suggestions:

• Web 2.0
  • Highly Scalability, Performance and Operations space
  • No SQL
  • Continuous Deployment and Monitoring space - Owen’s Slides are a good starting point
  • Watch out for conferences like O’Reilly’s Velocity
• Alternative Language (non-mainstream languages) space. Lot of interesting experiments going on in
  • Dynamic language space
  • Functional language space
  • Hybrid language space
• Domain Specific Language space
• Could Computing, Parallel Computing (Grid Computing), Virtualization space
• Code Harvesting Space - Check out Test Driven Code Search and Code Genie as a starting point
• Complex Adaptive Systems and its implication on our social interactions space. Dave Snowden’s work is a good starting point
• eLearning and visual assessments (feedback) of a programming session. Check out Visualizing Proficiency
• Polyglot Programming space
• With Google Apps, people are able to build 100s of Apps each month and get instant feedback on their ideas
• Social Networking and Second Life space
• Conference: Lot of interesting experiments are been conducted in the conference space. Conferences have evolved to something very different from before.
• Distributed Development and Remote Pairing space

If you would like to contribute to this list, please add your point on the SDTConf Wiki.

For the last 3 odd years, I’ve been exploring the use of behavior (verbs, instead of Nouns, Test) as my test class names. The verb describes what behavior you expect from your system (program).

For example for a Veterinarian Information System (system responsible for billing and patient history), I would have tests called:

ChargeAccountForServices with the following test methods:

• makePaymentsAgainstAnAccount()
• completePaymentsResultInZeroAmountDueOnReceipt()
• incompletePaymentsDisplaysDueAmountOnTheReceipt()

Another test class: GenerateBillsForClientAccount with

• notifyIfAccountIsNotDueForPayment()
• billContainsTotalCostOfAllServicesTaken()

And another test class: ManageClientVisits with

• trackAllServicesTakenByThePatient()
• skipVisitIfPatientDidNotTakeAnyService()

These tests helped us flush out Objects like Account, Procedure, Visit and so on…. When we started we had no idea we’ll need these objects.

This style is mostly influenced from a pairing session with Corey Haines post our discussion about “There is no Spoon” @ the SDTConf 2006.

For more about this approach…read my last post…There is No Spoon (Objects)

Just got back from the 3rd SDTConf. I’m very happy with the conference overall. We had over 40 participants at the conference. (A little less than I expected, but they were all really passionate people). That’s right, Quality OVER Quantity.

We discussed some really interesting topics. Check out the conference schedule for more details. I also got to pair with Micah Martin on the Avatars of TDD. It was fun. We hacked some Ruby using RSpec.

Big thanks to Jim Newkirk for helping me organize this. Also big things to all our sponsors, Microsoft, Agile Alliance, Rally, Version One, SQE and Open Information Foundation who made this conference possible.