Engineering Principles

Over the last 15 or so years in my time as a developer I have written, reviewed and released countless lines of code. One of the things I have always done is to always try and improve my code going forward and adapting to new practices. 

The problem I have always encountered is that everyone writes code in different ways sometimes of good quality sometimes not so much. Poor quality code is and has been the bane of my life, I have forever had heated debates with developers of code quality. 

A few months ago I was watching a video by Bob Martin about some principles that he had developed over the years, if you haven’t watched his videos I would highly recommend them.

I realised that maybe poor code quality isn’t just due to “bad” software engineers but more to do with the fact that no company I have ever worked for has had a set of principles that developers should abide by. 

Think about it most companies always have a set of company principles or a motto which they abide by! So why can't we as engineers have a set of principles which we abide by?

To that end, I decided to come up with some principles of my own inspired by Bob Martin, which I hope to implement with any development teams that I will work with going forward.

1. Always produce your best work and ensure code quality is a feature

Now yes, of course, every developer produces their best work, right? Well, there are a few things that you can do to ensure that this is always the case:

Ensure Code Quality is NOT an afterthought

Always think about how best to approach fixing the issue, write the test first and ensure that you are not making things worse by rushing the implementation.

Always write code that makes sense to someone else ideally a non-technical person if they can read your code and it makes sense to them, you are on to a winner. 

Never code to make it work

Coding to make things work leads to poor quality code, 

Yes sometimes deadlines and pressure come into play and it will have to be fixed quickly if so then ensure that you:

Never allow bad code to accumulate

Bad code accumulates because no one has been bothered to go and fix it. If you have had to rush your implementation (you shouldn’t but if you have) then go back and fix it afterwards. This will minimise technical debt and save you & your team pain going forward.

2. Always have a repeatable proof that the code works as expected

One question I have asked myself is:

An executive of any company is without fail always interested in how much revenue has been generated in a given quarter or if the company is still liquid, should they also be asking “Where is the proof that our key customer solutions are working as expected?”

What we are talking about here is good quality and high coverage of unit tests, your proof to ensure that what you have written works as expected.

How many times have we heard about a banking system going down? Good quality unit testing would go some way to try to reduce this however it's important to note that some banks are still using old green screen mainframes which makes unit testing difficult. 

The best way to do this is to follow Behaviour Driven Development - This will mean that your unit tests will be based around scenarios and written in such a way that makes sense to others - namely non-technical people. If your tests can be read and understood by others you are onto a winner.

3. Encourage and make small frequent releases

Making small releases frequently ensures that not only can you deliver features quickly but also try and get feedback quickly allowing you to ensure that the features you are delivering is not just of the highest quality but can also have the highest impact on the business and can continually be improved.

Another reason for making small changes is so that we don’t impede others, how many times has a developer, tester been unable to move forward due to something not been completed in time.

4. Always look to improve productivity

Branching and GIT  

This may seem obvious but you might be surprised how many developers I have come across you don’t know how to use GIT to a high standard or companies who don’t have a branching strategy.

So learn to use GIT properly maybe by having an internal training course and assessment and always enforce a branching strategy

Automate Everything

Automation helps to ensure that things are kept consistent throughout the SDLC, with microservices being adopted more and more, systems are reliant on more and more services. The last thing you want is to have to remember how different services are configured and to do this manually.

Automating everything from your deployments, security checks and infrastructure will take time in the short term but will save you hours if not days later on.

Continuous Improvement

Spend time trying to improve the code this will increase future productivity also try and improve your processes. If you have had to rush some code into production for any reason (you shouldn’t but it does happen) then ensure the team knows that it needs to be revisited in the next sprint.

Conduct code reviews to ensure that bad code never makes it into production.

5. Encourage Pair Programming to ensure that is always suitable cover

How many times have you heard the following:

“Sorry the developer is on holiday, we will need to wait until they come back”

Pair programming is a great way to build a good relationship with your peers, the best teams I have worked with involved the entire team have a great relationship with each other. This can be achieved by having a least one user story in a sprint which got 2 developers working together.

Not only does it help build good relationships within a team but it ensures that the above question is a thing of the past and more importantly keeps momentum in the team going.

6. Always look to improve

The worst thing you can do today’s world is to stand still, look at:

• Doing Kata Challenges
• Watching videos on new technologies
• Building a POC 

This is always a challenge especially with how busy teams can get but giving developers time to improve can be overstated - Doing so will reap huge benefits for the business going forward.

 7. Don’t Repeat Yourself

Developers are familiar with the DRY principle, applying this a  higher level will ensure productivity is kept as high as possible.

How many times have you written code to interact with Kafka or a Redis Cache? 

Writing these as reusable components will speed development up in the future if possible write these using an API first approach and try open-sourcing it - It will attract feedback from the community allowing them to improve in ways you didn't think possible.

 8. Security is everyone’s responsibility

Security should no longer be just the responsibility of the security team, it’s the responsibility of everyone from developers to testers to platform engineers and all should contribute.

In an Agile world, we have to shift security as left as much as possible in the SDLC this will result in security holes being identified much earlier in the life cycle and if there are identified earlier they can be fixed quickly. 

Open source is becoming more and more popular, developers are writing less code and “borrowing” code from third party public repositories such as GitHub, NuGet, NPM etc. and integrating these into their application.

It’s important to know these libraries are safe to use in regulated environments such as financial services. 

Companies such as Veracode and Whitesource integrate into the IDE helping to identify insecure code or vulnerable open source libraries, using these will ensure that security holes are caught as early as possible in the SDLC.

Conclusion

We live in a world now where we are increasingly reliant on technology, organisations that traditionally saw IT as overhead are having to restructure to ensure that IT is now an integral part of them getting a competitive advantage - The CIO’s place is now on the board not in the basement.

Whilst this is great for engineering teams and people like myself, not having a set of principles to abide by will result in poor quality engineering and technical debt. 

In a world where we need to deliver quickly, get feedback and iterate to maintain the advantage, having a set of principles will go a long way to ensure that organisations are delivering not just high-quality products but high-quality products underpinned by excellent engineering.