Implementation. “Just do it” vs “Do it properly”

In our previous post, one of a series on the different phases that a software development project goes through, we looked at the design stage. Now we focus on the third stage – implementation.

The story here, as far as Zircon is concerned, is not that we do anything particularly different or remarkable at this stage – we just do it extremely thoroughly, adhering strictly to best practice, to provide a top quality job.

What’s Involved at the Implementation Stage?

As we’ve said with each post in this series every project is different – and it’s true, once again, at the implementation stage.

With some projects it’s not exactly clear what the finished solution is going to look like, so the work at the requirements and design stages is quite high level, and not particularly well defined. This probably means that you have to employ an agile or iterative process, in which case there is more work involved at the implementation stage – there are more grey areas and so more surprises and challenges that need to be worked out.

With other projects, those that are safety related, for instance, the work at the requirements and design stages goes into considerably more detail.  By the time you get on to the implementation most of the questions have already been answered and the work can progress relatively smoothly and swiftly.

History Repeating Itself

In the early days of software development the design tended to be very detailed – it would go right down to a very low level, almost to the point of writing pseudocode.  This gave the programmer a very tight set of instructions and they would then simply translate these into the relevant language.

Over time developers moved away from this, and would tend to design at quite a high level.  However, when companies started to offshore the programming they had to revert to providing very detailed low level designs again – at which point you could argue that they might as well just do the whole job themselves!  For this reason we do all the coding and implementation in-house – for us, we don’t see any benefit to offshoring this work.

Coding Standards and Commenting

When creating code we follow certain recognised conventions and standards to ensure the highest structural quality and to provide consistency.  These standards cover things like file organisation, comments, naming conventions, programming practices, principles and so on.  By adhering to these standards we ensure the code is consistent, making it easy to read and maintain.

This is important if we, the client, or a third party, has to review the code, or go back and change something.  If it has all been done in a consistent way it’s easier and quicker to see what each bit does, how it works, and so on.   Using strict coding standards also prevents us from using certain constructs that may not be entirely safe and which may cause issues elsewhere in the system.

When you write a block of code it can sometimes be quite complex and hard to tell, just from looking at it, what process it performs.  In such instances it makes sense to write a comment alongside it, to identify the function.  This is for the benefits of others, and even for yourself when you revisit it – it just makes it easier for everyone to see at a glance what that line of code does.

However, like any other form of writing, there’s a skill to achieving clarity and accuracy so the meaning is expressed without any ambiguity.  As mentioned above, and for this reason, comments are covered by the coding standards – in other words when we write comments we do so following prescribed best practice to ensure they are meaningful and helpful.

For example, when the code includes variable names or a value, such as height or distance, it will not be clear from the code what the unit of measurement is – are we working in feet, inches, centimetres or even miles?!  A meaningless comment, in this instance, would be “distance” whereas “feet” would be meaningful.

Writing comments alongside your code takes time, and so does doing it in accordance with the standard, but it will save huge amounts of time and grief later – it’s one of those factors that separates high quality code from poor quality code.


There’s a variety of languages that we could use for a project but these are generally self-selecting – there will be certain characteristics of the job, such as performance, platform, licensing, and safety requirements, that mean a particular language is most appropriate.

For instance, many applications are Windows based, so these days we’d probably use C#, as that works with .net environment.  On some projects we also use a combination of languages – on a recent one we employed a mix of Python code, C code and C#.

The team here isn’t fluent in every language that has ever been created but we’re capable of working in everything that’s current.


Like all software developers we use a variety of different tools to assist us in the creation, debugging and maintenance processes.  These include source code editors, compilers, interpreters and profilers.

Just like hand tools that you might use for a DIY task at home they just allow you to do a better, neater and more professional job more swiftly and consistently. It is only when you have to go back and work in a language that’s not supported by a modern Integrated Development Environment (IDE) for instance that you realise how valuable they can be!

Version Control and Change Control

As you develop and maintain a software system you change it – change and version control is the process you use to log those changes and the different versions that are created as a result.  Essentially it’s a filing system and an audit trail that allows us to identify and track all the different versions we’ve created and issued.  If you don’t do this it’s easy to get confused, so it’s vital to have a logical and efficient system that is used consistently.

Code Reviews

We don’t just write code without checking it.  We use tools to perform static analysis – this just checks that the coding standards have been consistently applied throughout.  We also review the code in the context of the design to ensure we’ve done what we set out to do and that the code will perform the functions in the way we intended.

We’ll review the code internally, using our own team, then supply evidence of the review to the client.   On other projects the client will review it themselves, or ask an external organisation to conduct the review.  Sometimes a client will write code themselves, then ask us to review it as a stand-alone job.  Code reviews are especially important on safety related jobs, for the obvious reasons.


At the implementation stage we follow normal industry procedures – but the point is we adhere strictly to recognised best practice.  We don’t just merrily write reams of code any way we feel like it on that particular day.  We ensure everything is formatted correctly and that it consistently follows the right coding standards, we keep track of all the different changes and versions, we conduct thorough reviews, and we do all this rigorously.

The result is a quality job that is easier to fix, maintain and upgrade down the road – so time and money spent at this stage will save you huge amounts of both over the lifetime of the system.