John's Adventures

Archive for February 2004

Full Product Lifecycle

I’ve had a few job interviews lately and as is usual in interviews a fair portion of time has been directed at going over my professional career. I’ve spent most of my time and the most interesting part of that career at my last job. Going over the four years and a half years (punctuated with a six month gap where I left to pursue other interests) reminded me of how much I’d learned, how much I’d experienced and how it has prepared me for anything the world of software engineering can throw at me. It’s a good story so I thought I’d tell it now for posterity – it was a once-in-a-lifetime trip.

New Beginnings

Back in 1999 I left Scotland after working for a University for a couple of years and entered the real world. I joined a company that had been a start-up spun out of the University of Manchester and had just been acquired by a large American company. The product was an optical inspection system for use in the electronics industry. By using Statistical Appearance Modelling (SAM) the underlying software could be trained to recognise what an electronic component looked like and therefore by looking at an image of a Printed Circuit Board (PCB) on a production line it could spot any mistakes and flag them so that they could be fixed before the PCB went further down the line. The beauty of the machine was that it consisted of two banks of simple video cameras that didn’t have to be precision-placed, the software was clever enough to make sense of what it saw and measure component locations very accurately and repeatably. It also meant the machine could be easily and cheaply manufactured. So myself and two other developers were hired to help get this product to market.

We fixed a few bugs, put the product out and made a million. Right? Wrong.

A treeCalming The Waves

The first thing I and my new other new recruits had to do was port the existing software from UNIX to Windows NT. In fact I started a month before the other guys and my first task was to set up a Visual Studio environment for the software which was around 700,000 lines of code! Talk about in at the deep end. After a fair bit of pain we managed to get the software to build on Windows but getting it to work, not crash, draw the GUI correctly and a million other niggly things meant we had to spend a considerable length of time before we had anything that could go onto a customer site.

We had to stabilise the software and get our release process under control. We were at times guilty of hastily firing out releases to potential customers and shooting ourselves in the foot when it all went wrong. We were in start-up mode and we needed to slow things down and get more organised. It was a slow and at times difficult process but by sending people out to developer conferences for ideas, reading books on lifecycle management, trying to score well on the Joel Test (as well as reading loads of his articles) and buying some good tools we managed to create a process that made our lives easier. Eventually we managed to score 10/12 which we were happy with.

Decisions Decisions

But what the books and courses don’t tell you is how to make judgement calls. You’ve got a customer demanding a particular feature before they’ll sign a purchase order. You’re working towards a release that has some other fixes and features some other customer has demanded. All the while you’re looking further ahead to where you want the software to be in six months time. So what do you do hotshot? Do you just put the fix into the main trunk, build an installer and send it to the customer? Do you go back to your most recent stable release, branch and add the fix, then do some testing and send it out? Do you hold off for your next service release and roll it into that? Wait a minute, rewind. Have you figured out how high-impact the fix is and how likely it is to destabilise the software? How risky is it? Is there a better way to give them what they want? Do they really know what they want? If we do this will they really buy? Oh the questions.

And while we’re at it, how many branches of development do you want to have going on at one time? How do you decide what fixes and features are going into upcoming releases? In fact, how do you decide what your product needs to succeed?

To be involved in the decision making process and realise that writing software isn’t all about tight algorithms or clever use of design patterns is eye-opening. We were all plugged into the fact that at the end of the day we had to sell kit and therefore make money. That was the bottom line and every decision we had to take was directed towards that goal, not mere intellectual pursuits. So if you were going to hold up a major release for a service release to a key customer to put new functionality into the rework interface, it had to make financial sense to do so.

Smooth Operators

Of course as time passed and we learned by mistakes, we got better at the decision making process and having procedures and systems in place made our lives easier (no signing documents in triplicate to change a line of code for us). Eventually we didn’t even have to think about it, it was second nature. When customer demands would come in or our technical director would have a brilliant idea, it all went into the system and we’d calmly put it all into our roadmap.

In fact, early on we used a piece of defect tracking software that became the centre of our lives. TestTrack Pro was that tool. We began by putting only defects into it and managing the fixing of bugs with it. But soon we put everything into it – specs for new features, refactoring ideas we’d have, literally anything that we wanted to do. Then when it came time to dish work out, that piece could be assigned to the relevant person. When it was done then they would mark it as fixed and release it to testing. Likewise when deciding what would go into a release, you could look through all the outstanding work in one place and specify which release it should go into. Simple. Being competitive people we could always keep track of who had fixed the most bugs and try and get one-up on everybody else.

The Proof Of The Pudding

We put in a hell of a lot of hard work with many good times and many bad times (I’ll never forget when we started on a bug fixing run where there were literally hundreds of bugs we had to fix before release – we got through them though in the end although at times it seemed we’d never finish). We finally managed to produce a very competitive product that actually did exactly what it said it was going to do. The proof is that despite closing down our office – effectively ending development on the product – it continues to sell to a market that demands to see a product roadmap before buying.

A street

For me it was a four and a half year voyage from start-up company with the raw materials in place to creating a world-beating product. For others who were there from day one it was a seven year project from having an idea, securing funding, creating a viable product and selling it to a company before going on to having a world-beating product. At the end of the day it was mission accomplished. We did it and learned so much.

From a personal point of view I had a chance to do it all. Most people only experience small parts of a product’s lifecycle but I was lucky enough to see it from start to finish – and right up close. I got to be a tester, a configuration manager, a GUI expert, a decision maker, a designer, a continuation engineer, a terrible table football player and of course a software developer. And I loved it (more so after I’d left for 6 months and grown up before coming back for my final stint).

The Things You Never Lose

There are several things I’ll take away with me from the last four and a half years. One is friends. I have no doubt that in 20 years time I’ll still be in contact with most of the guys I worked with (unless I or they are dead of course). I think that when you work that closely with people for so long you either end up hating them or being friends with them – with me it’s usually the latter.

Next, I’ll take the working practices with me. We had a pretty well organised system that was both scaleable and was very successful for us, as well as making our lives easier rather than harder (not a Methodology with a capital ‘M’). I know for a fact that most software companies are terrible at managing the development process and I know one way that works.

I know that the way I’ve learned to approach problems – whether it be a random crash that can happen once every five minutes or five days (I must write about that one some time), a tricky piece of development, trying to design a way to solve a user’s problem or learning a new technology – seems to work. I’ve never come up against a problem I’ve not been able to solve and I don’t see why I’ll find one now. Basically, I have confidence in my abilities (no, I didn’t say arrogance, okay?).

I’ll always remember that at the end of the day the decisions you make when you develop software need to make sense from a business point of view. After all, the business reason for writing software is to make money. It’s an important lesson that can be all-too-easily forgotten when your head is buried in code.

And finally, I’ll always remember that I can never learn everything. Working with such a good team demonstrated on a daily basis that no matter how good I thought I was at something, there’s always room for improvement. And if you don’t strive to improve and instead stagnate, you’re dead in this business.

Two Years And Still Running

I just noticed that exactly two years ago to this day I published my first entry on this site. It was a short description of the fact that I’m Scottish and I live in Yorkshire. When I wrote the article I didn’t really know what I wanted to do with this site. I’d read Joel On Software and liked the format of his site and thought it would be an idea to create something similar so that people I knew who lived elsewhere could see what I was up to without having to send them e-mails from time to time. I guess it was laziness, experimenting with the web medium (I used to be a web designer and had left that firmly in the past) and perhaps a little bit of exhibitionism. Plus I’d never managed to write a diary longer than a few days so it was a challenge.

Well, much to my own surprise I haven’t become bored with the whole idea and given it up. I don’t know what you – the reader – think of the site but from a personal point of view it’s been interesting to write about things on my mind and document some of the good and bad things that I’ve experienced in the last two years. If you were to ask me why I still write this site I’d struggle to give you a really convincing reason, it’s just become a part of my life and I accept that and don’t feel the need to really understand why.

Anyway, I just wanted to congratulate myself on sticking with it through thick and thin. I may just carry things on like this for the next two years. I might write more technical articles. I might even start posting darker, more negative articles rather than just deleting them. Or I might get sick of it all and wind it up like I thought I’d do in the first place. Comments and suggestions are always welcome. Happy birthday to John’s Adventures!

Learning My Lines

I must confess I’m a serial singer. I seldom listen to the radio and never in the car. The reason is simple. I like to sing along to music, and it just so happens that the music I like is the kind I can sing along to – the radio just tends to play manufactured rubbish these days. This started many years ago when my friend Scott (also a serial singer) explained that singing loudly when you’re doing a long drive at 2am from some far-flung part of the country is a great way to stay awake – much more effective than coffee. I tried it (the singing, not the coffee) and he was right – I’ve stuck to it ever since.

The end result is that I can sing my way from start to finish through almost every album I own (and I have rather a lot). This means that as soon as I hear a line from a song I know on the radio (I do listen to it sometimes, like when someone else is driving) I can instantly join in and sing the rest of it (much to the annoyance of the driver). But when I buy a new album I have to learn all the lines to all the songs and it takes a bit of time. This is the reason that I never buy more than two CDs at once or else I’ll get overloaded with music and that’s not good.

Take, as a random example, the new Belle and Sebastian album I mentioned before. It’s fantastic and a great return to form. There are plenty of tunes I want to sing along to and I’m gradually getting there. Here’s how I do it (you may have a better technique and if so let me know). I’ll start by playing the album through several times on repeat. I’ll play it in the house if there’s nothing on TV, I’ll play it in my garage while working out, I’ll play it in the car when I go to the shops and pretty soon it’ll be playing in my head when I’m trying to go to sleep at night.

This initial phase will tend to force the choruses into my memory so I’ll be able to sing along to those parts of the song (I’ll also inevitably learn the backing singer’s lines but I always wanted to be the lead singer so that will go out the window). I can usually use this method of playing the album over and over again and eventually the words will sink in (and then 5 years later I’ll discover that I’ve been mis-singing the line “maybe not baby, maybe not baby” as “maybe now baby, maybe now baby” and feel like an idiot).

However sometimes my patience to learn the words this way will grow too thin – usually because it’s such a good album I want to be exercising my incredible vocal range to its’ fullest. When this happens I have to resort to the dreaded CD inlay. Quite often the lyrics are neatly printed there for you and you can sing along to them. Although in the case of Belle and Sebastian they seem to make a good job of deliberately printing the wrong lyrics – for instance how can “has he ever seen Dundee?” be printed as “north of Scotland has he seen?” for Seymour Stein? I ask you…

But after a while of reading the lyrics I’ll go back to the repeat play method and suddenly before I know it I’ll have the words lodged in my head and the best thing is that they’ll stay there forever! Well, until I go senile / am killed / get part of my brain blown out and live like the lead in Memento. So good is my memory for useless information that I memorised pi to 50 decimal places when I was at school and I can still remember them to this day! Pi, for those who can’t remember, is the circumference divided by the diameter of a circle and is an endlessly long number – it’s slightly over 3. It’s no wonder I don’t have women flocking all over me…

Having said that, I don’t tend to keep that much genuinely useful information in my head if it can be easily found. For instance, I don’t memorise class libraries and methods when writing software, even though I’ve been using the same ones for years. The way I see it I can look it up in 2 seconds on MSDN so why waste precious neurons on it when I can task them with remembering the fifth verse of I’m A Cuckoo. It’s all a question of priorities really. Or maybe I should have just tried the coffee technique instead…

The Soundtrack To My 20s

My Belle and Sebastian CDsIf you were to make a film about my 20′s (maybe when I’m long dead and you want to chart my rise to power) there’s one thing I can tell you right now to ensure a certain degree of realism and accuracy. And that would be what music to play throughout. It would be the collected works of Belle and Sebastian.

They’re a band from my home country of Scotland and I can still remember the first time I heard them. It was from my personal music advisor – my brother. He had a copy of the album The Boy With The Arab Strap and was playing the track Dirty Dream Number Two and I was instantly hooked. I bought my own copy of the album, then a copy of the previous two albums, then all the CD singles (they’re always EPs with more tunes on them) and then I kept a watchful eye out for any new releases. I’ve played all the CDs to death but I still love them and whenever I change the CDs in my car I almost always have one by Belle and Sebastian in there.

The thing I love most about Belle and Sebastian is that all of their tunes are the sort you find yourself walking along a road humming the song to. They’re amazingly catchy – if you’ve seen the UK sitcom Teachers you’ll have heard the title track to The Boy With The Arab Strap and must agree how once you’ve heard it you can’t get it out of your head. They’re all like that! Each one feels like a journey rather than just a song – you feel like you’re actually going somewhere throughout. They can seem quite twee while being both uplifting and depressing at the same time with some clever lyrics and the old trick of negative lyrics with positive music.

Anyway, I was flicking through the music channels on TV last night and came upon this song. I liked the sound of it and watched the video. The premise was a guy who’s an athlete and is getting pulled in all directions by his coach, his girlfriend and the band he’s in. They all want a piece of him and he just seems to be caught in the middle bouncing all over the place. I found the song really catchy and watched intently to see who it was by. And guess what? It’s by Belle and Sebastian and I didn’t even twig! A quick call to my brother to say that they had a new single revealed that in fact they’d released an album back in October while I was in the process of going to New Zealand / losing my job / moving into a new house. Five minutes later and I’d ordered it from Amazon – it’s called Dear Catastrophe Waitress.

I still remember driving around to job interviews back in 1999 listening to The Boy With The Arab Strap over and over (and singing all the way). So here I am five years later and I’m going to be doing exactly the same thing with their latest work – how’s that for symmetry? I’ve only got 7 months left of my twenties which is plenty time to play the new album to death…