Friday, March 26, 2010

Technical Debt, Non-Technical Managers and Tony Soprano

Yesterday’s Ignite Your Coding webcast featured Dave Laribee speaking about technical debt.  It was very insightful and Dave made several great points that make the technical debt metaphor more powerful.  One point that struck a cord with me was that of “high-interest debt”.  I’ve always found the technical debt to be a very powerful when talking with other developers, however, it seems to lose it’s effectiveness when talking with non-technical managers.

A Short Story

A few years ago I worked on a project that had a lot of technical debt, like mountains of debt.  New development was painfully slow because of all the crappy code that we had to wade through just to make a simple change.  The dev team had all sorts of inside jokes about it and any estimates that were given were always padded with a hefty “tax”.  We all knew that we had loads of technical debt and had to do something about it, but the message always seemed to get lost when communicating this to management.  Looking back now I can’t blame them at all because in their eyes, debt was how you grew the company.  The company had been built with loans from angel investors and venture capitalists and this was considered a good thing, this is how the company was able to grow to the size it had in the short period of time that it had.

High-Interest Debt

What we as a development team failed to communicate was that the technical debt we had incurred was not the technical equivalent of loans from angel investors and venture capitalists.  No, we had borrowed from Tony Soprano and every other loan shark in town, we’d maxed our the credit cards and had 3 mortgages on our homes.  The fact is that in software, the interest rate on technical debt can run much higher than what business people are used to in the financial world.


This is the inherent danger of all metaphors, they only take the concept so far and end up implying meaning that was never intended.  As business person already has preconceived notions about borrowing and debt that they will carry with them when speaking about this metaphor.  From now on, I will make an effort to clarify the “interest rate” when speaking about technical debt to non-technical managers.

Paying Down Technical Debt

I would be remiss if I didn’t touch on strategies for paying down technical debt and the best resource I’ve seen is Dave’s article in MSDN magazine titled “Using Agile Techniques to Pay Back Technical Debt”.  Go check it out so that you can start to pay down your debt and get Tony off your back so you won’t end up swimming with the fishes!

Thursday, March 18, 2010

Speaking on Domain-Driven Design at .NET BC User Group

I confirmed this week that I’ll be speaking at the .NET BC User Group in July.  The title of my talk is “Domain-Driven Design: Redux” and it is a reflection of how I would have preferred to learn Domain-Driven Design if I got the chance to start again.

There is a scene in Good Will Hunting where Ben Affleck’s character, Chuck, is in a bar trying to pick up a girl.  Another guy steps in a tries to show up Chuck by spouting his opinions on what he learned in an MIT class that Chuck said he had taken.  Matt Damon’s character, Will, steps in to confront the other guy and lectures him that he only holds his current opinions because he hasn’t taken the follow up course yet, and when he does, he will predictably hold a different opinion.  The point here is that Will has already taken the journey through the stages of learning and he recognizes the mistakes that the other guy is making, simply because he hasn’t progressed far enough in his thinking to understand the higher concepts.

This is a pattern that happens in Domain-Driven Design all the time, I went through it myself, and it sucks.  When I first learned about DDD I was so caught up in the details of entities, value objects and services, that I lost sight of why I even cared about these patterns.  I spent days trying to decide whether or not entities were allowed to call into services, I spent weeks searching for sample applications that modeled simple domains, I spent months figuring out how I could break the aggregate root pattern.  These are all common stages that DDD newbies progress through, and they’re all pretty much irrelevant to DDD.

Domain-Driven Design newbies tend to focus on the details of the mechanics of DDD rather than focussing on the essence, “tackling complexity in the heart of software.”  When we ignore the essence and focus on the mechanics, the mechanics feel very cumbersome and many people get frustrated by the complexity that they feel DDD has added, exactly the opposite effect that was desired.

This talk will emphasize the parts of Domain-Driven Design that I find are the most valuable.  By focusing on these essential elements, the mechanics become more natural and have their intended effect of making complex logic more easily represented in code.  If you’re interested in hearing more, please join us on July 7th 2010 at the BCIT Burnaby campus for a jam packed evening of all things DDD.  More details here:

Wednesday, March 10, 2010

Judiciously Exposing Collections in the Domain

This is a follow-up to Jimmy Bogard’s blog post found here:

Jimmy does a good job of explaining why exposing your collections as IList or IList<T> is likely not the best choice for your domain.  His basic argument is that collections should only be exposed as immutable collections to client code.

Like Jimmy, I often expose collections as IEnumerable<T> but have run into problems with that too.  While IList<T> with its 9 methods and 3 properties is  exposing more than you want to, IEnumerable<T> often proves too limited with only its single GetEnumerator() method.  I have found that creating custom collection classes has become an increasingly valuable method for showing intent.

Let’s take a very simple example, we want to expose a count of the orders that a customer has, and yes, I know there is a Count extension method on IEnumerable<T>, but bear with me, we’re starting simple here.  Using Jimmy’s Customer/Order example, our classes would look like this:

public class Customer
public OrderCollection Orders { get; private set; }

public class OrderCollection : IEnumerable<Order>
private IList<Order> orders;

public int Count
get { return orders.Count; }

public OrderCollection(IEnumerable<Order> orders)
this.orders = new List<Order>(orders);

public IEnumerator<Order> GetEnumerator()
return orders.GetEnumerator();

IEnumerator IEnumerable.GetEnumerator()
return GetEnumerator();

Notice that you can still use the Orders property on Customer as an IEnumerable<Order> and we’ve also added a Count property.  That was a very trivial example, so let’s look at something more interesting.

One of our requirements is to track the customer’s most recent order, so let's add this method to OrderCollection:

    public Order GetMostRecent()
return (
from o in orders
orderby o.OrderDate descending
select o

We've added a method to our collection class that clearly states its intention.  We haven’t over exposed other methods in order to achieve the requirement.  We can test this method in isolation from the Customer class and we’ve encapsulated the logic and abstracted it away from other code.

There’s all sorts of methods that we could add to OrderCollection as required in our domain.  We could add a method that returned all of the unshipped orders, or the delinquent orders.  Whatever our domain requires, we have a place in our domain where the code belongs.

Collections within the domain are often over exposed and not well encapsulated.  By creating simple custom collection classes we create intention revealing classes that don’t expose unwanted behaviour.  They make the domain more discoverable, testable and encapsulated.