Existing by coincidence, programming deliberately

An integrated pomodoro timer for Visual Studio

2010-11-30T13:52:00.004Z

As part of my ongoing fight against procrastination, I recently started using the Pomodoro Technique to help me focus on the job at hand.

For anyone unfamiliar with it, the Pomodoro Technique is a time management practice invented by Francesco Cirillo while he was a student in the late 1980s. It works by dividing a day into a series of focused 25-minute slices, called pomodoros, broken up by short breaks away from work.

The beginning of the day is given over to planning which tasks are to be accomplished, resulting in a prioritised list. Then, pomodoros are used to progress through the list of tasks in order, working as many pomodoros as necessary to complete each task. When a pomodoro finishes, a mark is placed next to the relevant item from the list, so that the time spent on each task can easily be tracked.

Pomodoros are indivisible, so interruptions are not allowed. If an interruption does occur, that pomodoro is declared void and the timer is reset. Equally, completing a task 'early' results in the remaining time being spent on overlearning; either reviewing, repeating or improving whatever has just been done.

One of the requirements of the technique is that the timer is always visible. Because most of my work occurs in Microsoft Visual Studio, I thought it would be useful to have an integrated pomodoro timer that runs in a docked Visual Studio tool window. As well as making it easy to glance at while coding, such a timer would also enable a visual alarm to be used, thus sparing the concentration of co-workers who might not appreciate a bell or buzzer sounding off every 25 minutes or so.

To that end, I've built VSPomodoro, an integrated pomodoro timer for Visual Studio. It is a very basic little add-in, but I've pushed it up to GitHub in case anyone else is interested. I've also made an installer available for those people that are interested in using it without looking at the code.

An intuitive, editable .NET ListBox control

2010-07-13T11:08:00.009+01:00

For a recent C# side-project, I found myself wanting to use an editable ListBox control, with intuitive keyboard shortcuts for rapid data-entry. The model I had in mind was similar in appearance to the VC++ Directories pane in Visual Studio's Options dialog, adding support for Tab and Shift+Tab navigation between items in the list. Trawling round the web, I found plenty of candidates for re-use, but none of them really had the look and feel I was after. So I took the opportunity to educate myself about .NET User Controls and started work on a new side-side-project.

As it turns out, implementing a basic User Control is pleasingly simple. Visual Studio has a wizard that generates the boilerplate code and from there it is straightforward to use the design view to position any constituent parts in much the same way as you would for a Windows Form. In the case of my EditableListBox, those components were a normal ListBox, a TextBox to act as the edit field and some Button instances to enable user-invoked sorting, ordering, addition and removal of items. I took the icons for the buttons from Everaldo Coelho's Crystal icons project.

The next step was to add appropriate keyboard event handlers so that the control presented the smooth data-entry experience that I envisaged. I opted to display the edit field in place over an item when that item is double-clicked, or when Enter or Space are pressed and the item is selected. Tab and Shift+Tab can then be used to navigate through the listed items, confirming any changes that are made, whereas the up and down cursor keys perform similarly, but will discard changes. The editing mode can be left by pressing Enter, to confirm changes, or Escape, which discards changes.

Event handlers were also added for each of the buttons, so that the control could be operated with the mouse as it could with the keyboard. The most noteworthy of these was the sort button, which actually led to two different sorting algorithms being implemented. When the button is pressed, a quicksort is used to order the items with typical O (n log n) performance. However, when a new item is added to an already sorted list, it is only necessary to bubble that item up or down to its correct position.

With the event handlers in place, all that remained was to expose a set of public properties from the control, so that end-users could customise its appearance and behaviour to match their requirements.

For anyone interested in looking at or re-using the source code, I've pushed the source up to GitHub under an MIT license. I've also uploaded a built DLL containing the control, for anyone that simply wants to re-use it in their own project verbatim.

An anti-pattern rant

2010-02-24T12:39:00.004Z

This post is not about anti-patterns, rather it is itself anti-pattern. I am railing against the ubiquity of patterns because I believe that, in many cases, their fundamental message has become lost in the midst of an unthinking, cultish devotion to the "patternal" (to coin a phrase) doctrine.

First, a couple of anecdotal items to illustrate where I'm coming from.

ITEM: Recently, I attended a job interview. During the interview, I was asked about design patterns and the GoF book. Yet at no point was I asked about the wider topic of object-oriented design in general.
ITEM: In a previous job, I worked under a technical lead who consistently exhorted his minions to consult the GoF for every design decision under the sun. Not once was discussion initiated from a standpoint of the principles of good design.

Okay, so this is nothing like a statistically significant sample of the programming universe, I know. But equally, conversations with my peers suggest that these are not uncommon phenomena.

So what is the problem, exactly? The problem, as I see it, is akin to one of stalled shu-ha-ri. The GoF book has been very successful at encouraging developers to consider the implications of their design choices. It contains concrete implementation details, which make it easy for developers to apply each pattern. But that very ease of application has also, I suspect, stymied deeper thought for many developers about the underlying justifications for patterns. In particular, I think that some programmers develop blind spots around the edges of the patterns that they apply to their code.

I've seen a number of cases where patterns from the GoF have been applied inappropriately. The best of these cases merely introduced unnecessary complexity. The worst cases actually led to serious issues of rigidity, fragility and immobility in the surrounding code. Clearly patterns are not a panacea, yet I've seen them used that way, as if by rote. Of course, this reflects a failing of the developer(s) concerned in each case, not a failing on the part of the GoF. But my concern is that the GoF patterns make traps like these easy to fall into.

Patterns are (or should be) a means to an end, not an end in and of themselves. Instead the end should be a design that is flexible, robust and reusable. Perhaps that sounds easier said than done, but it is the natural consequence of adhering to the five SOLID principles of object-oriented design, collectively popularised by Uncle Bob.

In a recent, unscientific straw poll of eleven of my peers, only two of us were familiar with the SOLID principles, yet all eleven were familiar with the GoF book. This state of affairs worries me greatly.

Briefly, the five SOLID principles are as follows.

Single responsibility principle: Every class should have exactly one reason to change.
Open-closed principle: Bertrand Meyer's paradigm-defining assertion that classes "should be open for extension, but closed for modification". That is to say, new behaviour can be added to a class without needing to modify it.
Liskov substitution principle: Derived classes must be substitutable for their base classes. Everything that is true of a base class must also be true of its derived classes.
Interface segregation principle: Classes should provide separate interfaces, according to the sets of methods that are required by their clients or client groups.
Dependency inversion principle: Dependencies should be on abstract interfaces, rather than on concrete implementations.

These are the principles that underpin all good object-oriented design, including the patterns in the GoF book. And it is these principles that should be a lingua franca in design discussions, regardless of the specific programming languages involved. Of course, the GoF patterns can and should still be used where they are suitable. But they should be used within a framework of understanding the design principles on which they are based.

Improving TDD with one assertion per test

2010-01-06T13:36:00.000Z

A nagging problem that I continue to suffer from when practising TDD is the urge to take bigger steps at each turn of the cycle. It's a problematic itch because, when scratched, it leads to longer periods coding with a red bar. In my experience, coding against a red bar is like leaving the lid off a petri dish: bugs grow there. When smaller steps are taken, the lid is off the petri dish for a shorter time and bugs have less opportunity to develop.

Recently, in an effort to address this issue explicitly, I started restricting my unit tests to a single assertion each. It is not an original idea, although I'm not sure where the proper credit for it lies (I first saw it mentioned in this old post by Dave Astels). I've dabbled with the technique before but, for whatever reason, I was unconvinced at the time. However, I've now come to realise that it may be the best weapon I have against the aforementioned itch.

Typically, when I'm writing the test for some planned feature, part of my brain seems to rapidly announce a list of all the conditions that must be tested in order for that feature to be done. Followed to their natural conclusion, these thoughts lead to a unit test that appears comprehensive but looks messy. There are echoes of BDUF here, I think, in the eagerness to get every permutation written down right now, almost OCD-like.

By limiting myself to just one assertion per unit test, I'm forced to ignore all but the simplest of these conditions, which can feel frustrating at first. Yet it has the precise effect of minimising the time spent with a red bar, usually to under a minute. The remaining conditions are dealt with by subsequent unit tests and suddenly I find myself hitting that very tight red-green-refactor rhythm, which tells me that I'm practising TDD how the books say I should.

There is another benefit to using this method too. I've discussed the issue of clean unit tests before and I'm always concerned that my own are not as clean as they should be. With only a single assertion, though, I've thus far found it impossible to write a messy unit test.

My take on the Stack Overflow DevDays

2009-10-30T18:49:00.005Z

On Wednesday, I attended the London leg of the Stack Overflow DevDays. Conferences are normally way out of my league, financially, but at a relatively cheap £85, this was my first chance to spend a day at one.

Carsonified, the event organisers, did a really great job setting up the venue. The wireless was near faultless and there were plenty of power sockets to run laptops from. Twitter apps encouraging social interaction among the audience were also a neat touch.

It felt like there were a lot of speeches crammed into the day, kicked off by Joel's excellent and thoroughly engaging keynote. Of the others, these are the ones that I found most interesting:

Michael Sparks analysed the source code for a spellchecker, written in just 21 lines of Python by Google's Peter Norvig. From a technical perspective, this was an excellent speech, walking through the source and building up a mental model of how powerful Python can be.
Reto Meier's introduction to Android development probably captured my imagination more than anything else. He was quite explicit about contrasting Google's openness with Android against Apple's paranoid control-freakery with the iPhone, which was a pretty astute pitch to a hall full of developers. And having the JVM at the core of everything just sweetened the pill even further, when compared to Objective-C (of which more in a bit). It got me tossing around some ideas for an Android side-project, written in Clojure.
Next up was Remy Sharp's talk on jQuery. I got the impression that 90% of the audience found this one quite tedious because it was aimed at jQuery novices. But that suited me perfectly and I found it to be a great introduction. It also helped that Remy is clearly a very accomplished public speaker.
Phil Nash presented an iPhone development jump-start. It was another good speech and quite a persuasive argument for investing the time to learn Objective-C, but... Objective-C. I mean, what's with that language? It just seems wilfully awkward. Separate labelling and naming of arguments, for instance; did somebody really think that was a good idea? Suffice to say, Clojure/Android seems way more attractive to me at the moment.
Pekka Kosonen delivered a fairly high-level overview of Qt. I first looked at Qt three or four years ago, while evaluating cross-platform C++ libraries. Unfortunately, the GPL restriction on the free version turned me right off, so I chose wxWidgets instead. That was a shame, because Qt's signals and slots architecture sounds cool. Anyway, since buying Trolltech, it appears that Nokia have relaxed the GPL restriction, so I may come back to Qt next time I need to work in C++. It looks like Nokia's intention is to leverage Qt to muscle in on the developer space that Apple has carved out with the iPhone and Google is now angling for with Android. I wish them luck, but I can't see it happening somehow.
Last up, Christian Heilmann delivered an interesting overview of Yahoo!'s developer tools. I'm already familiar with YUI because it is at the core of Ubiquity XForms but, of the others, YQL seemed especially interesting. I thought it was a bit of a shame that Christian's talk was at the very end of the day, because the audience were visibly tiring by that point.

All in all, it was a good day and definitely worth the entrance fee.

Five wishes for the javascript debugger in Safari

2009-09-25T08:11:00.006+01:00

This week, I played around with the javascript debugger in Safari 4, as I started adding Safari support to Ubiquity XForms. Until now, all of my javascript-based work had been targeted at Internet Explorer and/or Firefox, so I had no prior experience with Drosera. From experience debugging javascript in those other two, though, my feelings about what is a pretty significant part of modern software development were mixed at best.

There were some early hiccups, predictably enough, but I was quickly impressed by what Safari offered. The UI looked slick and it ran very reliably. Overall, my impression was of a very solid debugger, so kudos to everyone involved for that.

However, I was also left with a sense that, if only a few more crucial features had been implemented, the whole thing would be genuinely industrial-strength excellent. That feeling led to this blog post, so here, ladies and gentlemen of the internet, are my five wishes for the javascript debugger in Safari:

My biggest gripe at the moment is that changes to my scripts are not loaded when I refresh the page in the browser. I assume this is probably down to something in WebKit itself, but when debugging it is a major pain to have to close and re-open the entire browser, just to debug with some modified code.
Hot keys for important actions like 'step over', 'step into' and 'step out of' would be a massive bonus. When debugging large applications, it can take some time to zero in on problem areas. On every occasion that my fingers have to leave the keyboard, just to step to the next statement, that time is increased.
Making the console window update calculated values dynamically would also be a huge time-saver. Round about the third or fourth time that I have to paste the same variable name into that window, just to see its current value, it gets quite tedious. Alternatively, a dedicated watch window, separate from the console output, would be just as good.
Tooltips for certain items like variable names, showing the current value, or breakpoints, showing the current hit count. That would be sweet.
And if that little lot got finished, then it would be really nice if the code view were actually a code editor, so I didn't have to Alt+Tab to a separate window to make changes. This would be especially great because the dropdown list of currently loaded scripts is way cool and I really, really want it in my editor.

UPDATE: So, I've just discovered that you can use the cursor keys for shell-style scrolling through the command history in the console window. You can also use them to auto-complete the names of objects, properties and methods. These go a long way to assuaging my pain from #3, although the dynamic update of values / dedicated watch window would still be very nice to have.

The XForms Developer Zone

2009-09-15T18:46:00.002+01:00

Well I've not been around these parts much of late, but it is good to see that the old blog is still standing. Now seems like a fine time to blow off the cobwebs that have gathered around this place and post some news about what's been keeping me so busy.

Over at Backplane, we've dedicated a significant portion of the last few months to improving Ubiquity XForms, the open-source project that we're developing jointly with IBM. Going hand-in-hand with this work has been the creation of a new XForms community resource, the XForms Developer Zone. The vision for <xforms:dz> is a community-driven site for anything and everything XForms-related. Developers and users of all XForms processors are welcome, in fact they (and you) are positively encouraged to sign up and contribute.

As it is only the first day of the new site's life, content is still quite thin on the ground right now, but we're aiming to add new articles thick and fast. Already on there, amongst other items, is a tutorial by yours truly that demonstrates how Ubiquity XForms and Google Maps can be combined to easily add powerful map controls to your web pages. And looking forward, we're excited about plenty of other Ubiquity XForms articles that we have in the pipeline, not to mention even more content about the likes of Chiba, formsPlayer, Orbeon, XSLTForms and XForms in general.

That IE8 ten grand thing, clue #4 (b)

2009-06-22T09:34:00.017+01:00

So, @Tengrand_IE8 just tweeted again, yet it seems too early for the next clue to me, even when the time difference to Australia is factored in. Is this a new clue? Or another part of today's clue?

The clue is a link to an image, showing parts of the Canadian province of Saskatchewan and the American states of Montana and North Dakota. Featuring quite prominently is the Canadian city of Regina. Regina is the latin word for 'queen'. Is that what this clue is getting at?

If we then run with ENKC's Oscar Wilde idea about today's earlier clue, it seems that The Importance of Being Earnest was part satire on the reign of Queen Victoria. So my gut is telling me that the first part of today's clue identifies Wilde's play and the second part identifies Queen Vic. Victoria is also a state in Australia, where Microsoft are running the competition. It all seems to fit together rather nicely, pointing at 'Victoria' as today's answer. Or am I seeing patterns where none exist?

That IE8 ten grand thing, clue #4

2009-06-22T07:24:00.011+01:00

Clue #4: "New clue: a predatory fish being earnest".

What strikes me first is the presence of the text "new clue". None of the other clues had that. Is it part of the clue?

A predatory fish. Shark? Piranha? Barracuda?

Synonyms for earnest: grave; humourless; no-nonsense; sedate; serious; severe; sober; solemn; staid; uncomic; unfunny; unsmiling; weighty.

I shall ponder it some more on my journey to work.

UPDATE: EKNC made the inspired link from this clue to Oscar Wilde's The Importance of Being Earnest, an oscar being a species of predatory fish. That feels like a very good answer to me.

That IE8 ten grand thing, clue #3

2009-06-21T09:36:00.010+01:00

Hmmm. This one's a toughie. "You are now watching 370211931299".

At first my attention was drawn to the numbers. Three hundred and seventy billion, two hundred and eleven million, nine hundred and thirty one thousand, two hundred and ninety nine. It is a pretty big number, seems too big to be significant in and of itself. It is not prime. The constituent digits sum to 47. In hexadecimal it is 563259c4a3. I'm making approximately zero progress here, anyone else have thoughts on it?

After failing with the numbers, I decided to fail with the words instead. Why now? Why watching? What do each of those four words mean, decomposed, in isolation? I'm completely stumped right now, so I shall let my r-mode do its thing in the background while I teach myself Ruby.

UPDATE: It turns out that I was being way too analytical on this one; 'Anonymous' has quite brilliantly pointed out that the clue refers to an item on eBay, item #370211931299. 'You are now watching' is the part that was meant to get you to eBay, it is the phrase displayed when you watch an item. So my hunch is that the answer to this clue is title of the book: "Buried Treasures You Can Find". But more context is needed, roll on the next clue!

That IE8 ten grand thing, clue #2

2009-06-20T09:33:00.007+01:00

Morning, internet. Today should be all about a gentle recovery from my obligatory Saturday morning hangover. But, with it being a Lions year, a gentle recovery is not really an option. It is the first test match today, so it's all about the hair of the dog that bit me.

Second clue is up. Can I be bothered? Not really sure. "FbWiFnRg". In spite of my fuzzy head, the presence of Microsoft's bing in there seems obvious. It is interspersed with the letters F-W-F-R, which, according to bing, is a four-word film review. Is that significant? I'm not sure. Perhaps sobriety, however fleeting, will aid matters.

That IE8 ten grand thing, clue #1

2009-06-19T09:30:00.013+01:00

Not being Australian, or knowing any Australians, I'm not in a position to take part in Microsoft's mildly diverting hunt for the 'buried' $10,000. So instead I'm going to offer what little insight I have gratis to my dear friend, the internet. Are you there, internet?

The first clue is a cinch: "3000 upside down".

In roman numerals, 3000 is MMM. Upside down, that is www. Clearly we have the beginning of a URL.

Next!

Grokking the SRP

2009-05-02T14:22:00.007+01:00

I've been doing a lot of thinking about the single responsibility principle recently. It is one of the many excellent things I've learned from reading Clean Code (there's that book again, I promise to stop namechecking it soon). Basically, the single responsibility principle asserts that classes should have only one reason to change.

One bit that I really like about it is that definition of responsibility: a reason to change. Defining it thus, in terms of the effects, immediately suggests some of the benefits that are available to adherents to the SRP. Individual changes become localised to specific areas of a system, not strewn out across numerous modules. This means that making changes becomes easier and the risk of introducing problems when making those changes is decreased. It also has the effect of making code easier to read, because each module in the system will be focused on just one area.

Another good aspect of the SRP is that it provides an objective test of whether a class is too big. Rather than relying on some abstract property such as the number of lines of code it has, it suggests instead ways to verify that even very short classes are not doing too much. For instance, if some member variables are used only by a subset of methods in a class, that might be a reasonable pointer to a smaller class that is stuck inside waiting to be released.

And the SRP applies to methods too. It is commonly accepted that good functions do one thing, at one level of abstraction. Conceptually, this just seems like the SRP at the function level to me.

My realisation of the fundamental truth encapsulated by the SRP has already led to one significant set of refactorings in one of my side-projects: the extraction of all exception-throwing code out to dedicated exception-throwing classes. All told, the process took a couple of weeks of my spare time, but it was worthwhile. The resulting code was both shorter and eminently more understandable. Looking forward, I feel more confident as a developer, having the SRP in my armoury.

Clean unit tests

2009-04-18T08:25:00.008+01:00

Earlier this week, I read the chapter on unit tests in Clean Code. One of the things it stresses is that having clean unit tests is in some ways more important than having clean code, because unit tests themselves are prone to rot exactly as production code is. Yet, whereas rotten code can be refactored with confidence as long as it is supported by unit tests, rotten unit tests are an outwardly-spiralling liability that become progressively more difficult and time-consuming to maintain. Eventually, if left unchecked, rotten unit tests get dropped entirely, at which point, every subsequent change to the production code becomes a potential bug.

Well, forgive me father, for I have sinned. Seriously, I'm ridden with guilt on this one. It seems such a manifestly obvious point that I can't believe how thick I was being not to realise it before. I always just kind of hoped that my unit tests were fire-and-forget tools, smart weaponry that needn't be reconsidered once written. At times, of course, I've had to modify tests to account for behavioural changes in my code or whatever, but I've always done it in a thoughtless fashion, regarding it as a distraction from my actual work rather than important work in its own right.

The area in which I'm most culpable is 'single concept per test'. The anti-pattern I've tended to use in my unit tests is to write a test for a given method, then continue to test all variations of parameters and entrance conditions to that method in the same place. But, of course, each of those variations should be a separate test in its own right. It has also confirmed for me that I'm doing test-driven development wrong. For some time, I've suspected that I'm not taking small enough steps, and I see my dirty unit tests as another symptom of that. They are part of my coding phenotype, I guess, with incorrect TDD in my genotype.

So, anyway, that's the diagnosis. The prescription for cure, I think, lies in the build-operate-check pattern and perhaps adhering to a given-then-when naming convention (ripped off from Dan North's behaviour-driven development). I shall also experiment with limiting each test to a single assertion, although I'm not convinced enough about that to get dogmatic about it.

Software craftsmanship

2009-04-05T15:06:00.015+01:00

The software craftsmanship movement has been accumulating an increasing amount of attention lately and I think it's an important development for the software industry. When I first heard the term used, I have to confess that I wasn't a fan. I detected a faintly unpleasant air of superiority and pomposity surrounding the whole thing. In hindsight, I see that this was primarily a defensive reaction on my part, stemming from an unacknowledged realisation that my own set of development practices at the time weren't working as well as I'd hoped. But since then, my thoughts regarding software craftsmanship have altered radically, in line with improvements that I've gradually been making to the way I develop software.

Fundamental to this change have been my early experiences with the various XP practices. As I've discussed here before, my experiences with XP have been something of a mixed bag. Part of the struggle has been in the small team size and the lack of a single, unifying project to work on. The company I work for is simply not a good fit for out-of-the-box, vanilla XP. However, some of the practices have had a hugely positive effect on our productivity and none more so than test-driven development. Seeing and feeling the benefit of TDD in my daily work was a trigger for me to analyse other practices and approaches that might make me a better developer.

At that point I started to read a lot of technical books. I've always been an avid reader, but reading for me before then was always about escapism, so I rarely bothered with non-fiction. Now it is the other way round; I rarely have time to read fiction because my stack of unread technical literature is piled so high. Most of the books I read during this period were good. A few of them, though, were just magnificent. These few have filled in some of the other holes in my approach to software development, continuing the process that TDD started:

Refactoring, by Martin Fowler;
The Pragmatic Programmer, by Andy Hunt and Dave Thomas;
Clean Code, by Robert C. Martin;
Pragmatic Thinking & Learning, by Andy Hunt.

So now I find myself thoroughly approving of the idea of software craftsmanship. It feels as though a great myth of our industry is finally being busted. Software development is not engineering. It is not science. It is craftsmanship.

Clean code and static analysis

2009-03-28T11:27:00.006Z

I've been meaning to buy a copy of Uncle Bob's Clean Code for a while now, and finally did so this week. It seems like a pretty good read so far: Principled, opinionated, well-argued and right.

It has set me thinking about a possible side-project too... are there any open-source static analysis tools that specifically analyse code cleanliness? I'm imagining metrics such as longest function, mean function length, argument counts and so on. Analysing names would be difficult I guess, although incidences of one- and two- character variable names could easily be tracked, for instance. I shall do some hunting around for existing projects while pondering this some more.

A refactored workspace

2009-03-20T07:24:00.008Z

Last autumn, there was a point where I was spending most of my free time manically extolling the virtues of Andy Hunt's excellent Pragmatic Thinking & Learning to anyone that would listen, not to mention quite a few that wouldn't. Most people managed to feign interest quite well, presumably certain that it was just a phase I was going through and that it'd pass soon enough. It did leave a lasting impression on me, though, and I realised yesterday that my workspace has become some kind of weird shrine to much of the book's content.

It started with a single index card, bluetacked to the wall above my display, reading "CONSIDER THE CONTEXT". The book suggests doing this as early as page six, so I obviously bought into it right from the off. The index cards gradually multiplied and changed as I progressed through the chapters, until eventually there were 13 of them, arranged in two horizontal rows just above my display. They're generally just little reminders of things from the book that seemed like they might help me to work more effectively. My favourites are: "Don't just do something, stand there"; "Learn by synthesis"; and "Know what you don't know".

The next thing to change on my desk was the addition of a second display, effectively doubling the size of my visible work area. As the book suggested it would, doing this had a tangible, positive effect on the way I work, allowing me to focus my attention on more pieces of information simultaneously.

Almost immediately, I followed that by installing VirtuaWin, software for Windows that allows you to run separate virtual desktops. So web browsers, iTunes, IRC and so on were all banished from view, allowing me to focus purely on actual work. This resulted in fewer interruptions, less context-switching and increased productivity.

Then, just before Christmas, I decided that the starkly-lit, whitewashed walls of our windowless basement needed breaking up with a bit of colour. So I bought a couple of posters on the internet that would also serve to remind me of the book's advice. The first is a picture of the earth, taken from the moon. This reminds me to turn my assumptions on their head if I'm ever stuck on something and try to view them from a different angle. The second poster shows both the tip and the much larger, hidden section of an iceberg. This reminds me that a problem's symptom is not the whole thing and that I must always consider the context.

The final piece of this slightly obsessive jigsaw was actually something I first heard of from Hunt's first book with Dave Thomas, The Pragmatic Programmer. I wish I'd read that book much earlier on in my career, because it would have saved me from learning a lot of things the hard way. As it was, it was a great feeling to finally put proper names and rules to concepts or approaches that I'd been imperfectly forming in my own mind over the years. Anyway, the last arrival at my desk was a plastic duck, a prize from a rather drunken general knowledge quiz at my friend's house on New Year's Eve. It feels like I was destined to win that duck, who now occupies pride of place on the stack of books next to my two displays.

So what's the point of the duck? The duck is there for me to talk through sticky problems with. It is consistently surprising how the very act of describing aloud the symptoms of a problem can instantly cause one to discover the cause. By describing the symptoms to the duck instead of a person, I am saving my teammates from the tedious job of walking across the room just to listen to me answer my own question. Although I must confess I'm still occasionally guilty of this, so I'll add a 14th index card to my wall today: "Talk to the duck!"

The 12-day week

2009-03-12T22:20:00.012Z

The last month or so at work has seen a change in emphasis for me, as I've shifted my focus to the Ubiquity XForms project that we're working on in partnership with IBM. Ubiquity XForms is an open-source, cross-browser, client-side javascript library that implements the W3C's XForms 1.1 recommendation and is now pretty close to reaching full compliance in Internet Explorer and Firefox.

In an effort to break the back of the remaining features, we agreed as a team to throw ourselves whole-heartedly into a timeboxed coding marathon. This involved ditching the typical iteration plan for a couple of weeks and instead throwing all of the outstanding story cards onto the whiteboard. It was then a case of ploughing through the stack of cards as quickly as possible. Although this approach breaks almost every principle of XP, the consensus was that it was worth the extra effort at this point in time. So, coming towards the end of an arduous 12-day week, I've got a few observations about the experience.

At the start of the week I drew up a new BVC on the whiteboard by my desk. I had in mind the run-rate charts that television broadcasters put on screen during coverage of limited-overs cricket matches. It is similar in many ways to Scrum's burn down chart, except that the progress is plotted as a required rate of stories per day rather than a sum of all the outstanding work. I have no idea whether this kind of chart is one that has been used by other devlopment teams in the past, but I thought it was pretty useful in our situation. Update: Here it is.

Predictably, there was a big increase in stupid, sleep-deprived coding errors, especially in the evenings. The cost of these was kept reasonably low because of TDD. Code a bit, test a bit, code a bit, test a bit, code a bit, what the...? Keeping the cycle tight meant that it was never a big deal to undo some changes or svn revert before having another go at something. The thought of doing it without that safety net of unit tests is genuinely frightening.

Something that I hadn't expected was the sense of unity and common purpose that evolved within the team. Most of the time, each of us is working on a separate project, pretty much isolated from everything else that is going on. Obviously we talk about each others' work and so on, but there is rarely any collaboration between us. This has never seemed remarkable to me before, it was just the norm in our office. But the situation now is a noticeable improvement and I hope that we are able to maintain it.

Ultimately, I think that the coding marathon has been part-success, part-failure. We didn't finish everything that we set out to, but we achieved a fair amount and learned some new things on the way. I'll be very interested to hear everyone else's thoughts during the next retrospective.

XForms in .NET

2009-02-14T11:33:00.007Z

I've just updated an old article that I wrote on the Code Project. It describes how to use XForms to build dynamic user interfaces in a .NET application. If that sounds like it might be your bag, check it out. Behold! How to Harness the Power of XHTML and XForms in your .NET Applications.

Reflections on applying XP to a (very) small company, part I

2009-02-04T20:11:00.011Z

There have been a lot of excellent posts in the agile blogosphere of late about poor technical practices causing teams to fail. These have tended to centre around Scrum, for the obvious reason that it does not mandate the use of any particular technical practices per se. Although we are not using Scrum, I've been pondering the implications of many of the concluding opinions for my own team (my own implies membership rather than ownership here btw).

We are a small team of three developers, each tending to work on a completely separate project to the rest. In fact, it would probably be more accurate to say that we are three one-man teams, rather than a single team of three. This structure is one that has grown organically, through necessity, as the business itself has developed over the years.

About a year ago, we discussed as a team how we could work more effectively. Our manager indicated that he was keen for us to try XP, using James Shore & Shane Warden's excellent tome as our bible. The book quickly pointed out that our team size and the amount of legacy code involved meant that we were not simply looking at a standard, vanilla port of XP. However, we realised that there was still an awful lot that we could try to collectively improve and have since had varying degrees of success applying some XP practices:

Working to a regular rhythm of weekly iterations and thus knowing our velocity was a near-immediate win.
Ditto the informative workspace with lots of whiteboards and big, visible charts.
Retrospectives and daily stand-up meetings have both gone pretty well, although they seem to be valued much more by some team-members than others.
Unit tests, TDD and refactoring have been introduced, but there is still a very large burden of technical debt to pay off. We also have some source code, mostly written in XForms, that we lack a suitable unit-testing framework for (which probably means we should be writing one ourselves).
Pair-programming enjoyed a brief period of popularity and promsicuity before fizzling out somewhat. It still makes an appearance from time to time when individuals want to make it happen, but the combined effects of an odd-numbered team, the disparate nature of the projects we're each predominatly responsible for and the resultant context-swapping that occurs when we switch the pair are a problem for us.

On balance, I think that we're definitely operating more effectively as a team than we were a year previously. However, I am utterly convinced that we remain a long way short of anything like our full potential. And the single, biggest factor in taking the next step seems to me like sustaining a radical increase in the amount of pair-programming we do. Hopefully, a year from now, I'll be writing a new post here about how we got on.

Iteration plans, my antidote to procrastination

2009-01-28T21:22:00.009Z

I read an interesting article recently that described a study into the causes of procrastination. I have suffered at the hands of that particular demon more than once in my life and am consequently quite interested in the psychology of it. People (i.e. me) are often aware that they're not doing themselves any favours by procrastinating, yet they can continue to invent ever more creative devices to avoid getting on with the job in hand. The study mentioned in the article concludes that people are more likely to procrastinate if the task they are trying to do is viewed in abstract terms, whereas people tend to act quicker when they are given specific, concrete tasks.

This effect is something that I became very aware of in myself when I first started using XP practices. Specifically, I discovered that the rhythm of regular iterations and the breaking down of features into stories (and stories into tasks) really helped me to cut out time that I was previously spending between tasks on trivial or even unnecessary jobs. I've not seen this effect discussed explicitly anywhere, which makes me wonder whether procrastination is not a big deal for most people? Or perhaps it is, but people don't like to aknowledge the existence of such a negative trait?

What I do know is that I am now very reluctant to work on a project without the supporting crutch of an iteration plan to help me focus. This is despite the fact that I basically work as a one-man team in my job and that in the preceding n years of my professional life I seemed very happy with just a bug-tracking system and a long queue of bugs.

Introducing Hubbub

2009-01-23T21:54:00.008Z

In my day-job for the last six months, I've been working on a new application called Hubbub. In its current form, Hubbub is a social networking client based around a couple of popular web services: FriendFeed and Twitter.

Our aim was to provide an interface to their APIs that was radically different to the look and feel of existing client applications. We wanted the UI to be intuitive, aesthetically pleasing and unhindered by the limitations of convention.

To that end, we enlisted the services of Bartek, an excellent Dublin-based designer that we've worked with on a number of projects over the last few years. He came up with some great designs and helped us to put some intellectual dynamite under the constraints that application developers typically operate within.

Looking forward, there is still a ton of stuff that we want to do with Hubbub, however it is at the stage where we're keen to start getting feedback from real users. It is only available on Windows for now, as there is still some work outstanding on porting our UBX framework to other operating systems. But if you're interested in finding out more, check out the screenshots, or sign up for the beta and download Hubbub for yourself. And if you have any feedback, bug reports or feature requests, you should post them to the Hubbub mailing list.

To play is to learn

2009-01-21T16:33:00.007Z

One of the myriad excellent things that I learned from Pragmatic Thinking & Learning concerns how playing with information is a highly effective method of learning (it is how we instinctively do it as children, after all). I just spotted an utterly inspired case of this on Our Signal: Ruby Warrior, a game that teaches the Ruby programming language by requiring the player to write Ruby scripts to complete game levels. A brilliant idea, brilliantly executed. One day, all introductory programming courses will be like this.

Considering const_cast

2009-01-08T16:11:00.003Z

Yesterday I had cause to consider the const_cast operator from C++. I came this close to employing it out of sheer laziness when working with some legacy code. Fortunately, voice #2 objected loudly enough to rouse my conscience in the nick of time.

It made me ponder, though: is there any conceivable scenario in which casting away an object's const behaviour is the right course of action (as opposed to the quickest, say)? It seems pretty unlikely. So I guess the argument must run that at least explicit usage of const_cast makes such activity easier to find in large code bases, which is fair enough.

However, what if there was no const_cast to fall back on in the first place? And, furthermore, what if compilers refused the right of C-style casts and reinterpret_cast to cast away an object's const? Might enforcing the sanctity of const in this way make C++ a better language?