« Archives in September, 2008

Notes on Working effectively with legacy code, by Michael Feathers

Most of the projects that I’ve been paid for thus far have involved working with a substantial amount of what I would gently term “other people’s code”. I’ve also jumped into these projects at a stage where those involved have started to use the terms “technical debt”, “refactoring”, and even “re-engineering” with increasing frequency.

It’s challenging to work with code that has a history, but I find it to be a lot of fun. (From a 30000 foot view, that is — at any given time when I’m in the thick of it, you will hear me cursing under my breath just like anyone else would be.) I’ve developed my own little arsenal of techniques that I use to get things done in such an environment. (The most useful one is to always remind myself that this is software that has been _successful_, and that it has intrinsic worth, even if I am working in a particularly hacky corner of it.)

Anyhow, a few months ago it occurred to me that it would be great to have a book about this sort of thing; about the mindset you should be in when working with old code, the techniques you can use to mitigate the complexity, etc. It didn’t take much poking around to discover Michael Feathers’ book, and I’m glad I did. This is, in my opinion, one of those books that anyone in a software-related field should read.

While I picked up quite a few little tips from Feathers’ book, there were three major contributions that I considered to be the main ones:

  1. The definition of ‘legacy code’ as ‘code that is not under test’. By casting the problem of maintaining an older system in this light, Feathers moves the problem from the realm of genericity (our code is hard to work with and we need to do something) to the realm of specificity (our code is hard to work with, so we need to find ways to get it under test.) This gives you a specific problem to attack.
  2. The identification of the “seam” as the primary concern in a legacy system. A seam is defined as any point in the system where one component may be stubbed out or otherwise decoupled so that you can test an interacting component in isolation. This focus on seams essentially turns your “testing quest” into one of decoupling components from one another, which is (in the opinions of many people much smarter than I) perhaps the most critical precondition for keeping a system maintainable.
  3. The simple fact that Feathers has obviously been in the trenches himself many times, and that he speaks of the experience not with despair, but with acceptance and even mild amusement. While many software engineers I know would bemoan the idea that the status quo of system development should be a gradual decay towards unmaintainability, it’s pretty obvious that it happens and that this is a thing that all of us will one day have to deal with, as inevitably as death, taxes, and all that sort of thing. Having a respected individual in the field talk about it so frankly is, well, downright comforting, and I find it helpful to recall that I am not alone when stuck trying to disentangle some particularly heinous code-rot.

I could go on, but there’s little need. In summary: I strongly recommend Working Effectively with Legacy Code. This is the sort of book that I intend to read not just once, but once every couple of years or so to keep the lessons fresh in my mind.

Velocity diet, day 2

Note to self: When doing the v-diet, do not rely on a protein blend that uses aspartame as a sweetener. Ugh…

I woulda splurged on the Metabolic Drive but it takes a while to ship to Canada and this was a last-minute decision. Oh wells.

Courting the Dark Horse at dawn

This morning on my walk to work, I stopped in at the Dark Horse espresso bar on Queen east. Von, the owner of Bisogno, actually encouraged me to try them out.

The place is pretty cool lookin, but Bisogno has cooler books. Also, the people behind the counter weren’t the friendliest, but it was just a little after 7am and I can’t imagine that I was all that cordial myself. Nor was I very coherent — after I ordered my single espresso, I ran to the washroom and then remembered that I had to keep walking. So, I came out and asked if I could have my order to go. I mean, what a stupid thing to say — you can snort an espresso through your nose in 5 seconds if you need to. So, I am going to reserve judgment on staff friendliness until I get a sample encounter when I am not obviously being a dumbass.

Anyhow, the coffee itself was freaking awesome, pretty much on par with any of the blends I’ve had at Bisogno. I still like Bisogno better, though. I mean, Von has Gödel, Escher, Bach and a history of the Medici family in his bookshelf. It’s hard to beat that.

Give it shot yourself (pun intended):

On BlogTO
Stopfinder map

Redux on cycling in Toronto

I don’t consider myself to be much of a cyclist. However, I do tend to use my bicycle as my primary means of locomotion, and I’ve done so in Vancouver, the Bay Area, and now in Toronto (and the suburbs thereof), so I guess I have a smidge more experience than most.

My initial observations about being a cyclist in downtown Toronto, in comparison to other places? In Vancouver and the Bay Area, the infrastructure for cyclists was pretty good. It was the drivers you had to look out for. (This may have been my inexperience as well, but I don’t think it was entirely so.) Vancouver, in particular, was somewhat harrowing: I was hit from behind by a car while I was _stopped_ at a red light. The driver subsequently drove off while I screamed at him through a red haze and hurled rocks at his rear windshield. It was pretty awesome.

In Toronto, I personally have found the drivers to be good about cyclists. Sure, you get your occasional road-rager, and the cabbies treat you no differently than a similar volume of air, but by-and-large folks are pretty respectful. Even the infrastructure is decent — there are lots of side streets for you to take, and bike parking is especially easy to find. The city supplied bike-parking poles that you find everywhere are far superior to your average bike rack.

The hard part about cycling in Toronto, in my opinion, is the quality of the streets themselves. Many of them are cracked, completely uneven, sometimes even unfinished (the other day I almost hit a partially-removed island coming over the Bloor viaduct) and frequently contain “potholes” with diameters and depths that must be measured in feet and fathoms, not inches.

Then there are the streetcar rails. I find these to be a huge pain, although I’m getting better at it. Still, whenever I go over a rail cloverleaf on my roadie, I can feel my brain trying to unravel the seemingly Moebian geometry of the whole mess as I clip over it at a cautious 10kph. Even if you don’t get your front tire caught, the rails are quite slippery in wet weather.

Cyclists themselves seem to be a bit more clueless in this city, as well. I frequently find people riding _against_ traffic (even in the bike lane), which invariably triggers my filthy-pirate-mouth reflex. And I see many folks with iPods stuck in their heads while they pedal along, especially if they’re cycling on the sidewalk (*veinpop*). And what’s with all the bell dinging? Whenever I’ve cycled in other places, if a cyclist was going to pass you, she’d just call out something like “on your left”. If I hear a bell ding, how am I supposed to distinguish if it’s a bicycle, a streetcar, or some kid with a new toy that miraculously does not require batteries?

Rereading that, it only seems to _border_ on ranting, so I’ll leave it as-is. However, I think this is a good place to stop. The gist of what I’m trying to say is that, despite my rash of negativity there at the end, I don’t think Toronto is really as bad of a city for cyclists as I’ve heard many people claim. I’m pretty happy with it so far! Smoother roads, railless streetcars, and smarter cyclists would make me happier, and I think that at least some of these things are being worked on already (check out Metronauts), which is cool by me.

Notes on Ground Works: Avante-garde for thee (a collection)

Ground Works tricked me. I thought it was going to be an anthology of short stories written in post-modern style by the authors that really originated the movement in Canada. It’s close to that, but instead each work is actually an excerpt from a larger one. In pretty much every case, the “story” is a single chapter or subsection of a novel.

At first I thought that the distinction would be minor, but it was not. For one thing, most of the pieces that I read in this collection still felt self-contained, which led me to wonder why I would subject myself to reading the complete work in the first place. (I say “subject” because a lot of these pieces are challenging to read, to say the least.) At the same time, many of the pieces were also quite diffuse, probably because of a combination of the style and the fact that they were parts of larger works, and so lacked the intensity of a short story.

I have discovered that reading a sampler-pack of book chapters gives you sort of the same feeling as eating a sampler-pack of snacks: I ultimately ended up feeling unsatisfied, but was pleased to try a bunch of new things and came out of the experience with a short list of items I’d like to explore with more depth.

Other good things about reading Ground Works? Of the stories presented, Remote Control and some other work about a mother who takes her child along with her when she shoplifts were pretty awesome. I was compelled to research what “post-modernism” actually is, albeit shallowly (read: I visited the wikipedia page. It didn’t help much. Neither did comparing it to “modernism”. I need to do some real book-work to appreciate this, I think.) I learned what a “panopticon” is. I discovered that I’m not very much interested in writing that focuses on the act of writing itself. (Metawriting?) And finally, I very much enjoyed the biographies presented on each author, especially the discussions of the historical and regional contexts in which they were operating.