We’ve always followed a set of software engineering principles here at Engage and we thought it was time to share these so that everyone can see our approach to technical problem solving. The below principles are what we endeavour to stick to on every project we build.
All code should be easy to test using automation. Ideally this should involve a “test first” approach to writing software. This means that a test should be written first before any other code is written. Subsequent code should be measured against a test to ensure that it satisfies the requirements. This approach results in better code quality and scalability.
All software should be written with maintainability in mind. This means that a specific approach or solution should be avoided if it is likely to introduce issues in the future. Remember that you read more code than you write. Imagine when you are writing code that you will need to explain what the code is doing in the future. This means that things like descriptive variable names, and functions that do just one thing are required as they are self documenting.
It should be noted that this principle needs to be balanced against the below MVP principle.
Minimum viable product (MVP)
This means you should only implement a feature when you actually need it, not because you think you will need it. It is better for a solution to do the least it can do really well rather than have it do everything but not quite as well.
Context is king
Before you begin implementing any solutions, a good understanding of any wider context should be acquired first. The problem and potential solution should be thought through and planned at a high level first, taking account of the needs of the project, client, budget and any other factors that might affect the outcome.
Don’t repeat yourself
This principle speaks for itself, but code that needs to run in multiple places should be abstracted appropriately so that it can be accessed in multiple places. Code should never be copied, pasted and repeated in the application i.e. copying a method from one class to another.
Follow SOLID principles
SOLID principles should be followed when writing code i.e. Single Responsibility Principle. These principles are widely promoted in the industry, and are intended to make software designs more understandable, flexible and maintainable.
Beware tunnel vision
It’s unlikely that you’ll be the person using the software you have written. It’s easy to get tunnel vision when working on a solution to a problem, and regular check-ins with both peers and colleagues who aren’t programmers is often beneficial.
This means that any errors should immediately, and obviously, break the application. The Fail fast principle is designed to prevent problems with code from being hidden away, only to cause more problems later on.
An example of this is not writing deeply nested “Christmas tree code”, but instead inverting “if” statements and returning early if the condition is not met. This also has the nice side effect of creating a single path through functions.
Better than you found it
Ideally you should leave code in a better state than you found it in. A “band aid” solution whilst quick to implement, will almost always require exponential effort when working with it again in the future. Where possible, try to improve the code around a problem (without rewriting the whole thing), in order to improve maintainability.
When building software, ideally decisions should be made primarily with the end user in mind. This is often tricky to do due to the needs of the client or project, but where this isn’t possible, efforts should be made to educate stakeholders about the best approach to a problem.
We’ve always found that following these principles improves not only the quality of the projects we produce, but also increases scalability. We’re sure there are other principles in addition to those mentioned above too, but these are the ones that have always worked the best for us and our clients.
It can be tricky in the agency world to always follow every principle, with various factors getting in the way, but achieving a gold standard is always our aim.