Engineering systems for consistency and impact

Published on January 03, 2022
This is a foundational series article. Read more here

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.

"impact map"
"impact map"

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!

Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building and supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My Universal DevShell tooling will save you 30+ hours of configuring your Windows or Mac dev environment with all the best, modern shell and dev tools.

Get DevShell here: ✨ https://devshell.darraghoriordan.com


Read more articles like this one...

List of article summaries

#engineering

Building an AI generated game with Stable Diffusion and data from Wikipedia

Last week I released a game called Doodle:ai.

In the game you’re shown AI generated images and you have to guess the Wikipedia topic it used to create the game.

#engineering

Easiest way to optimise images for web

Here is how I optimise all pngs and jpgs in a folder for publishing to the web.

#developer-experience

Start tracking DORA metrics for your team in just 15 minutes with Apache Dev Lake

DORA (DevOps Research and Assessment) metrics are an excellent way for engineering organisations to measure and improve their performance.

Up until now, monitoring the DORA metrics across Github, Jira, Azure Devops etc required custom tooling or a tedious manual process.

With Apache Dev Lake you can get beautiful reporting for DORA metrics on your local machine in as little as 15 minutes (honestly!).

From Google Sheets to Grafana
From Google Sheets to Grafana

#engineering

A summary of NDC Sydney 2022 Developer Conference

I attended my first in-person conference for more than 3 years last week! NDC is one of the more well-known developer conferences in Australia and New Zealand. It’s a 5 day conference with 3 days of talks and 2 days of workshops.

There’s so much to learn across all the streams so I try to take notes for each of the talks to quickly reference them later. This post contains all my notes. I’ll add the relevant videos to talks later if they’re released.

A reminder that these notes are just my notes. They’re paraphrased and summarised from what the speaker actually said. Each speakers would have provided must more clarity and went into more detail during their pressos!

Comments