Behind the Scenes at Global-Roam

The time was half past seven in the evening.  It had been dark for an hour outside.  My stomach was empty, but I pressed on.  It was quiet in my study at home, the only activity - my feverish typing away at the keyboard.  I was almost done, joy within sight.

You see I was finishing the design specification for the latest iteration of ez2view.  This version was going to be the most ambitious version of our products yet and, after heavy internal debate, we had finally decided on where the product would go.  I spent the last week researching the technologies that we needed and designing the core structure of how the program would work.

Who am I?  My name is Stephen Hurn and I am the Product Manager of ez2view Australia and its companion product ez2update Australia.  I have been with global-roam since 2006 and have seen the company grow threefold over the last three years.  I will occasionally be pontificating on this blog about my times at global-roam.

Last night saw the completion of the most difficult task in developing a new product, or even a new version of a product - the design spec.  This, to me, is the most interesting and creative part of product development .  It is also the most important aspect of product development and the one that many companies repeatedly fail at.  It connects the requirements (essentially a wishlist of features) and implementation (the code).

Companies fail at writing good design documents for several reasons.  These are the three most common:

1)      Programmers like programming.  It is why programmers became programmers in the first place.  There is a great temptation to launch headfirst into code when working on a new version of a product.

2)      Time pressure.  Many developers feel that they do not have enough time to get their work done.  To take the time to write a good design document can feel like a huge waste.

3)      Management that just doesn’t “get it”.  All too often, poor management can make absurd demands of their developers.  Those demands may include moving the requirements every two weeks, placing unrealistic pressure on developers to be continuously coding (any company that pays by the line of code or volume of output is guilty of this) or simply over promising to clients.

All of these reasons for not writing specs are bogus.  Programmers who simply jump in and adopt the “cowboy” style of coding with no spec may feel like they are achieving, but in actual fact will produce code that is more poorly structured and undisciplined than coders who follow a spec.  The sheer amount of bugs that will be prevented by a good design document will more than make up for the immediate gratification of having a semi-functional program sooner.

A good spec will save time.  It might not feel like it when the developer is sitting there racking their brain trying to come up with a good structure for their code, but having a design document to focus development helps prevent dead ends and allows for an overall speedier process.

Management can be the biggest problem when it comes to developing software.  There is so many ways in which management can hurt or help the long term interests of a product.  Primarily though it is over promising to clients that is the usual sin of management.  Nobody is immune to this, not even Microsoft manages to ship all of their products on time with all of the features that were originally promised.   Unfortunately bad management is the hardest problem to solve.  A great manager though is worth their weight in platinum.

Fortunately for me (and the other developers at global-roam), we have good management that has encouraged us from the beginning to write good design documents for our products.  Of course, we are still human and the design documents we write are not perfect but having a plan of action allows us, as a company, to focus on the most important issues of design - making things work well.

Making things work for us means that we peer review product designs heavily.  The real advantages to this are several, but primarily it allows us to have objective eyes view our designs at a stage where changing a checkbox to a radio button takes one sentence on a page, instead of some code, some phone calls and long negotiations with IT contractors who do not even work for the same company as the people who use the software.  The cost of fixing problems at design time is exponentially less than fixing the same problem later down the track.

Over the next week, my design will be heavily reviewed.  Debate will rage, tempers will flare, sarcastic remarks will be made and changes will be made.  In the end though, we will have decided on the best design possible at this stage, with the knowledge and the tools available to us as a company.  In the end, the company exists for the clients and the clients are the ones who benefit the most from strong design processes.  I am just glad that it is so rewarding.

This entry was posted on Friday, April 24th, 2009 at 4:38 pm and is filed under Design, Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.