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.

Calming 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.

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.