Sunday, May 31, 2009

Containing technical debt

One of the most important concepts in Software Engineering is "Technical Debt." It was first introduced by Ward Cunningham in 1992 in an experience report at the OOPSLA. If you haven't heard the term before or want to refresh your memory, I have collected articles/blogs on the topic that I thought have done a good job of explaining it.
  • Here is Ward Cunningham explaining his thoughts behind why he coined the metaphor on wiki and also in a video talk.
  • Here is a blog by Martin Fowler on the topic.
  • Here is a personal blog by Dharmesh on the same topic.
I was at an Open Space session on technical debt at Orlando Scrum Gathering early this year. What seemed to be on everybody's mind was how to protect our projects from going bankrupt under the burden of technical debt. We all agreed that it is easy to deal with debts that we take on knowingly. The real challenge is to identify debts that creep up on us over time (like credit card debt- a little here, a little there, some missed payments, and voila...). We get caught by surprise until it is too late.

I am going to suggest a few things when put into regular practice can help you contain the debt to a minimum.

1. Low test coverage can contribute to hidden technical debt. When we are under time pressure, guess what gets cut from the budget? "testing!" It may seem innocuous to eliminate funding for "testing," it can push the project to bankruptcy when done on a regular basis. So, target 90%+ test coverage and track it through continuous integration.

2. The best "architecture" is not static, it is evolutionary that emerges over time. What is important though is "consistency." If we are always doing the same thing the same way, the chances of incurring hidden debt goes down. The consistent way of doing things needs to be a shared knowledge best captured as a list of "How Tos" and needs to be kept in synch with the evolving architecture. Do you have one such list for your project?

3. Review architecture at a regular interval to spot inconsistencies. I am sure you will find some even after you have a published "How Tos." As soon as you find them, fix them.

4. I have seen bugs are triaged and then some are deferred to be fixed in the future in favor of some "important" new features. The fallacy lies in the notion that cosmetic/minor bugs are harmless. What is harmless today can compound into a significant issue later somewhere else in the system. Personally, I always like to fix all bugs before I do any new development. However, I can understand that we may need to do it at times, but it should be "exception" than "norm."

5. Last but not least, if you must take on a debt, get a commitment to payback in full by a specified timeline. Then track and report on it like a hawk (not like the Fed or SEC).

How are you containing technical debt on your project? Care to share?

Wednesday, May 20, 2009

Why should you consider Ruby on Rails for your next project?

I am sure many of you are asking yourself- so, why should I use Ruby on Rails (a.k.a. RoR) for my next project? I am going to share with you why I would. It is the Rails, the application framework, that is the force behind RoR. What Rails does is constrains developers in this predefined application structure with necessary elements required to build a reasonably good enterprise/commercial strength Web-based solution. Constraints can be liberating. It is certainly true for RoR. As a result, you can expect to build an application of reasonable quality with a less experienced/young team faster than any other technology, for example, Java/.Net (assumption is the team has the same years of experience with both technologies ). The database migration tool that it provides to help with incrementally building the database alone can be reason enough to give it a serious thought. Rails' simple yet elegant plugin architecture have fostered a large active community of plugin builders. You can find many useful plugins that are needed for many applications. These plugins could speed up your development time even faster.

We all know imitation is the highest form of flattery. It is true for Rails too. Rails has inspired many copycat frameworks in many languages. Even Microsoft has taken a notice of it. Microsoft has recently published its Rails-inspired MVC framework for its .Net platform. Please remember, these Rails-inspired MVC frameworks do not give you all the things that you get from Rails to make your team hyper productive.

While RoR philosophy of "Convention over Configuration" contributes to developers' productivity, it could also be limiting for certain situations. RoR is good for new applications as well as porting existing applications where your existing databases can easily support "Single Table Inheritance" in your domain.

I have heard many expressed concerns about Ruby's performance because it is a dynamic language. It reminds me of Java's early days. We have come a long way since then. We have many high traffic RoR applications in production. Ruby is now supported on Java VM through JRuby and on .Net CLR through IronRuby. Performance should not be a concern for RoR applications that can also be built using Java or .Net. If you are not convinced, here is a very good case study on YellowPages.com that should remove all your concerns about RoR. If you are still not convinced, David Hansson, the man behind the Rails, talks about why scaling with RoR is boring...:-)

Are you considering RoR for your next project? Did you recently complete a RoR project? Please feel free to share your experience with us here.

Monday, May 18, 2009

The Dream Team of Agile Software Development

If you had to put together the best team possible for the most complex project and money is not a concern, who would you have on your team? I can tell you who would be on my "The Dream Team."

Product Owner- Mike Cohen

Scrum Master- Ken Schwaber

The Development Team

Kent Beck
,
Bob Martin,
Jim Copline,
Martin Fowler,
Alistair Cockburn,
Ward Cunningham,
Jeff Sutherland,
Ron Jeffries, and
Jim Highsmith

I am making an assumption that they all still write software and will be able to work with each other...:-) Now the questions are-

  • Is this team going to be the most hyper-productive team ever in the history of software industry?
  • Are they going to follow Scrum? Or, are they going to come up with something new? Should we call that "Scrum But?"
Just wondering. Unfortunately, the reality is much more constrained. We need to work with a team that we can reasonably put together. The reasonable expectation is to have individuals who are average. I always wonder why people are so obsessed with hiring the best/brightest from Standford or MIT. I guess I do not fall in that category (and hence the grape is sour!)...:-) However, I sure can bet my money on my team that it can go head-to-head with any dream team in the world. I am sure so is yours.

The focus should be "The Team," not the individual. Do me a favor, when you look for a new team member, mention in your Ad- "Looking for the best team member."

What do you think? Who would be on your dream team?