January 31, 2005
Mixed Feelings Over Firefox
Let me just begin by stating that I use Firefox as my principal browser on each machine (iMac, Laptop/Windows XP, PC/Fedora Core 2) in my home network and think it's a fabulous piece of software and demonstrably better quality than the "market leading" browser. That's my personal option/preference.
My professional preference is somewhat different - for different reasons...
As a software developer who tends to end up writing/maintaining large-scale Web-based Internet/Intranet applications, I quite like the browser monopoly currently held by Micro$oft. Why? Because with every new browser on the market, the testing of such applications becomes correspondingly more difficult.
Yes, it is possible to minimize the amount of client-side code these applications contain, but I've yet to meet an environment when such code has been completely eradicated and, until that time, multiple browsers in the audience means more complicated testing.
Thankfully, things have improved from my first internet application involving large applets which caused no end of pain from a testing perspective, but unless I can fast forward time to when Firefox has 90+% of the browser market, I'm happier developing to a (more-or-less) single browser, thank you very much.
From 2 Wheels To 4
Those close to me will know that impending fatherhood has forced my hand and caused me to pursue (for the fourth time) my car drivers' licence, thus considerably reducing the high moral ground I reside on as a purist pedestrian and cyclist (both motor- and bi-). To paraphrase Kevin Costner (gulp!) from The Untouchables, "I have become what I beheld and I am content that I have done right!"
The transition has been an interesting one and not without it's moments of increased blood pressure on both my part and my long suffering girlfriend and passenger. I had in mind a number of things which concerned me when planning my move from controlling a high power sports motorbike to a relatively low-powered SUV - some of which were legitimate concerns, some of which were not:
- I was pretty sure braking would be an issue. I was used to my bike's rapid braking and was pretty sure the car would prove an innertial slug by comparison.
- Sheer vehicular dimensions were my other major concern. On my bike, I look straight down both sides of my vehicle, thereby enabling fairly precise manoeuvering between objects. Conversely, in a car I figured I'd need to "project" my mind 5 feet to the left to work out exactly what the left side of the car would hit/miss on it's current trajectory.
In the end, the former has been far more of a nuisance than the latter. The car takes an eternity to accelerate and even longer to brake. No sign of the engine braking I so love on the VTR, which will pull me up without the need for brakes on most occasions. The direct effect of this difference has been a few extreme braking occasions, although I'm getting a much better feeling for the car now.
Even more of an issue has been the lack of acceleration. I'd been taking for granted how much of a safety feature a powerful, torquey engine can be when changing lanes - a flick of the right wrist was always enough to quickly get me out of the way of any impending danger. Now car bound, I've got to plan these things so much further in advance and have been stranded stationary behind blockages in the road because of my lack of confidence in the car being able to react quickly enough in time.
The only other major issue I've had so far has been the very strange sense of disconnection you get in a car compared to a bike. Apart from the caged nature of driving in general, I've found the level of abstraction the steering wheel puts between it and the turning of the wheels to be somewhat perplexing. I'm used to handlebars directly connected to the wheel and a 1-to-1 correlation between the turning of one and the other. Now I'm having to mentally map n amount of steering wheel turn to m amount of wheel turn. Ironically, I tend to oversteer rather than understeer and still have a bit of work to do in that direction.
Apart from that, it's been quite fun seeing how the other half lives and very interesting charting the progress of my newly-found skills. The 10+ years of road experience on the bike has certainly put me in a better position confidence wise that the last time I attempted to join the rest of the 4-wheeled world, so fingers crossed it will be 4th time lucky!
January 28, 2005
Closing the feedback loop
I'm soon to be rolling off my current project and, as tradition demands, have been lumped with the "shitty work" of bugfixing for the next month or so . That's right - no shiny new stories for me to work on, just "go into the corner and don't come out again until you've fixed all those bugs!". And guess what? I'm loving every second of it!
The reason for this strange attraction is the feedback loop we have with bug-fixing which isn't in place or our normal iteration work...
Up until now only the development team has really had the final say on whether a story card was finished or not within the iteration. Effectively, we'd come to the end of what we think the work entailed and it'd would be subsequently ticked as complete. This is all most irregular I know and decidedly un-Agile, but until recently I'd forgotten one of the major positive side-effects you get from external sign-off of stories.
I'd been thinking that the sole reason for having such a tight feedback loop for story sign-off is to ensure the highest quality code is released at the end of each iteration. This is a valid point, and we do have a uncomfortably large number of bugs raised against our stories once the testing team gets to looking at our "completed" stories, usually well after the iteration has closed.
However, there's another key benefit to this approach... it provides great closure as well. There is nothing better for a developer's morale than for a third-party (i.e., customer, customer-proxy or tester) to say "Yes. That's exactly what I was looking for!" And that's what I'm getting several times a day (usually) when the testing team looks at each bug I've resolved and passed onto them for review. It's a small difference but the end result is infinitely more satisfying.
Now, we just need to get the same immediate, objective feedback in place for our main story card development.
January 12, 2005
Death March to Mordor
I've been fascinated by the mechanics of film-making and been eagerly pouring over the box set of extended editions of the LOTR trilogy that Santa gratefully rewarded me with last Christmas. Coupled with this fascination is a growing theory about the level of similarity between film-making and large-scale software development projects. One day, I'll be sure to post an insightful and thought-provoking treatise on the similarities. Today is, unfortunately for you dear reader, not that day.
Today I want to highlight an interesting observation/admission that surprisingly (to me) crept into one of the last making-of specials on the last DVD for the ROTK. The special itself was detailing the post-production work done prior to release of the third film. The amount of work required of Weta (the digital FX workshop), the music and audio departments and the editing team to satisfy Peter Jackson was astonishing and it's truly a credit to them all that everything was completed just three days before the world premiere in Wellington.
However, what became abundantly clear to me was that the ROTK post-production phase was a fairly classic "death march", as detailed in the text by Ed Yourdon. Way too much work was required by way too few people in way too little time. People lived at their desks, slept in the office, and generally worked outrageous hours for prolonged periods. The key statistic that sticks in my mind is that Weta produced the same number of shots in the 5 weeks prior to release as they had in the entire first film.
Eventually, everything did get done and the film itself was IMHO a staggering success. So, again in my opinion, ROTK delivered on the requirements of the customer. Additionally, it was delivered on schedule, although only by the hair of it's chinny, chin, orc-y chin. I have no idea on whether it exceeded it's original production budget, but I'm fairly certain that it's earnings to-date have exceeded whatever it cost to make the film. In summary, the project ROTK is a success on pretty much every axis such things are judged in the IT world.
But amongst all the self indulgent back patting that consumed this special was a short comment from one of the main people in the post-production team mentioning the human cost of the post-production effort. Although there were no numbers at hand, this person made a statement about the "poor record" the film had in terms of the number of divorces and broken relationships resulting from the efforts required across the entire series. At last, some indication of the inevitable downside of putting your life on hold to follow the vision of an inspirational and charismatic leader!
Like many developers, I've been involved on a DM or two. The most extreme of these is something I look back on fondly now, mainly because of the enormous feeling of camaraderie within the team and the thought that what we were doing would really be a revolutionary step forward (it wasn't). At that time of my life, I wasn't harming anyone apart from myself with the amount of work I did. These days, a little older, a little wiser and with a lot more personal commitments, I wouldn't go near one of those things with a bargepole. It would be fascinating viewing to see whether any of those who suffered the consequences of such enormous personal sacrifices still spoke so glowingly of the process in light of everything.
Kudos to the LOTR DVD editors for including this little gem of harsh reality.
January 07, 2005
Crossover Office: 100% pure Windows
I'd been struggling with my own imcompetence for... well, pretty much my entire life, but it'd been more of a burden recently - but I digress.
I'd been struggling with my own imcompetence recently as I'd been strangely unable to reconfigure my much beloved Lotus Notes installation on the Windows partition of my laptop, after having used it quite successfully for several months through Crossover Office (a commercial port of Wine) on the Linux partition of the same laptop.
The reasons why I wanted to revert were twofold:
- To obtain whatever slight performance gain I might eke out of running natively (and if you don't believe an email client needs to be performant, I invite you to step into my Notes-using shoes for a couple of days)
- To restore the cultural diversity to my home office, which consists of the laptop, my G4 iMac and an AMD-64 PC running Fedora Core 3.
So after fruitlessly comparing the working and busted configurations between my Windows and Linux installs, I made one heavy-handed last attempt by copying the entire Lotus program directory from the Crossover Office/Wine installation across to my Windows partition and... Voila! No further changes needed, no configuration outside this directory structure (including no registry entries, thank God!).
Perhaps this is the first documented case of "configuration stupidity is the mother of invention"?
January 06, 2005
Little known to many, I was lined up for a journalistic vocation prior to my discovery of the wonders of the Microbee PC in 1985. As such, I still have quite a love for the carefully crafted word and admit to being hugely derivative when it comes time for yours truly to put quill to parchement.
And although I do consider myself to be a writer of reasonable skill, there are often times where I gaze in awe at the chasm that separates casual writing shmoes like myself and those who are employed to churn out copy under heavy deadlines day in, day out. However, rarely is this gap spanned so succintly than in this one-liner from an article raving about a recent performance of a member of the Australian cricket team. The author is Peter Roebuck, one of my favourite sports' scribes from the daily broadsheet paper of my previous home town. The meaning will be lost if you don't understand cricket:
"... he spent less time in the 80s than folk rock".
The full article can be found here.
January 03, 2005
Review: Pragmatic Unit Testing
Having previously read the original title in the Pragmatic Programmer series, I eagerly delved into this more recent addition. However, I have to admit being somewhat disappointed and at the same time, wishing I'd read the text 2-3 years ago.
My main gripe with the book is that it didn't give me any of the "but of course!" moments that I was constantly encountering when reading the original Pragmatic Programmer book. After finishing the first book, I felt that Andy and Dave had melted away the myth and legend around being a top software developer and laid it bare in far simpler terms. None of this sense of alchemy struck me having read Pragmatic Unit Testing.
Having said that, I couldn't think of a better introductory text for someone first wanting/needing to gain some knowledge about the art of writing effective unit tests. Covered from a Java development perspective (although a C# version of the text is available for "the other team" :-)), the text provides a very solid introduction into the use of JUnit as a unit testing framework.
My favourite Java unit testing text is JUnit in Action by Vincent Massel, and whilst Pragmatic Unit Testing does not cover anywhere near as much techical depth as the former (especially in the area of JUnit derivatives such as HttpUnit and Cactus), it does include more of the theory behind building a quality test suite and what properties such a beast should exhibit. This emphasis is what makes the book such a good choice for someone who has not done much/any unit testing before. For a more experienced testing, JUnit In Action will be a far more satisfying and valuable read.
Like all the books in this series, it is commendably short and succint, the language is informal and the sequencing of chapters logical and well thought out. And for a novice unit testingg developer, the minimal investment in time and money will pay handsomely in a very short period of time... after which a more exhaustive reference guide might be appropriate.