What is a table?

Many years ago a good friend of mine aced all his exams and went off to study clever things at Cambridge. While there he took a short course in philosophy and when we met up in the Christmas holidays he told me all about it, between lagers. It turned out that philosophy is all rather complicated and difficult and that’s why they only really bother telling you about it if you went to university. I confess that I don’t recall a lot of the information that was passed to me but I do remember one interesting bit where we talked about what a table was. My friend assured me that, over the years, many of the greatest minds in existence have attempted to answer that simple question, “What is a table?”. Why? Well, presumably because someone said ‘Please sit down at that table over there and do some work’ and rather than just get on with it most philosophers try to be all clever and ask what a table is first.

Anyway “What is a table?” is actually quite a difficult question to answer. “Something you put stuff on”, “Something you sit in front of”, “A flat surface with one or more legs” perhaps. They all seem reasonable if partial answers but none quite help determine how a table might differ from a desk or whether or not a cardboard box can be considered a table if, for example, you put your can of lager on it.

Happily we don’t need the definition to enable us to recognise a table when we see one. It looks right, it feels right, we’re comfortable and safe in the knowledge that we’re dealing with a table and not, for example, a chair, or less likely, a baboon.

Good IT Managers (good managers in general come to that) are like that. No, I’m not saying they’re baboons although some I’ve know have erred on the simian side. I mean it’s not that easy to pin down exactly what a good manager is or how one behaves but we can generally tell a good one pretty quickly when we see it. What is the quality or qualities that help us recognise a good or great manager compared to an OK one? Equally what anti-qualities allow us to quickly spot a dreadful manager? Why do we even need to know?

The car manufacturers know that one of the things people look for when they buy a new car is that reassuringly expensive door close “clunk”. They consequently spend fortunes getting the doors to make just the right sound. Of course, as a consumer, hopefully your entire car purchase decision isn’t just based on the doors. Hopefully you seek to check a whole heap of things and hopefully you know the things that really matter to your own personal decision.

If we know the qualities we’re looking for in a manager or a management style then a few things potentially slot into place:

1. We get better at distinguishing the good from the bad.
2. We enable ourselves to improve our own management style.
3. We may get to recognise those managers who just have a good door sound and not much else.

So what makes a good manager for me? In no particular order…
I want to be managed by someone I can trust and believe in which makes honesty high on my list.
I want to be managed by someone I respect which makes intelligence and integrity important.
I want to be managed by someone who recognises what I do well and helps and encourages me to improve when I don’t.
I want to be managed by someone who is able and willing to empower me and will show faith in my abilities (as long as I don’t screw up).
I want to be managed by someone who listens and respects my opinions.
I want to be managed by someone who is fair and even-handed.
And I want to be managed by someone who is willing to have fun and not take themselves toooo seriously.

And, incidentally, that’s the manager I’d like to be too.

In every disaster a little rain must fall

I'm on a train at Victoria station. That's the good news. It's not the train I want to be on admittedly but it is a train. It is going vaguely south and I did manage to get a seat. I have offered to give it up to a pregnant woman but she looked at me a bit funny and now I'm not so sure she's actually pregnant. It has taken me nearly two hours to get here after leaving the office. Did I stop en route for a beer? No, though I wish that I had. So, what cataclysmic problem has befallen the great british transport system to result in a two hour journey so far? Earthquake? Tube strike? Locusts? No. The sorry truth is that it rained. OK, to be fair it rained really quite hard for nearly twenty minutes. And just like we have that one day a year when it snows more than we expected, once a year it rains a lot too. Victoria underground flooded. Victoria station flooded. No trains, buses and taxis full, roads blocked with people and everything grinds to a very soggy halt.

In an effort to take the positives from what promises to be a four hour commute home (the same it would take me to fly to sunny Tenerife) I thought I would reflect on what this experience has taught me so far.

Disasters (big and small) just have a habit of turning up when you least expect them. The trick is to be prepared to deal with something you weren't expecting. That means having flexibility in your approach. And being prepared for some quick thinking.

Prepare, prepare, prepare and, crucially, expect not to be quite properly prepared. Practise your DR procedures not just by saying "let's try a restore of system x" but by saying "there's no power in the server room, AD is corrupt, the mobile phone network is saturated and there's a rail strike" and take it from there.

Remember what it feels like to be on the outside (of Victoria station in a puddle in the rain) and make sure you communicate. Even if there's no news, communicate. Tell people what the problem is, what's happening to fix it, when that might happen, and what they could do to help themselves in the meantime. It also helps a lot if someone somewhere looks like they're in charge. That helps to reassure people that you're not flustered, you're in control of the situation and working sensibly to get it resolved.

Put aside the why part of the question for later. It doesn't matter why it happened, for the moment all that matters is it did. You can do all the soul searching and "why didn't we think of that" -ting later.

And finally, when you have fixed it, when you've battled outlandish odds and rebuilt the data centre from scratch using bits of twig and a ZX Spectrum, don't expect any applause. Yes you've done a great job but doing your job and doing it well is what your employer pays you to do. Instead expect people to be angry. Their main reaction is likely to be "why did it take so long to fix and what idiot put it together so badly in the first place?" So chin up, make sure you work out how to learn from it and move on.

My train is moving now and I am finally travelling homewards. Am I grateful? Not really. I just want to get my hands on the person who designed the roof of Victoria station.

How to write bad software

Aloha!

I was about to introduce this, my first ever real blog but in simply attempting to type "Aloha!" I have made a discovery! I have discovered that the # key on my keyboard is located on the right of my right shift key. And that means that every other time I try to use the shift key I end up hitting the # key as well as, or instead of, shift. So that "Aloha" came out "Aloha#1". Oddly I'm not sure which one I prefer more. In the spirit of keyboard/user error therefore I would like to wish you all an Aloha#2.

So why can't IT be better? Well, hell, of course it can be better. But why isn't it? Let's start with software.

Luckily there are loads of very clever and very creative people making amazing and exciting software. Some of the software is so good you might even get to see it or use it. But there is plenty of good software and good ideas that just don't make it, just don't do it in time, sometimes for the best of reasons and sometimes for all the wrong reasons. By all means invest a few of your hard earned cash in a copy of Dreaming in Code and see what Scott Rosenberg has to say on the subject. And let me be clear - that's the situation for the really good software.

The sad news is that there are many more people making bad software than there are people making good software. Why? Because it's just harder to make good software. You have to really make an effort with it. You have to really really try to get it right and make it the best it can be; you have to take care, time and effort to iron out all the bugs in it; you have to write, build and design it so that's it's robust, easy to grow and change; you have to understand what your users want, how they work, which features make sense and which will never get used; and you have to make it a memorable, compelling and fulfilling experience. Are you prepared to invest the time, energy and commitment you need to do that?

Maybe you are and if so, then fantastic, you have a real chance of making great software. But maybe you're not prepared to. Or maybe the guy who pays your salary isn't prepared to. Or maybe the lady sponsoring the project doesn't want the costs too high. And so, inevitably, corners get cut. And for every corner you cut you pay the price in terms of the quality of your software. Cut too many corners and the square you set out to build ends up a circle. And what happens when you build bad software? The guy with the budget might thank you - at first. The users might be glad their software got to them real quick - at first. Your boss might give you a big pat on the back and throw you a party. But don't get too used to the accolades. Because that baby is going to fail. It'll fall flat on its face. It won't quite do what you intended. It won't quite be what your users wanted. It will have bugs. It will fall over. It will cause untold problems for your support teams. You will have to patch it. Then you will have to do a whole new release. At about that point you'll discover that you're going to need to totally re-write it because what you did the first time is horribly compromised. So now you're starting again. Which means now you have a choice. Will you cut all those corners this time?

Incredibly many people seem to do exactly that, falling repeatedly into the same old mistakes and entering what I'm going to term the Never Ending Cycle of Software Despondency.

Don't do it! Use all powers at your disposal to educate the decision makers around you and prevent your piece of software following so many others down this path. It's like the old truism around software testing, where every minute of testing you do while coding time saves you 100 minutes post release. That applies to every bit of effort that you put into doing all the parts of your software development the right way. Can you convince them? I think you have to try.

Aloha #3