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.

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.

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.

The session had no pre-requisits so began with an introduction to Ruby. Following a brief introduction I showed some of the driving principles behind Rails including coverage of the benefits & implications of MVC.

In an attempt to demonstrate the productivity of rails I built a web based application for tracking hours spent on tasks. The app was developed over three iterations.

• Manage tasks
• Add rendering of instalments (lumps of time spent on tasks)
• Add management of instalments

The rails project and pdf of slides is attached below.

Slides Project

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.

I took my inspiration for the session from an onlamp article that describes the development of a cookbook web application. I made a number of changes to bring the demo up to date, in particular the adoption of migrations and some further emphasis on testing.

The mixed group that is always in attendance with agile north provides for an interesting mixture of view points. I was somewhat taken aback by the suggestion that migrations should be test driven. This was a significant point that had not yet occured to me. However, when relying on migrations to move databases from on version to the next we need a mechanism to improve our confidence. I would particularly like to see tests for migrating to older versions.
I did alow a little too much emphasis to be put on the benifits of scaffolding, while it’s nice to get the rapid feedback that scaffolding provides I would have liked to spend a little more time developing “real” code (test first of course).

Below I have attached, as requested, a few slides and a zip of the Rails code that we produced during the session. In addition check out the agile north del.icio.us tag for other peoples views and other relevant links.

• Slides
• Project

I’m sure that this is not the last post I’ll make about rails, I look forward to making the most of this highly productive environment on a number of projects that I have in mind.

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.

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.

The dojo is the place we go to practice, for examples see the dojos run by AgileFinland, Laurent Bossavit’s monthly Coding Dojo in Paris, and my own local AgileNorth dojo in the UK.

Dojo sessions can be run in one of a number of ways.

• Choreographed session with leaders talking through decisions.
• Interactive sessions, a pair start to solve a problem, every 5 to 10 minutes one member of the pair is exchanged. Sometimes known as randori.

I am not a big fan of choreographed sessions. While there is value in demonstration I prefer this as an introduction to the session rather that a session in itself. I have felt somewhat detached from the decisions being made in the past.

The agile north sessions that I have been involved in have been in the randori style. We used the dojo to allow people to try TDD. To enhance the involvement of the audience they were asked to supplement the role of the second member of the pair by suggesting tests. The rational behind which test to do next was (for me) the most important output from the session.

Dave Thomas has been instrumental in publicising the benefits of coding katas. A kata is a small task that can be used by an individual to practice his craft. Through repetition one can achieve new insights even with a well known problem. My personal favourite is implementing the model behind Conway’s game of life.

Of course a kata is a good candidate for use in either type of session. However, for me there is an important extra aspect that shouldn’t be forgotten. After a kata, be it group or individual time must be set aside for reflection. During this retrospective we must take time to think about

• What did we do well?
• What did we learn?
• What would we do differently next time?
• What still puzzles us?

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

In order to test areas in isolation we must remove dependencies in the code base. Examples of unwelcome dependencies are; the use of singletons, internal instantiations and concrete dependencies.To expand on these:

• The singleton pattern is, in my opinion, overused. In fact I have heard it described as an anti-pattern. When test driving code singletons become even more problematic. If left in place, the singleton is a barrier to our goal of independence between tests. One member of the group suggested that "singletons are OK so long as they have no state and no behaviour". However, as a dependency exists between the class under test and the singleton class we cannot test without the singleton.
• The term "internal instantiation" refers to the creation of one class from another. This structure results in a direct dependency from one to the other. The impact again is the inability to test a class in isolation.
• Concrete dependency describes the previous two cases and many more. Any direct dependency on a class (rather than interface) is cause for concern.

The most direct approach to all of these is to extract an interface and parameterise methods or constructors with reference to that interface. However, some will argue that the code is not quite perfect.

Michael reminded us of a Voltaire quote: "Best is the enemy of good". We need to make many small improving steps. Do not look for perfection in one step.

The following algorithm was suggested as a route to making a change

1. Identify change point
2. Identify test points
3. Break dependencies
4. Write tests
5. Refactor or change.

When writing tests we often wish to replace real behaviour with test behaviour. The example given was to stub out code that sends an e-mail. In this situation we wish to change the behaviour of a peace of code without touching it. The approach described by Michael was to identify seams. Examples of seams are:

• Pre-processor – for example, remove the use of the doIt method with #define doIt doSomethingElse.
• Linker – this technique in C / C++ is called link time polymorphism. All we need to do is link in an alternative library implementing the same classes or functions. In JAVA we can consider the class loader as operating at this seam.
• Polymorphism – in OO languages our most effective seam is polymorphism, this is the run time dispatching of calls due to inheritance.

The next technique to be presented was, when trying to stub out utility classes introduce an instance delegator. This involves gradually turning a utility class into a real class. Finally Michael suggested an added benefit to reducing dependencies, to often teams have policy of going for a brew while waiting for a build. Reducing dependencies allows localised development with minimal compile time.

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.

I can think of a few groups of people who fail to apply OO principles for differing reasons.

1. The “functional programming works” crowd – I have worked with C programmers who are willing to accept bits of C++ syntax but believe firmly that OO does not work.
2. The “pure OO is for small talk” crowd – I remember being told in a coding dojo that, while a domain entity certainly had both state and behaviour, it would be inappropriate to represent it with a class as this was JAVA and not Smalltalk. I find it difficult to understand this approach.
3. The design according to technology crowd – there are technologies that can lead developers away from OO. Service oriented architecture seems at first glance to encourage design in terms of functions offered. I have, I hasten to add, no problem with SOA as a facade to a clean object model.

Unfortunately when trying to advocate the proper application of OO there is a stumbling block. Few organisations have managed to achieve the promised reuse that OO was supposed to bring.

In response all I can say is that OO makes my life as a developer easier. I can concentrate on one thing. Once a class is tested I can largely forget about it. Finally the object community have provided me with a recipe book to achieve design level reuse.