Technical Debt isn’t Like Borrowing From The Bank

I had an issue with a legacy component today.  It’s pretty much a poster child for technical debt, ill-understood, no documented procedures, precious little logging and everyone avoids touching it in case it breaks.  It’s also using an outdated architecture and the code is frankly bad.  In fact, the debt’s so bad… I’ve been putting off paying it off.  For the most part it doesn’t bother me and the inconveniences are mild.

raining_stones

The inconvenience today wasn’t.  Actually, I got really lucky.  Some messing around with IP addresses fixed it.  But I don’t know why it broke, and that bothers me, because next time I won’t be as lucky.

Borrowing from the bank is a relatively safe occupation.  You agree a sum, they check you can repay, you agree an interest rate and you agree a schedule of repayments.  You keep up the payments and eventually, the debt is paid off.

Technical debt isn’t like borrowing from the bank.  It’s like going to a loan shark.  You can borrow any amount, irrespective of your ability to repay.  The interest rate is high, and subject to change.  You don’t even need to pay it off all of the time.  In fact, it’s all smiles until the he comes round to break your legs.

If you’re lucky, you’ll get some warning.  If you’re not, the first thing you know is when someone’s banging on your door telling you it’s time to pay up.  And you’d better pay up there and then because the consequences of not doing so are pretty severe.  And that’s the really pernicious thing.  Technical debt often feels like a small problem, but it mounts up all of the time.  You can put off repaying it most of the time, so it doesn’t feel that big.  Until one day a something breaks and there’s no sensible way of fixing it.  So pay it off before the payment becomes due.

Technorati Tags:

The Composite Pattern Revisited

I’ll have to hold my hands up here.  My original remarks on the composite pattern was pretty much 100% wrong.  In fairness to myself, I’m not the only one to have dismissed it as being tricky and slightly special case.  (As an aside, I really don’t think Command is a starter pattern.  To be honest, I’m still not convinced I’m doing it right.)  Like the visitor pattern, we tend to associate it with dealing with trees* and such relatively obscure topics as semantic evaluation.

Actually, it’s closest to the adapter pattern.  But while the adapter pattern is about jamming a square peg into a round hole, the composite pattern is about slipping two round pegs into the same round hole.  Of course, the physical realization of this would be impossible, but code’s a lot more flexible than IKEA furniture.

So, how do we achieve this?  Well, imagine a simple interface like this

public interface ILogger {
    void WriteLine(string line);
}

and two implementations

public class ConsoleLogger : ILogger {
    public void WriteLine(string line) {
        Console.WriteLine(line);
    }
}

// Yeah, the implementation of FileLogger is awful
// you don't need to tell me
public class FileLogger : ILogger {
    string fileName;

    public FileLogger(string fileName) {
        this.fileName = fileName;
    }

    public void WriteLine(string line) {
        using (var writer = new StreamWriter(fileName, true)) {
            writer.WriteLine(line);
            writer.Flush();
        }
    }
}

So, imagine we now want to write to the console and to the file.  Or to two different files.  Do we need to write a new logger each of these cases?  No, we just need the one, the Composite logger.

public class CompositeLogger : ILogger {
    IEnumerable<ILogger> underlying;

    public CompositeLogger(IEnumerable<ILogger> underlying) {
        this.underlying = underlying;
    }

    public void WriteLine(string line) {
        foreach (var logger in underlying) {
            logger.WriteLine(line);
        }
    }
}

This class gives us all the aggregation we need and allows us to easily implement the single responsibility principle.  A class taking one logger can now write to two loggers without changing the code.  Incidentally, if you look at the Solution Transform source code, you’ll see that I have two composite classes that work exactly as defined above. 

Aggregation of Results

That’s the basic idea.  However, my example rather deliberately skirted an important detail: what happens if your interface returns values?**  The answer is, it depends.  We’re starting to move away from the classical definition Let’s take an example from the dotcom world.  Imagine that you were running a shopfront application.  You’ve got several suppliers with price providers.  But you only want the one price.  Well, the sensible thing to do would be to quote the lowest price.  So, on top of IPriceProvider you could have MinimumPriceProvider as a composite implementation. In fact, most aggregate functions could be used in various contexts:

  • Minimum
  • Maximum
  • Sum
  • Product
  • First (or First not null)
  • And (True if all of the underlying implementations return true)***
  • Or (True if one of the underlying implementations return true)

The price example is oversimplified, however.  Usually, you don’t only want to know the lowest price, you want to know who is quoting the lowest price.  The composite pattern doesn’t really apply here.  Actually, we’re probably talking about chain of responsibility again.  Composite objects are dumb.  If you’re talking logic and decision making, composite isn’t the right design.

Composites in Use

There’s a couple of composite implementations that you never even think about.  Any logging system is an obvious example, but MulticastDelegates are composites as well: they expose the method signature and call multiple implementations when invoked.  It’s also a fundamental building block of any publish and subscribe system.  Jeremy Miller’s got a list of common composites but, inevitably, most of them are tree structures.  Obviously, you start putting composites in other composites and you get a tree structure, but there are plenty of flatter problems that find composites useful.

So, when should you use it?  Basically. anytime you process list of objects, revisit whether your code would be simpler if you just dealt with one object, and used a composite to for aggregation/distribution duties.

*Please bear in mind that I’m referring to that JavaWorld article as an example of someone making a mistake.  I don’t really want to dissect exactly what’s wrong with the rest of the article, but I’m not recommending it.

**In fact, I don’t think you can return values according to the classical definition.  It’s hard to find an example on the internet that does.  I’m sure someone with a copy of Gamma et al handy will correct me.

***Take a look at the Rhino Mocks constraints code for a good example of this.

Technorati Tags: ,

CSS Keeps Getting Better

I’ve knocked together a quick demonstration of what CSS can do these days.  Take a look (I’ll wait).

Ultimately, this is how this sort of styling should be done on the web. Importantly, I’m not a web designer and I haven’t used any “tricks” to deliver this. This is all hand-coded from easy to read articles on the web.  You can do this yourself without very much work; cutting and pasting the code on this page would be a good start.

The weakness is the anti-aliasing (Firefox does this slightly better than Chrome). If you had a single colour background and no transparency, you could fix that with the excellent cornerz plug-in. I’m not sure what other approaches you could do here. There’s a Javascript PNG generator that could be used to create corner images, but it would be very hard to be compatible with both the gradient and the background image. There’s also some nasty issues with the compatibility of background images and background effects: sometimes the wrong one shows on top. Finally, the opacity isn’t all it could be: there’s no easy way of getting the text fully opaque and getting the gradient bleed through at the same time.

As with most things CSS, it’s all a bit more complex than you think it should be. But it does work. Here’s hoping browsers improve their anti-aliasing and render the rest of this discussion moot.

Technorati Tags: ,,,,,

Notes on dotLess

I’ve been working on a restructuring of this blog and decided it was about time I entered the modern age.  I’ve always pretty much developed CSS by hand in Notepad.  This is, to say the least, a frustrating and time-consuming experience.  Now I’d heard of dotLess from Daniel Hölbling’s blog and thought it was time to give it a go.  (As an aside, I know that dotLess is a ruby port.  Many of these issues may well also apply to the original codebase.)

In summary, dotLess is good and I’m enjoying using it, but it could be great.  Let’s start with usability.  If you fail to terminate a variable, it doesn’t tell you.  It simply keeps going until it finds an appropriate termination.  No warning that you’re generating a variable name with >8000 characters and multiple newlines in its name or value.  It has issues with unterminated CSS directives as well.

Then there’s what happens if you refer to a mixin or variable with the wrong name.  It crashes, which isn’t too bad.  However, it doesn’t tell you what name it couldn’t find or where in the file it was processing when it failed.  Again, this just makes more work for the user, and wouldn’t be very hard to fix.  It’s also a pity the –watch command line parameter wasn’t working in the version I downloaded.

Current Selectors Nested Rules

I’ll admit, I wish I’d thought of the whole nested rules concept.  It’s simple, it’s powerful and it encourages good CSS design.  However, I can’t help feeling the whole thing could be even more powerful.

In particular, nested rules currently only handle elements within the declaring element.  Wouldn’t it be great if we could say the following easily?

  • The text for this element is red, including any links in the text.
  • The left margin on a UL is 0px, except in IE7 where it needs to be 8px.
  • The post’s heading should be red, unless it’s within a digest where it should be blue.

Basically, if we could have a syntax for “current selector”, we’d be able to do really cool things and make the dotLess files even smaller and more readable.  Here’s a proposal: have ampersand (“&”) represent the current selector in a nested rule.  You can keep the existing syntax as well: there’s no conflict between the two.  But now you can say things like this:

.redText { 
    &, & a, & a:hover { color : red; }
}

UL {
    margin-left : 0px;
    *:first-child+html & { margin-left : 8px }
}

.post h1 {
    color : red;
    .digest & { color : blue; }
}

This isn’t my idea, it’s already fully implemented in sass and less.js.  It’s an awful lot simpler than turning dotLess into progamming language, and solves most of the problems that people trying to solve by introducing programming language features.  This is part of a much longer rant: JavaScript already exists, Modernizr already exists.  dotLess is a useful tool, but duplicating functionality is going to be a waste of time.

CSS3 Problems

Using modern features and, in particular, unadopted features causes a few problems.  There’s two main issues here: if you define multiple values for a property, it just uses the last one.*  This is fine, except that web designers sometimes do this in the knowledge that different browsers will read different lines.

For instance,

h1 {
    background: -moz-linear-gradient(top, @primary, @primaryDark);
    background: -webkit-gradient(linear, left top, left bottom, from(@primary), to(@primaryDark));
}

Will generate a file containing only the webkit specific instruction.  Historically, that hasn’t been such an issue, but it’s becoming one at the moment.  Also, there’s another reason this code doesn’t work: dotLess variables don’t like being in a larger CSS expression, so in practice this code doesn’t even work for webkit browsers.

Use it

All in all, I’m going to continue to use it.  The operations stuff is incredible: I can actually do things like say “It needs to be the colour which at 80% opacity will merge with the background to make navy blue.”  Expressing stuff like the holy grail layout is relatively easy as well (never thought I’d say that, it’s normally a complete pain). 

*All of this was from the 1.0 beta download in January.  I’m not the first to spot this issue and for all I know it’s already fixed in source.

Technorati Tags: ,