Engineering systems for consistency and impact

Published on January 03, 2022 - Tagged: #engineering #management

This is a foundational series article. Read more here

Follow me on twitter for more posts like this

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 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 DevShell tooling will save you 30+ hours configuring your dev environment with all the best modern tools. Get it here

https://darraghoriordan.gumroad.com/l/devshell


Read more articles like this one...

List of article summaries

#engineering

PostgreSQL and typeorm - Caching

With most web applications you can drastically increase performance by using caching for data that’s frequently read across network boundaries. This lesson will explore some common caching techniques, you’ll learn how some common tools and libraries provide caching for us.

While caching helps with performance it can also cause some surprises and bugs in applications and i’ll discuss some of those too.

#engineering

How to run Monica personal CRM on Dokku

I left my home country right after university and I worked and lived in a few countries since then. I’ve met lots of amazing people but I’ve always struggled to remember contact details and important dates for everyone.

#engineering

Find 20% of missing site traffic with plausible analytics and some proxying

Google Analytics (GA) has been a force in web site metrics since 2005. The metrics have always been incredibly useful but it’s a “free” product so you pay for it by providing all your site data to Google for tracking and advertising.

With Google Analytics your metrics are tightly coupled with tracking and advertising so when ad-blockers kick in to block tracking they also block your metrics!

The good news is that this is all fixable!

#engineering

Open Telemetry in NestJs (and React)

Open Telemetry is good enough to use in production projects now and most cloud providers and telemetry services have integrated open telemetry into their products.