Article: This "Software" Stuff

The third installment in my mini series This "Software" Stuff has been published in the March issue of ACCU's CVu magazine.

Read it to find out how software is like child's play and a chore.

This issue of CVu was guest edited by Roger Orr, who has done a sterling job.

The cover I produced this month includes some top-secret implementation drawings of an embedded product's USB driver. Bonus points if anyone can work out which chip it's for!

It's not unusual

They say that some people see the glass half full, some see it half empty. But most programmers don't see the glass at all; they write code that simply does not consider unusual situations. They are neither optimists not pessimists. They are not even realists. They're ignorists.

When writing your code don't consider only the thread of execution you expect to happen. At every step consider all of the unusual things that might occur, no matter how unlikely you think they'll be.

For example:

Errors

Any function you make a call to may not work as you expect.

• If you are lucky, it will return an error code to signal this. If so, you should check that value; never ignore it.
  
• The function might throw an exception if it cannot honour its contract. In this case, ensure that your code will cope with an exception bubbling up through it. Should you catch the exception and handle it, or allow it to pass further up the call stack? If you allow it to rise upwards does your function leak resources or leave the program in an invalid state in the process?
  
• Or the function might return no indication of failure, but silently not do what you expected. You ask a function to print a message; will it always print it? Might it sometimes fail and consume the message.
  

Always consider errors that you can recover from, and write that recovery code. Consider also the errors that you cannot recover from; the storage failures or running out of critical resources. Even if you can't recover in these circumstances, write your code to do the best thing possible; don't just ignore it.

Threading

Too many programmers try to work in an idealistic single-threaded bliss. However, the world has moved around them to a complex, highly threaded environment. Reasoning about what might happen in your code in the presence of multiple threads is much harder.

Unusual interactions between pieces of code are staple here, and it's hard to enumerate every possible interweaving of code paths, let alone reproduce one particular problematic interaction more than once.

To tame this level of unpredictability, make sure you understand basic concurrency principles, how to ensure mutual exclusion in code blocks and how to decouple threads so they cannot interact in dangerous ways.

Understand mechanisms for the safe creation and destruction of objects in threads, and the correct primitives to reliably and quickly pass messages between thread contexts without introducing race conditions or blocking the threads unnecessarily.

Shutdown

We make great plans for how to construct our systems: how to create all the objects, how get all the plates to spin, and how to keep those objects running and those plates spinning.

Less attention is given to the other end of the lifecycle: how to bring the code to a graceful halt without leaking resources, locking up, or going wrong.

Shutting down your system and destroying all the objects is especially hard in a multi-threaded system. Objects that depend on inter-thread interactions can be particularly prone to subtle destruction problems: deadlock, dependency inversion and the like.

As your application shuts down and destroys its worker objects, make sure you can't leave one object attempting to use another that has already been deleted. Don't enqueue threaded callbacks that target objects which have been deleted on another thread.

Make sure that you thoroughly test your code for destruction issues as well as construction issues. Test it in an environment where you can control threading issues with mock objects, but also cover it with integration tests that glue real parts of the system together — the particular timings and order of operations there may highlight other shutdown problems.

The moral of the story

The unexpected is not the unusual. You need to write your code in the light of this.

It's important to think about these issues early on in your code development. You can't tack this kind of correctness as an afterthought; the problems are insidious and run deeply into the grain of your code. Such demons are very hard to exorcise after the code has been fleshed out.

Writing good code is not about being an optimist or a pessimist. It's not about how much water is in the glass right now. It's about making a water-tight glass so that there will be no spillages, no matter how much water the glass contains.

Lifestyle changes

At the end of last year I got a new mobile phone and changed phone number at the same time. I'd deferred changing phone numbers for as long as possible since I expected it to be a massive hassle. It actually wasn't too painful; I don't use the phone that often and there weren't too many people who new my old number.

Of course there might be a few people that still have my old phone number (mental note: check whether the girls' school has my new phone number). But what I don't know people don't know won't hurt me, right? Or at least, I won't know that I don't know it hurts me.

So that bodes well for my next lifestyle change, then.

This week I have to move my email address. Move my email address? It can't be that hard can it? It's kinda like moving house, but with fewer vans and boxes.

This is an email address that I have been using for the last, ooh, more than ten years. Turns out it's a lot more personal than a phone number. Whilst I've been using my goodliffe.net domain as my main contact email address for some time now, the threat of an old email address actually disappearing (cthree.org is moving mail provision service and rationalising their addresses in the process) is a sobering thought.

When I consider how many services I've subscribed to with that address, how much software I've registered using that as a contact address, and how many products and suppliers might contact me using that address, I realise that if the old address suddenly goes poof! I'll be in a bit of bother.

So what online malarkey has my email address? Off hand I can think of:

• Banks and credit cards.
• Several professional organisations.
• Service providers like electricity/gas and my ISP.
  
• eBay.
• PayPal.
• Amazon.
• Social networking places like: Facebook, LinkedIn, Myspace, etc.
• Skype and MSN-ny services.
  
• Many other shops (how can I remember them all?)
  
• My internet domain registrations and DNS services.
• Various product subscriptions.
• My software registrations.
• My book publishers.
  
• My friends.

And I'm sure I'm missing a load of stuff there. Frustratingly, if the old address is disabled then it's much harder to move some of these; many services require access to the old address in order to change to a new address.

I hope that I remember everything. And I'm left wishing there was a decent way to track who has your contact details.

Bootnote: if you have my old cthree.org email address in your address book then please update it to my new goodliffe.net address. You can probably guess it! Normal service will be resumed shortly.

Article: The Ghost of a Codebase Past

My latest installment in the Code Craft column, The Ghost of a Codebase Past, has been published in the current issue of Better Software magazine.

It's an encouragement to look back at your old code. Revisiting old code can be a frightening experience. But it's worthwhile; take a look to see how your technique has progressed, how your skills have grown, and what you can learn.

Read it here.

Speaking: ACCU 2009 (Legacy Code)

I'll be speaking at the ACCU 2009 conference, in Oxford UK. The conference runs from Wednesday 22nd to Saturday 25th April 2009.

Here's the summary of my presentation:

Legacy code - learning to live with it

Legacy code. You can't live with it. You can't live without it.

Well, you can't avoid it, at least. Spend long enough in the software factory, and you'll inevitably run into other people's old code. And of course, none of this old stuff is any good. It's nothing like the high quality software you craft. Pure tripe.

Let's be honest, sometimes you might even stumble across some of your own old code, and embarrassing as it is, you have to admit that you don't know how it works, let alone how to fix it.

This presentation will look at practical strategies for working with "old" crufty code. We'll see how to:

• start working with a completely unfamiliar codebase
• understand old spaghetti programming
• make correct modifications
• prevent bad code from causing more pain in the future

It should be a lot of fun.

If you're a developer and you've never been the the ACCU conference before, then I highly recommend it. It's excellent value for money, it has a great atmosphere, and you'll learn a tonne of really useful stuff.

Book: Beautiful Architecture

O'Reilly have just released Beautiful Architecture, a follow up to their hugely successful Beautiful Code book.

I have contributed a chapter to this book, entitled A Tale of Two Systems: A Modern-Day Software Fable. Based on my experiences with two contrasting development projects, it illustrates how software architecture affects many things, from the quality of the software, through to the morale and dynamics of a team, through to the very success of a company.

It looks like a great book, and all proceeds from its sale go to Medecins Sans Frontieres.

Grab it on Amazon here.

Running KDE 4.2 on Kubuntu 8.10

Earlier this year KDE announced their latest release, 4.2. This is probably the first release in the 4.x chain that's actually worth using. There aren't official release packages for Kubuntu 8.10 yet, but you can save yourself the source-build-athon by pulling in the "experimental" Kubuntu packages.

Sadly, it's a painful process. Is it worth it? Yes. This new version KDE really is great, but installation is definitely not for non-techies, yet. This is a shame as the 4.2 KDE release is for non-techies, whereas Kubuntu's stock 4.0 is most definitely not.

I've run through the upgrade process three times in one day now. Each time I've hit the same problems.

Installing KDE 4.2 on Kubuntu 8.10

The first trick is finding out how you are supposed to do it. The information is on: www.kubuntu.org/news/kde-4.2 (not in the Kubuntu FAQ or wiki).

Make sure your installation is up to date, and you have already installed the Kubuntu "restricted" extra packages first. Then add the "experimental" package repository for the software update process. This is a manual copy of an APT line, which is rather error prone. Indeed, it's incredibly important to get this line right, or the update not only fails, the adapt software installer program segfaults on startup. User friendly. Fixing the problem involves common sense, the command line and knowledge of apt and Linux. This clearly isn't ready for Granny, yet.

Next install some gpg keys. If you forget this, the update fails and leaves your system in a semi-screwed state that the adept GUI updater cannot fix, leaving you to again resort to the command line.

At last, you can hit "Upgrade" in Adept.

Now watch the errors. Back to the command line. Run apt-get -f install to try to clean up the mess. Agree to whatever it says. The computer knows best.

Then, if you don't want to be totally screwed, install the window manager that was magically removed with the above shenanigans. apt-get install kde-window-manager

Logout, restart X, say a little prayer, log in. Enjoy.

Hopefully that'll work fine. (2 out of three times it did.) If not, go back to the command line, apt-get install kde for luck, and see if everything else got installed.

Running KDE 4.2

Oh joy! Compared to 4.0, this is a joy to use. Most (not all, most) of the redraw bugs have been ironed out. Missing functionality had been restored. It's actually nice to use again. It feels as good as KDE 3.x felt in the day.

I'm a happy bunny.

I have to take my hat off to the KDE development community. They have polished and improved the KDE 4.x code considerably, and it's a job very well done.

Conclusion

No one suggested that installing KDE 4.2 on Kubuntu was supposed to be easy right now. If you have the smarts to do it, it's highly recommended. If you don't feel comfortable playing with apt-get by hand then it's probably best to wait until the packages become a mainstream Kubuntu release.