Simplifying technical designs

Someone recently shared with me that they really appreciate my ability to take a massive, complex problem or design and find creative ways to simplify it, making it easier and faster to build and reducing the overall maintenance costs and risks.

As often happens with me, I hadn't actually thought I had that skill or that it was anything special...

Anyway, I thought I'd share a few tools in my toolbox that I use to try and bring problems down to a reasonable, hopefully achievable size. And who knows, perhaps these can be useful for you...

Clarify and hone requirements

First of all, do you have a clear sense of what problem you're trying to solve? And if so, have you written them down, gotten them reviewed, and gotten alignment with your stakeholders and the development team?

That in itself can be incredibly effective at achieving clarity and focus and potentially simplifying the solution.

Look for requirements that can be dropped or modified

Often intractable design problems can be "unlocked" by loosening or dropping requirements.

For example, maybe it's ok if a small percentage of requests to fail as long as they can be retried.

Or maybe the price or availability on a search page can be stale, as long as they are correct and up to date when you go to the detail page and are ready to buy.

Maybe we don't need that ...

A common thing I see is a design that takes on too much all at once, or adds too much optionality.

I know we could implement both GraphQL and REST interfaces. We could provide the ability to reconcile two browser tabs making changes to the same document.

But maybe we don't have to, at least to start.

Stick with the minimum of what we need to do to deliver value.

Look for enabling constraints

Sometimes if you create a constraint about what you can do with a system, it can really simplify your design.

For example, set a rule that you can only update entities by providing a full copy of the object, versus being able to provide just the fields that are being modified.

Or set a rule that you can only roll back a change by applying a new, compensating change, rather than try to implement some kind of undo functionality.

But what about...

As engineers we are good at thinking about all the possible wacky edge cases that can happen.

If a user starts creating a calendar entry in Germany but then gets on a plane and then tries to finish it in New York, what happens? Hm, ok, but maybe we don't need to worry about that just yet.

As long as the general design looks good, we can set aside the edge cases.

I once heard someone say that in some cases the best recovery strategy for an error is an apology.

Getting something working and delivered can be much more valuable than spending precious time trying to design a system that completely eliminates every potential edge case.

In my experience, the edge cases that do happen are always a complete surprise. We're not going to solve all of them anyway.

Giving yourself permission to relax and adapt

In general, just have a stance of giving yourself space to relax and be flexible.

Don't assume what is handed to you as requirements is immutable.

Don't get fixated on offering lots of options or solving every possible problem.

Give yourself space to find a way to tweak things and as a result have a much cleaner, easier to implement solution.