Anyone who has worked at an organization with more than a few developers for a reasonable period of time would have felt the pain associated with a growing codebase. The word ‘legacy’ creeps into the everyday language and the number of maintenance tasks soon exceeds the amount of time spent writing new code.

The maintenance tasks hopefully make your existing clients happy (’serve the client in front of you’) but the reduction in new code generally means less new features per developer and therefore is naturally linked to a reduction in your ability to increase the amount of product you can sell to your clients.

There is of course a correlation with the amount of code you write to the amount of maintenance it requires however exactly to what factor this is depends entirely on your processes and how they affect the technical debt you incur.

Relish deleting code

My first piece of advice to any developer (you never know when your own codebase will become a multi-developer maintenance monster) is to relish deleting code. Most code, after-all, is the application of standard algorithms and patterns to specific problems and is therefore not that useful or unique once it is no longer required.

Don’t keep code around just in case. You have it under version control so as soon as it is orphaned then delete that sucker. Have an active deprecation process that is regular and ruthless!

Campaign actively to deprecate unused functionality within your organization as well. The temptation to keep functionality around just in case is not reserved to developers; product development, sales and marketing all fall into this trap.

It is costly to leave unused functionality and code intact because it costs an organization in a number of ways:

• Developers have more complexity to deal with and this will always result in waste.
• Users have more unnecessary complexity which affects the usability of your product which in turn affects how your product is percieved.
• Technical debt is incurred over time - its like continuing to pay rent on an apartment you already moved out of.

The global namespace is not your playground

Making changes becomes the focus well before the codebase even reaches the inflection point of maintenance outstripping new code. This is because many features of any given software product are built on top of existing features.

The enemy of change is the dependency and the easiest way to create unnecessary dependencies is to create globals because if its in the global scope then other coders will use them. Declaration scope and JIT inclusion of necessary dependencies are your friends – use these wisely.

Those entry points into your codebase that are necessary because they are utilitarian or because they kick your application off should at least be namespaced off into a structure by using a pattern such as the Singleton. Don’t be fooled – a Singleton is still a type of global but it is much easier to attach documentation to and control the signature for it.

Divide your code into layers to assist in reducing coupling and avoid having lower layers called directly from layers that are not immediately above them. For instance – if your page or front-controller calls your database directly you will find you reimplement the same query creation code, query execution and object population code over and over. Its much better to abstract this functionality to an object hierarchy which can specialise in these tasks as there is nothing useful in seeing lowlevel logic scattered through-out the logic behind your presentation.

Much of this advice is available from a variety of sources and I do recommend reading up further on the topics I have mentioned if you found that some warning bells with your own organisation’s codebase started to ring. Codebases can become massive – particularly when their are multiple developers involved multiplied by a few years of time. Some continual investment in keeping the house clean will pay off by allowing you to spend more time on new code.

I have long found Outlook a pain-in-the-butt to use and a few years ago switched back to Thunderbird (I had been a user of the Netscape Mail client in a former life…).

I find Thunderbird is much lighter and quicker at filtering mail than Outlook. There are better clients but all seem to have their own quirks which have kept me from adopting them.

The main difficulty with replacing Outlook with Thunderbird is that it lacked a good calendaring option. Incompatibility with the other Outlook stalwarts in my office meant I was forever having to ‘View Source’ on email bodies to see when a meeting was to be held so I could go and manually enter it into Google Calendar (my primary calendar which I share with my team). Fortunately I found the Lightning plugin to add a calendar to Thunderbird but I was still manually updating meetings in Google Calendar.

Now I have just come across this excellent tutorial on setting up what might be the holy-grail of calendar setups and want to share it with all Thunderbird users and frustrated Outlook users. Here is the short version of the tutorial for experienced Thunderbird users :

1. Install Thunderbird 2, RC1
2. Install the Lightning plugin so Thunderbird can read Outlook meeting requests and place a calendar in the Thunderbird interface.
3. Install the Google Calendar provider to allow Lightning to add two-way synching with Google Calendar.
4. Add the XML address for your primary Google Calendar (Found under “Calendar Settings >> Calendar Address”).

And you are done – test it by setting a meeting in the calendar within Thunderbird. You should see the meeting appear in your Google Calendar shortly (I had to manually refresh). More information at each the sites I have linked to.

We seem to rediscover every few months that many users are typing the name of the search engine they are on into the search box. I read many disparaging remarks directed at this very large group of users and I wonder why the remarkers would think this behaviour is ‘clueless’ or ‘dumb’?

Forgetting what the user ’should’ do, lets consider the two options for a moment. Firstly, in terms of physical and functional composition, both methods of navigating the web comprise of a single field and respond to the enter key; so no difference there. Further, one is placed at the top of the screen, the other often nearer to the centre. I’d say thats one factor that the search box has over the navigation bar.

Moving on, the navigation bar will in most cases punish you for mistyping. Google and other engines will offer a link to (most likely) the site you intended. Now thats handy! I’ve started using the search method for those times its handy. Google Desktop makes it easy to get to a search box (just hit ctrl key twice). This is much easier than ctrl-tab a few times combined with another key-combination to open an URL (and then you get to type the URL…). Who wants to be doing what they ’should’ do anyway? That sounds clueless to me!

Not all instances of a search engine name being entered into a search engine is for the above reasons, though. ‘Google’ is entered into the Google search engine because who can remember where all their products are housed. Google, in their effort to deliver a ’simple’ homepage, avoid the portal type page so typing ‘Google’ can be all users can do to find their many great products.

Another point to consider are those keywords put into the navigation bar which aren’t legitimate URLs are often sent to a search engine in browsers such as Firefox. Who wants to spend time repetitively typing the fairly redundant ‘www.’ and ‘.com’ anyway…?

What can we learn from all this anyway? Well next time you consider calling a user stupid, stop yourself and look for the efficiency they are seeking. It can teach you alot about how you could make your application easier. Not everything needs to be reduced to a unthinking action but its worth taking the thinking out of the tasks that don’t require it so that effort is most effectively spent.

Maybe browsers should ditch the navigation bar? Maybe the navigation bar and search box should be one? I’d like to know your thoughts.

The line between code and documentation is blurring with the introduction of regimented documentation standards. In PHP reflection (and likely other languages as well) you can use reflection to programmatically access documentation blocks meaning you *could* make code dependant on information in your doc comments! Scary!

More scary is that I discovered this via a colleague who was considering using this. You could argue it conforms to the DRY principle because we were looking to add more strict control of return types implemented in methods that are derived from an interface we defined. This would require us to redefine information already part of our doc comments should we proceed without the reflection API.

For now we have elected not to proceed because it violates the rule of least surprise. Developers do not expect edits to comments affecting code conditionals and thus our effort to enforce correct use of interfaces could backfire causing exceptions in classes implementing our defined interfaces.

At some later date when the trend has continued and there is no line between code and API documentation or at such point we are confident our unit testing will prevent deployment of exceptions due to incorrect documentation we may reconsider this approach.