Engineering SLAs

As a developer you'll often be asked to explain why you have written certain pieces of code the way you have and some of this feedback may be critical in nature.

When your faced with this situation please don't use the justification "but it works".

There is so much more to software engineering then simply writing working code, if working is the only quality of code worth mentioning then I would wager it won't stay working for very long.

In order to qualify as an engineering discipline we should be aiming our sights a little higher and look for our code, and the systems we use to produce it, to have many more qualities then simply working.

Ability to Deploy Change

Software engineering probably exhibits the fastest rate of change of any engineering discipline.

A code base under active development by a large team may see thousands of changes being made to code daily.  For this reason the ability to accept change is an important property for a code base to have.

This may sound strange, surely any piece of code can be changed? Actually the ability for a code base to be changed, and not re-written, is something that can only be achieved via careful thought.

Many of the solid design principles, such as Single Responsibility, Open Closed and Dependency Inversion exist to promote this acceptance of change without having to throw away large portions of code whenever a new feature is requested.

But the ability to change or modify code is only part of the story, change that isn't deployed is largely a wasted effort, a code base must also demonstrate an ability to deployed easily and without fuss.

This is achieved architecturally via the use of patterns like micro-services but it also requires the confidence given by having well structured automated tests that can be relied upon to identify issues and potential defects.     

Ability to Determine Performance

We deploy code with a purpose in mind and our users expect it to perform that purpose with an acceptable level of performance.

Hearsay and rumour and not effective ways to measure performance, cold hearted metrics that can demonstrate what the code is doing and how well it is doing it must be thought about before deployment and continually measured and reported on.

This should create a feedback loop that when coupled with an effective ability to deploy change will accelerate your product to new heights.

Before the operation of software can be effectively measured it must be clear to everyone what each area of the code base does and how it does it. It must also be clear the reason certain events are generated and there importance to the overall success of the code that achieving its desired outcome. 

Ability to Demonstrate Security

If any single quality of code has been elevated in importance in recent years it is that it should be secure.

Any code deployed almost anywhere can expect to be the subject of inspection and attack, whether the intentions of the attackers are mischievous or criminal it is no longer acceptable for security to not be on the minds of developers at all times.

But security doesn't exist on paper or whiteboards, it exists when a system can demonstrate an ability to detect, repel and recover from an attack.

The ultimate manifestation of a code base that doesn't meet this criteria is one that relies on "Security through Obscurity", there are a lot of smart people out there trying to attack the code they find and you may find your secretes don't stay obscure for long once they turn their attention to your code.

Security must be demonstrated by a willingness to submit your code to deliberate attack.

There must also be an acceptance that sometimes security flaws will be uncovered that must be fixed, sometime they will be found by effective monitoring and once again when coupled with effective deployment of change this can ensure windows of opportunity for attackers are as small as possible and closed as soon as they are found.

The minimum that should be expected from any developer is code that fulfils its original purpose and can be said to be working.

Those that rise to the upper echelons of their profession don't stop when this minimum acceptable state is achieved, they instead realise that code must also demonstrate some other important properties.

In this way they elevate their art beyond the mere production of working code to an engineering discipline with all the rigour and attention to detail that is implied.