There has been some renewed discussion recently on the subject of technical debt, this has been played out on twitter as well as a variety of blog posts including this one.
The technical debt metaphor is one I use often and I believe that there is some clarification required around this subject.
At it’s broadest, technical debt is any trait of the current system that is considered sub optimal from a technical perspective. The debt aspect reflects the cost of ownership of that trait. For example and overly complex and untidy method is sub optimal, it incurs cost each time it needs to be re-visited and re-understood due to either a defect in the logic or a new requirement. This method obviously incurs more cost if it is re-visited more often.
Much of the debate recently has been focused on the times that it might be good to incur technical debt. The debt metaphor reminds us of borrowing money from the bank to get that new toy a little sooner. The question here is two fold, does technical borrowing exists and how can we view the rate of interest or total cost.
Before we can consider technical borrowing we need to split technical debt into two categories. First, the design or implementation decision that was sound the day it was made but now, with new information, is constraining our ability to progress. Second, the quick and dirty approach that we can see on the day of writing is gong to cost us very soon.
The first category of debt is a direct result of doing the simplest thing that could work and resisting the temptation to predict the future. We develop simple software that is easily changed through effective use of tests, the code that is written is written well. We categorise these design traits as debt when new information presents its self and we identify a change that will enable the system to serve us better. We may decide to make the change or not based on the ongoing cost of maintaining an design that no longer reflects our understanding of the problem or technology.
The second category is often the result of a deadline looming. A common chorus of “lets hack this in now and we’ll fix it later” is coupled with the nagging concern that later never arrives. In my mind, this category of debt can give the first category a bad name. But, is this thinking sound? Surely there are times when the wrong technical solution is the right business decision. It is my belief that there are situations where a quick fix is the right decision, imagine a major flaw that brings down a trading system. However, there are too many instances where code bases become un-maintainable through a feeling of time pressure that leads developers to incur debt with little or no benefit. In fact, in most cases, untidy, poorly designed software incurs cost both short and long term. In the short term, defects delay the release of the software and in the long term software is difficult to maintain and rigid in the face of changing business need.
So we arrive at technical borrowing. The decision to borrow must be explicit. As a team, along with appropriate stake-holders consider the decision. For example,
we have selected framework X for the next release, it does not offer the scaling flexibility we would like but we believe that our early entry to the market is a higher priority. We plan to move to framework Y in the next release window to achieve our target scaleability.
There are less extreme examples of refactorings that should be done but won’t fit in this iteration. Again, be explicit. Discuss the need for refactoring with your Product Owner or Project Manager, consider the cost of the refactoring, the cost incurred by not doing so, the risk of refactoring. One approach to maintaining a healthy code base is to keep a backlog of refactoring and allocate time in each iteration.
However, beware the temptation to save time, get it done, do a quick fix or tidy it up later. In almost all cases code that is hurried, poorly designed, overly complex or untidy will incur far more cost both short and long term than the time saved today by not doing it right.
Finally, this can be most difficult in a legacy code base where technical debt abounds. I use a simple motto that has served me well with a few teams:
Do no harm!
Where you cannot fix it all be sure to agree, as a team, that you won’t make it worse. In fact agree to making one small aspect of everything you touch better for the next person.
September 4th, 2009 in
technical |
No Comments
Last night the subject for debate at XTC was software craftsmanship. This is not a new subject but seems to be gathering momentum. In many ways I am a supporter, however, I do have certain reservations about the way it is being presented.
We have a draft of a manifesto for software craftsmanship that has been written to build upon the Agile Manifesto. Following this we have a host of proposed principles.
Personally I care about delivering quality software, I believe that software apprenticeships and effective mentoring would have a very positive impact increasing the skill of those involved in the industry. Finally, I believe that practice (i.e. doing a task followed by reflecting on the task purely for the purpose of learning) is largely ignored within our industry. If you care about what you build at work you should practice to develop your skill in your own time.
On the other hand I would prefer it if the concepts of craftsmanship and agile were kept separate. Being a craftsman is a personal choice independent from the process your team has selected. It is also a life choice since it is unlikely that you can be a craftsman 8 hours per day. By contrast agile teaches us about collaboration. I am sure that these two are compatible, even complementary but my preference would be to retain the separation.
There seems to be an increasing amount of discussion about software craftsmanship but what is it?
Thanks to Robert C. Martin for this great presentation about what it means to be a professional craftsman.
I’m sending this to everyone I can think of so I should let you know. This is recommended viewing for anyone who considers them-self a professional developer, software engineer or dare I say it craftsman.
In the presentation you will hear ‘Uncle Bob’ suggest that we have finally reached the point where we can discuss our profession. He goes on to talk of a variety of practices that have evolved to form the lynch pins of that profession. These include design principles, testing and my favourite, the following comment regarding defects:
Expecting QA to find bugs is unprofessional.
Last week was the Agile North Annual conference. I was invited to run an introduction to Ruby on Rails. On the request of the attendees I’ve attached here the presentation slides along with the application developed.
Read the rest of this entry »
September 27th, 2006 in
technical | tags:
Ruby |
No Comments
This week I had the pleasure of running a demo of Ruby on Rails for the agile north group. This was a well attended session that (much as I’d like to) I probably can’t claim all of the credit for. While I have not had a great deal of experience of Ruby on Rails I agreed to run this session in part to force myself to spend a little time on it.
There seems to be a real buzz about Ruby at the moment. People from a wide variety of backgrounds are looking at Ruby and particularly Rails trying to establish what the fuss is all about and if the promised productivity can pay off in their environment.
Read the rest of this entry »
June 20th, 2006 in
technical | tags:
Ruby |
No Comments
I found the following set of articles on Object Mentors site. I quite enjoyed them so thought I’d spread them about a bit.
The articles follow the story of a developer who is being taught TDD. A good intro and the primes exercise is a nice one to try yourself.
May 24th, 2006 in
technical | tags:
TDD |
No Comments
What flavour of session shall we have today?
In the agile community we like to share ideas and learn from each others sessions. In addition we borrow ideas from other communities. These three names (dojo, kata & randori) are borrowed from the martial arts world in an attempt to encourage programmers to practice.
The idea of practicing coding it quite unusual in the traditional sense, not least if programming is considered to be a solitary activity. People tend to think of years of experience as being all important. These types of sessions are intended to develop a group learning dynamic where all members leave the session having learnt something.
Read the rest of this entry »
April 16th, 2006 in
technical |
No Comments
I just read Jo’s comments about doing the simplest possible thing that could work here and they got me thinking.
I have spent a great deal of time teaching software design, designing for reuse and about the benefits of good architecture (be it layered or hexagonal). So I guess I’m one of those that occasionally does a little more than the minimum.
However, at what point in the project does a clean layered architecture become the simplest that could work? And, having reached this point how long is it likely to take to refactor into a cohesive architecture?
There is definitely a point at which developers start trying to predict the future and add features on the off chance that they become useful one day and this must be discouraged. Like many guidelines lets be pragmatic in the application of “do the simplest thing”.
April 12th, 2006 in
technical | tags:
design |
No Comments
This session was run by Michael Feathers (author of the book by the same name). To begin with Michael explained the term legacy; this refers to existing code without thorough test coverage. With this in mind discussion was aimed at C++, JAVA & C# applications that require extension. The goal is to achieve some of the benefits and confidence delivered by Test Driven Development (TDD) when developing on a none "green fields" project. If an application exists and added functionality is requested, should we be adding tests? Michael reasoned that the client did not want just the new functionality but the old too. To achieve this, tests should be added to ensure that the new software has no unwanted side effects.
Read the rest of this entry »
March 30th, 2006 in
technical | tags:
design |
1 Comment
I spend much of my time teaching OO. While it seems that modern programming languages are all about object orientation, how many developers are really embracing OO design?
In his article on getter eradication Martin Fowler says:
The OO community may have ‘won’ in the sense that modern languages are dominated by objects, but they are still yet to win in that OO programming is still not widely used.
This really struck a chord with me and also related to a post of Kevin Rutherfords on getting back to basics. Read the rest of this entry »
March 25th, 2006 in
technical | tags:
design |
3 Comments
