thoughts

I is for Interface

Back in 1995 I sat in a large ballroom to listen to politicians from the North and South of Ireland talk about the peace process, which at that time was far from a sure thing. A story, told by one of the Unionists stuck in my head. He told of how he had been involved in selling a ceasefire to loyalist paramilitaries and one of the questions that he was faced with was.

Continue reading

The Pilot and the Project Manager

To land a plane you need to line up with the runway, figure out the right rate of descent and airspeed, then monitor and manage those, all the way down to the ground. Your goal is to touch down on the runway, rather than before or after it, while travelling fast enough that the plane doesn’t stall and fall out of the sky, but slow enough that the wheels stay attached when they hit the ground, and you can stop within the amount of runway you have at your disposal.

Continue reading

Are Unit Tests the new Comments?

It’s verging on heresy to even talk of Unit Tests and Comments as being in any way related. They serve different purposes, work in different ways, and have nothing in common. Except Comments Document Interfaces, API’s etc. Can drive development by writing pseudo code comments first. Mark outstanding work using TODO comments. Explain particularly complicated pieces of code. Context to help future developers avoid breaking the code. Document expectations, side-effects etc.

Continue reading

You're Not Gonna Fix It

I’m not going to justify kludges, or apologise for kludges. I don’t need help figuring out how to avoid them. Kludges don’t usually come about because we don’t know how to avoid them. They usually exist because we make a judgement call. We decide that a kludge is not worth avoiding. Dress it up any way you like, but it comes down to a decision. This post starts from the premise that in all liklihood there will always be kludges.

Continue reading

Retrofitting Tests To Legacy Code

One problem with TDD is that those who try it, often begin by writing a few trivial tests to get the lie of the land. Then instead of using TDD to write new code they do something much much harder. They do what I did, they start out by trying to write some unit tests for existing code. Either a past project, or more likely the project they are currently working on.

Continue reading