I Was Nominated To Speak At LoneStarRuby Conference 2013

A few days ago I woke up to see this in my Twitter stream:

Looking at the list of nominated speakers, I am in extremely illustrious company which was just amazing to see. Of course I replied with my appreciation. Then a little later I saw this:

Which was also very nice.

Who would have thought something like this would ever happen – thanks @IndianGuru.

Anyway, if LoneStarRuby Conference 2013 is of any interest to you and you’d like to make me write a talk hear me speak, you can go and vote.

Downgrading A Ubuntu Package

I was recently upgrading a couple of Ubuntu machines to the latest and greatest everything. It’s good to be up-to-date makes me feel like a no-nonsense, can-do developer :). Anyways one of the latest and greatest things that Ubuntu pulled in for me was the latest java 6 (JDK 1.6.0_14). All of a sudden my build started failing with strange coverage errors – I hate it when that happens. After looking around for a bit I found that there was a Cobertura issue with java 1.6.0_14, this one. So I though I’d try and downgrade Java 6 to the previous version (who needs to be fully up-to-date anyway, that stuff is for the birds, the real hardcore developers use the penultimate version, yeah!).

This of course was easier said than done, Ubuntu doesn’t really like it when you try to downgrade stuff. I thought that if I could obtain, or create, a debian package with the version of java that I was after I might just be able to manually install that one (yeah that might work). I was wrong, I did get my hands on the debian package that I needed, but Ubuntu spewed out some gaff about dependencies and … long story short, it didn’t work. Of course I could always forgo the use of the package manager and just manually install java and set up the PATH and JAVA_HOME and so forth but that would make me feel a little unclean so I thought I’d persist and do things the easy hard way.

Are You Actually A Post-Agilist?

Have you heard that term? I happened upon it purely by accident about a year ago and after reading and learning a bit about it I found that I could identify with it quite a bit. You can read Jason Gorman’s post Post-Agilism Explained (Pretentiously) as well as Jonathan Kohl’s massive post – Post-Agilism Frequently Asked Questions for a great discussion of what the post-Agile movement is all about. Jonathan and Jason independently coined the term at about the same time so they are an authority on the term if anyone is. I am going to attempt to give my humble views on the topic and hopefully you will identify with some of what I say.

For those of you who’ve decided to learn about post-Agilism after they finish reading this post (thanks!), post-Agilism is basically a movement in the software development community of people who see themselves as moving beyond Agile methods. They have used Agile and not-so-agile methodologies and have moved beyond both to using an amalgamation of tools and methods that best facilitate them doing their job. Post-Agilism is not about evangelizing a particular process or a set of practices or even the Agile Manifesto, it is about getting to the core of the issues that process in general tries to address and solving them in the best ways possible. At least, this is the way I see it.

The Real Measure Of Code Quality

There was a comic going around a few weeks ago about code quality, you remember the one:


Pretty amusing, but it got me thinking, what IS a good measure of code quality? Quality after all is very subjective, what I might perceive as being great, you might perceive as crappy for a host of reasons. A pet pattern wasn’t used quite right, the unit tests aren’t “real” unit tests, you know of a library that would have made the whole thing 10 times easier, etc.

There are all sorts of different measures that might relate to code quality, the level of coupling, the testability of the code, the test coverage, adherence to standards and many others and yet all of these are still subjective to a degree. There are times when not adhering to standards is best, just as there are times when a low level of coverage is good enough, it is all different from system to system, situation to situation. So is there no one good measure of code quality?

I contend that there is only one measure of code quality that is worth anything. We can argue all we want about numbers and patterns but in the end, one thing will always be true for every good developer:

The 4 Unlikely Traits of Good Developers

Lately, I’ve been thinking about what makes a software developer a good software developer. All the generic things that you would expect came to mind, knowledge, skills with tools/frameworks, memory, teamwork skills, caffeine etc. But all of those are boring and predictable, noone wants to be boring, so I thought harder, I thought and thought “till I couldn’t think no more”. Then I had some tea, then I watched “The Simpsons”, now I am writing this article, but I digress, which actually illustrates my first point fairly well (in a roundabout sort of way, so bear with me).

1. Creativity

While drinking my tea and munching on my crumpets (that’s a figure of speech I wasn’t actually eating crumpets, I was having a croissant … I think I just made it worse). Where was I, oh yeah, while doing something completely unrelated I was able to come up with some interesting points about what makes developers, developers. Unlike what TV and certain other elements would have you believe, most good developers are not just single-minded calculatory automatons obsessed with algorithms, but are rather very creative people. Notice how I made up a word in a very sentence preceding this one, I bet most of you didn’t even realise “calculatory” wasn’t a real word.

How To Retain Your IT Employees For Longer

The IT industry is notorious for its high turnover rate of employees. In fact it has gotten to the point that most companies don’t expect to keep IT personnel for a longer than around 18 months when they hire them. If you’ve ever worked in software or IT you would certainly be familiar with phrases such as “… none of us are gonna be here 2 years from now …” or something along those lines. I believe it has almost become a self-fulfilling prophesy, since no-one expects IT people to hang around for long, most of them don’t.

Of course the industry itself is partly to blame. It is still a very young industry and growing rapidly, which creates a lot of new opportunities and being by nature a fast-paced field it creates perfect conditions for people to “jump ship” whenever the fancy strikes them.

Despite all of this I believe there are many things you as an employer can do to keep your staff for longer and it is certainly in your best interest to do so. The hiring process is expensive and time consuming and you still don’t really know what you’re getting. Most importantly however, domain knowledge is not something you can easily replace. It takes years to acquire business and technical domain knowledge and it should certainly be high on your list of priorities to not loose the employees who already have this knowledge. Especially not to your competitors!

3 Things They Should Have Taught In My Computer Science Degree

That’s right only 3 things. Oh, there are plenty of things that I wish I would have learned about at university, but I am well aware that no degree will give you an exhaustive education in your field. A degree is meant to teach you the basics and equip you with skills so that you can learn the rest yourself. However, as I get more experience as a software developer, I find that I am increasingly frustrated about not having been exposed to these three things before I entered the workforce.

I believe that any Computer Science degree can be made a lot more relevant simply by paying more attention to these three points. Had I had more exposure to these things before starting my working life, I believe it would have given me some real world skills that I could have applied straight away, rather than having to scramble to learn everything I needed to know on the job. It would have made me better able to deal with the requirements of my work and would also have made me a better citizen of the IT community.

Why Web 2.0 Sucks

No Web 2.0

Ok, I have no problem with the concept, but does every man and his dog have to buy into using the acronym and especially the 2.0 suffix. Everything is 2.0 these days from the iPhone to grandmas corner cookie store (Cookies 2.0 – Dey Da Shznit).

Seriously the guy who invented the term should be roasted slowly over an open fire and just so it can be done properly, by experts, I condemn him to the deepest darkest pits of the 7th circle of hell. He’ll probably meet the guy who coined SOA there, I am sure they’ll have loads to talk about and become great friends.

What happened to the days when people coined grand and dignified terms for concepts they wanted to describe (like ‘cyberspace’ for example), the days you could look upon the acronym you’ve coined and know that it was good and would make you proud in the wild. No, now it’s all airy fairy concepts and trendy sounding punch lines, appealing to the youth market and all, makes me sick.

Fitness for Software Developers (and Other IT Professionals)


A software developer these days is almost certain to engage in some kind of activity to maintain their fitness. Well, I may be stretching things a little :), but there are certainly more than a few developers who exercise pretty regularly; fitness is the “in” thing to do after all. I however found that many developers are either doing the “wrong” kind of exercise or focusing too much on some muscle groups to the neglect of others.

Every profession puts different kinds of stress on different parts of the body, this means that some exercise is very beneficial in some occupations while being almost harmful in others. Here, I will attempt to give some pointers on the types of exercises and muscle groups it would be best to focus on if you’re a software developer (or indeed any other IT professional).

If Software Development Was Like Medicine: Part 1

Software development often gets criticized for various reasons, overrunning budgets, failing to meet expectations, producing a buggy product, the list is pretty long. Inevitably when this kind of criticism is levelled at the software development profession, someone will try to compare building software to some other field, most often construction. You all know the analogy I am talking about, it often starts like this, “If we built houses the way we build software…”, and then goes on to describe in great detail how misshapen and barely functional the houses would be. Well, I’ve always had a bone to pick with that analogy, so I decided to come up with a new analogy, and I picked a completely different industry, Medicine.

Having become a lot better acquainted with the medical profession than I ever wanted to be, over the last few years, I feel that I am qualified to make this comparison :). I also decided to look at the whole thing from another perspective, rather than comparing medicine to software development, I decided to do it the other way around – here is the story I came up with.