An integrated pomodoro timer for Visual Studio

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

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

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.