About   Slides   Home  

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

Technical Debt is Really a Lease

Friday, May 18th, 2012

At the last SDTConf, Todd Little facilitated a session called “Technical Debt is Really a Lease.”

I had a few interesting take-aways from this discussion:

  • A debt always has a notation that you need to pay it eventually (unless you default.) This is not true in case of a technical debt. There might be parts of your code which is a complete mess, but you don’t touch it and its fine to live with that debt. Or you might just decide to throw away that code since it served its purpose. You might never need to pay off that technical debt.
  • Deep down in our psychology, the term “debt” trigger a negative thought. We strive hard to avoid a debt. However if you project the same thing as a lease, it seems to have a more positive feel. In the business world, taking on a lease, in many cases, can give you a good business advantage. In fact some might even consider it to be stupid not to lease out stuff.
  • The important thing to consider is: what is the “Cost of Service” for a lease/debt? If the cost is significantly high, you are better off not taking it on. But if the cost is really low, it makes all economical sense to embrace it. We’ve learned that long-term, heavy interest leases/loans are a bad idea for that very reason. But a short-term, low interest loan can provide extra working capital to expand business.

IMHO it can really help teams to think of technical debt really in terms of the “cost of service” of a lease.

Beware not to make technical debt a dumping ground for tasks that the team wants to defer without a conscious, thoughtful reason. I’ve seen in many organizations, technical debt becomes an easy excuse for the team to skip things that are very important but for their short-sighted hasty decisions.

Why I don’t believe in Organizing Large Scale Conference?

Sunday, November 6th, 2011

Over the last 7 years, with the help of various passionate folks, I’ve organized 50+ conferences. (Agile India Conferences, Simple Design and Testing Conference, Agile Coach Camp and CodeChef TechTalks to name a few.)

Most of these conferences were small to medium scale conferences in the range of  50 to 375 delegates.

Why we never organized larger conferences? Was it because we were not capable of organizing them? Or was there something stopping us from doing so?

Personally I prefer organizing small scale conference over large scale conference for the following reasons:

  • In my experience the quality of interaction and experience speakers & participants have is inversely proportional to the size of the conference.
  • Cost to run the conference exponentially increases with size. As the size increases:
    • we need a bigger venue, which does impose a significant cost.
    • overall logistics becomes lot more complex. Need extra planning and coordination. Again increasing cost and making the overall plan less adaptive.
    • the participant price has to be increased – which means, most participants won’t be able to self fund their registration. They’ll depend on their companies to sponsor them. This leads to many people who actually do get sponsored by their companies are the ones less inclined to learn at the conference. Which again impacts the overall quality experience of others participants.
    • we become more dependent on the sponsors. The more we are dependent on sponsors, more their demands. Inevitably leading to compromising the conference. Sometimes sponsors want speaker slots (esp. keynotes) for sponsorship. Also they further complicate the logistics.
  • Are less inclusive from smaller companies and individual’s point of view. Cost is one aspect, but also because there would be a larger number of participants from big companies, the interactions at the conference take a very different dynamics.
  • Right from the beginning, large conference have a fear of not attracting enough delegate and sponsors. To mitigate that risk, most large conference programs are filled with Big names. Who mostly present the same old topics which have been beaten to death over a decade. We like it or not, the overall program tends to be more focused on basics (least common denominator) and seems to attract mostly beginners who are willing to pay that kind of money. Innovative and disruptive ideas are mostly neglected. Because they would really be disruptive for the audience.
  • Because of the previous point, the real practitioners, doing really meaningful work, tend to shy away from such conferences. Again leading to poorer quality conference.
  • Marketing and Branding effort: Large conferences need huge effort and funds to market and brand themselves. Smaller conferences are mostly marketing and branded through word of mouth and these days with social media.
  • The effort and time it takes to organize one large, centrally located conference, in that much time, we could easily organizer 3-4 smaller, more local conferences. Smaller conferences surely reduce the costs for participants. Smaller conferences encourages more of a distributed, sustainable, local community.

I could spend rest of my sunday afternoon thinking about this and I’m sure I’ll come up with 10 more points against large conference. Having said that, large conference do have some clear advantages that smaller conference cannot achieve. the splash, the penetration, cross pollination, etc. etc.

However I think its clear, at least to me, why I prefer smaller conference.

It cool to have thought thru the issues and to have the points flushed out. But to avoid dogmatism, its always important to reevaluate your points every few years. Which is one of the reasons, I decided to help organize Agile India 2012 Conference.

Simple Design and Testing Conference: London, UK 12-13th March 2011

Thursday, January 20th, 2011

Simple Design and Testing Conference is an all open space conference providing software practitioners a platform to meet face-to-face and discuss/demonstrate simple design & testing principles/approaches.

At this conference you’ll meet real, hands-on practitioners interested in peer-to-peer learning and exploration. We strive hard to avoid fluffy, marketing talks and other non-sense.

  • What: Open Space Conference on Simple Design & Testing practices
  • Where: Skills Matter eXchange, London, UK
  • When: 12th-13th Mar 2011
  • Who: Software Practitioners (Developers, Testers, UX Designer…)
  • Cost: £50.00, also (Position Paper required!)

SDT Conf 2011 is our 6th annual conference and for the first time in Europe. Check out the past conference SDT Conf 2006, 2007, 2008, 2009 and 2010 details.

Register now…

5th Annual Simple Design and Testing Conference, Columbus, Ohio, USA, Oct 29th to 31th 2010

Tuesday, October 12th, 2010

I’m proud to announce the 5th Annual SDTConf. This year we plan to hold the conference in Otterbein University Campus Center, OH, USA.

We plan to keep a max cap of 100 participants for this conference.

As you might be aware SDTConf is a free conference and we use the concept of position papers as the price for admission. This helps us ensure the quality of the participants is really high. You can add your position papers for the conference on our wiki. Making the position papers public helps other participants gauge in advance what they can expect from the conference.

Last but not the least, since this is a community run, non-profit event, we really on sponsorship in kind to make this event possible. Here is a list of items that you or your company can sponsor to support this conference.

P.S: Please blog about this conference and/or send an email to your friends and colleagues. Word of mouth is the only way we market this event.

Simple Design and Testing Conference: Interview on InfoQ

Thursday, June 17th, 2010

Mike Bria of InfoQ interviewed me yesterday to find out what is happening with SDTConf. Here is the interview notes on InfoQ. Enjoy!

Simple Design and Testing Conference 2010 in India

Saturday, May 22nd, 2010

I’m planning the Simple Design and Testing Conference (SDTConf) for the first time in India around end of June.

SDTConf is:

  • All Practitioner conference (No Jokers giving lectures)
  • All Open Space (discussions and lots of hands-on workshops)
  • Invitation Only Conference
  • I’ve organized this conference in the US for the last 4 years.

Levels of Duplication

Wednesday, October 21st, 2009

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)


       for(int i=0; i < someList.size(); i++)
    • 2nd Level: Ex: Looping over an array of elements instead of each element in a different line


       for(int i : asList(1,3,5,10,15))
    • 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.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.

Biggest Stinkers

Monday, October 19th, 2009

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):

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.

Where is the real innovation happening?

Sunday, October 18th, 2009

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
  • 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.

Behavior (verbs) as Test Class Names

Monday, June 15th, 2009

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)

    Licensed under
Creative Commons License