Wick Technology Blog

As software engineer it feels so important to write code or microservices in a consistent way. This helps maintainability and understandability as other engineers work on different parts of the system, but is it actually holding back delivery of working features to users?

When a software system is constantly evolving it can feel strange to have inconsistent ways of doing things across the code base. But this is something that will always be the case. Changes come from new frameworks, new tools, updates of existing frameworks and new architectural patterns. It’s common to talk about business change - and that changes in requirements will always happen. However it may be less common to talk about, and be aware of, technical change.

You should expect the code you write to be replaced

This is my biggest mindset shift: I expect what I write to be replaced. I expect to be in a constant state of “migrating”. I expect new and better implementations or patterns to be found. I expect to never be finished at the “perfect” implementation.

This means when we’re re-architecting, or re-designing, or upgrading from legacy patterns, it’s not a big deal - it’s part of business as usual. It means I don’t hold on too tightly to the code I wrote because better ways of doing things will be found as we understand our customers and the business better.

Also I don’t expect to get to the end of evolving the architecture, I expect it always to be in constant improvement, which means it’s never finished.

Don’t prioritise creating a consistently designed system

This seems backwards but I believe you should prioritise building something that works first and then if technical changes/improvements come along, you can go back later and change things. When technical changes are needed, don’t spend time going through the whole system trying to upgrade everything at the same time, so the system is completely consistent. This is part of the advantage of component systems like React or microservice architectures - it allows you to evolve flexibly. For example, some React components can continue to use higher order components, as you upgrade just the components which are most used and changed, to hooks.

I’ve learnt to be ok with the fact the whole system will never be completely written in the same way - some services might use one framework, and other services a newer framework, some might follow an old way of design and some a new design system.

It could be easy to never finish anything if we prioritised design consistency, because as things change you need to go back and update all previous services and this work just gets bigger and bigger as the system evolves.

Conclusion

I’d encourage you to embrace constantly evolving systems, and allow yourself to evolve flexibly and where it’s most needed.

Written by Phil Hardwick