26 Jun 2007
Just reading Chris Sterlings recent post titled Clean Up, Clean Up, Everybody, Do Your Share* *and the following snippet on design debt caught my eye.
Have you ever been part of a legacy project where it seemed almost impossible to add the feature asked for because you weren’t sure what will break once it is added?
A resounding yes and it’s a tricky situation to work your way out of. You’re often without any substantial unit or regression tests and are left fighting an up-hill battle on two fronts. On one hand, you’re trying to devise a design that’s going to have the least impact on pre-existing code (perhaps through a facade if you have enough knowledge about expected behaviour to be able to pull a suitable abstraction) while on the other your level of frustration has reached the point of wanting to go down the rabbit hole of gutting and re-writing (emphasis on re-writing and not refactoring) components. It’s situational about which approach is the right one to take but there’s a definite time and place for fairly serious refactorings. You can only cart around technical and design debt for so long.
This does not mean that we no longer conduct design sessions to determine a design direction for implementing a feature but these sessions should produce just sufficient enough design to get started. Also, as a team we should decide if an artifact needs to be captured from our design session.
The context for this note is around the need to hold design sessions/reviews even when working in an environment that encourages continous refactorings. On a similar vain you don’t want the very notion of a design session or review to forbid or discourage refactorings during the course of an implementation. I strongly agree that design sessions are means to influence a direction, not dictate one. If as an implementor you come across a snag in your initial design, please don’t leave it and use the excuse of ‘oh it was in the original design and it was approved‘ when someone calls you on it. That excuse worked in University but certainly doesn’t fly in any environment I’ve seen.
Chris talks in more detail about various forms of accumlated debt and some strategies for dealing with it in agile environments, I just picked out the pieces that particularly struck home.
So, there you have it. Dealing with legacy components is often difficult but necessary, design at an appropriate level of abstraction to influence (and not dictate) direction and lastly… don’t make excuses 
25 Jun 2007
Last Friday, GenoLogics hosted their third hack day (and 2nd of the year). As Cliff mentions on his blog, we had a few visitors. It’s far from the extravagant events that Yahoo! and Google have been putting on as of late, but the concept remains rare enough to warrant attention from local (and national) media.
Nothing too fancy as far as rules go. Everyone’s encouraged to start thinking of a suitable hack a couple weeks prior to the actual event. That being said, it’s always been a scramble in the morning as people try and figure out exactly what it is they want to hack.
What started out as a dev-focused event has begun to branch out into other groups in the company. This time around we had participants from our Customer Service group. Looking forward to seeing what the Marketing and Product Management can produce next time around.
As for the hacks themselves, we had anything from Lego mindstorms to a mashup between Remember the Milk and various bittorrent networks. My contribution involved writing a synchronizer for iPod <-> iTunes. It was fallout from some prior aggravations I was having with iTunes not correctly synchronizing my ‘Play Counts’ (and related information) when I was manually managing music. It was rather annoying (to me at least) to try and build playlists based on a play count in iTunes that didn’t accurately reflect what was on the iPod.
Further to the basic synchronization (that was accomplished using Python, it’s Win32 bindings, and the iTunes SDK), I also wrote various utilities to backup and extract song information from the iPod. This information was then parsed and used to generate an RSS feed and various graphics (PyRSS2Gen and PyChart respectively). It was all tied together in a TurboGears app w/ jQuery and the rather nice Interface elements.
Python isn’t a language I have the opportunity to use on a regular basis but I was actually quite happy with how my particular hack came out. Python’s ability to interact w/ win32 COM objects was both impressive and straight forward. Certainly easier than trying to do it with JNI.
Interested in participating in our next hack day? We’re hiring (leave a comment).
19 Jun 2007
The Harvard University Gazette has posted a transcript of BillG’s commencement speech.
It carries an important and motivating message with some self-deprecating humour thrown in for good measure (see below :)).
Imagine, just for the sake of discussion, that you had a few hours a week and a few dollars a month to donate to a cause – and you wanted to spend that time and money where it would have the greatest impact in saving and improving lives. Where would you spend it?
This message particularly rings home. I was involved with the 2nd annual Canary (Soap Box) Derby held this past weekend in Victoria, BC. It was held in support of the Canary Foundation, who shares a vision of **A world of simple blood tests which identify and isolate cancer at its earliest most curable stage. It’s amazing what communities of like minded people can accomplish when adequately motivated to work towards a common cause (in this case, raising $100k+ and purchasing a piece of equipment for the BC Cancer Agency).
Obviously discovering a cure for cancer is society’s ultimate BHAG, but there’s something about a simple blood test that makes it both an attainable and stretch goal. Attainable in the sense that a blood test to many is just a fact of life, yet we haven’t (yet) discovered or validated any appropriate markers in our blood that are positively indicative of cancer). It’s important that there’s an ability to track progress towards a goal to help keep everyone involved (particularly the commercial entities) motivated.
…
Radcliffe was a great place to live. There were more women up there, and most of the guys were science-math types. That combination offered me the best odds, if you know what I mean. This is where I learned the sad lesson that improving your odds doesn’t guarantee success. – Bill Gates