Engineering systems for consistency and impact

Your most impactful engineering is done before you write any code.

It's important to have some systems around how you approach problems to make sure you're consistent every time.

These are some of the techniques I use to make sure I'm covering as many angles as possible when doing my pre-coding engineering.

Pre-engineering engineering

These are some questions I use to check my knowledge of a problem before I think about specific technical solutions

• Do we understand the problem? Does it even need code?
• Is there a hard launch date? When will we start communicating the change
• What documentation will be needed?
• How will we measure success? When will we measure success?
• When will the feature or product be revisited and reviewed for success?
• Will we need UX and UI? How much heads up will this need?
• How will this change impact other important services?
• Are there any regulations that need to be followed here? Are there any legal requirements?
• What assumptions have been made so far?
• Does the system need to fall back to a useful state?
• What are the risks? Are we dependent on any third party teams or services?
• What kind of extra resources will we need to run this in production? Will it need new infrastructure?

How to evangelise an engineering change to company leaders

As an engineer you will have to sell a proposal upwards to your leaders. These folks are short on time so be concise. Follow this as a guide

1. Start with the conclusion.
2. What’s the problem you’re solving and why does it matter?
3. What are we currently doing about this problem?
4. What are our competitors or industry leaders doing?
5. What’s your solution?
6. What's the cost?
7. What’s the cost of inaction?
8. The action items

(This list isn't mine - I think it came from a presentation somewhere. I didn't note who created it so let me know if you know who it should be attributed to!)

How to evangelise an engineering change to other engineers

If you're introducing a new platform or a new process to an engineering team you should plan some systemic evangelisation to make it stick. This will take multiple sessions! We wouldn't have successful products without marketing them and we won't have successful change without evangelising it.

• Use Lunch & Learns to show how, use Show and Tells to highlight successes
• Embed yourself in a team to help integrate your new thing
• Hackathons to encourage platform usage

Solution introspection

The best code is no code at all. Run through this list for any large piece of work as a quick sense-check that you're not making a big mistake in your engineering proposal before writing any code.

• The existing solution is too bad. We have to rewrite it from scratch.
• This software is too unmanageable. Adding operational complexity will help.
• This problem has never been seen before. We have to use the bleeding edge to solve it.
• Adding network hops to the system will make it faster somehow.
• Running systems and open source projects are the same and should be built the same way.
• I can add value to this command line tool by writing my own wrapper for it.
• The programming tasks represent the majority of the effort.
• Functional tests!!
• We can just deploy the code with our version control tool.
• I want logical decoupling, therefore I must have physical separation.
• Bureaucracy solves everything.
• Bureaucracy solves nothing.
• These two teams use the same noun, so they should use the same code.

(This list isn't mine - I think it came from an article somewhere. I didn't note who created it so let me know if you know who it should be attributed to!)

Start from the impact

Impact mapping is used to collaboratively set business goals. You can start from the behavioural change that you want to see (the WHY) and work backwards to find the steps you have to take to get there.

Impact mapping was developed for UX mock-ups but it works just as well for engineering impacts. Impact mapping works nicely with one of my favourite planning techniques - what, how, who, why, when.

In this case you start with WHY and use that to fill in all the other pieces in a structured way - WHY do we need it? -> WHO will be needed -> HOW you could impact the WHY => WHAT steps you need to take.

Map solutions to enterprise integration patterns

This is closer to coding than the other topics in this article but still important. Once you have a high-level rough solution in mind you should try mapping it to enterprise integration patterns by Gregor Hohpe and Bobby Woolf.

Just like in software patterns, the enterprise patterns provide us a language to discuss common approaches and solutions. By normalising the language we can increase the speed that our proposals can be understood.

The enterprise integration patterns are described here: https://www.enterpriseintegrationpatterns.com/patterns/messaging/

Summary

Most of the engineering work you do is not coding. You're gathering information, synthesising it, thinking about it, packaging it, proposing solutions.

Consistency via systems helps ensure your repeated success and prevents regressions in outcomes. Start creating your own list today!

Let me know if there are any systems you use that I haven't listed here! I'm always keen to learn new skills!