Engineering Maturity

Engineering maturity is a marker of strong preparation, depth of experience, and breadth of perspective.

My current and former coworkers know that I use three terms to characterize the level of engineering maturity:

• Consistency
• Systematicity
• Reproducibility

Let’s go through what I mean by each. I’ll bring examples from my own domain and would be glad to hear yours in the comments.

Consistency

Consistency is the ability to pick a suitable generalized solution for entire classes of problems.

Example

You’re building several (micro)services with a single team of developers. The services are interconnected and the developers know the domain well, so giving the responsibility to one team makes sense.

Instead of writing every service from scratch, you decide:

• whether you’ll go with a popular framework or write code using the standard library;
• whether there’ll be an IoC container, and if so which one fits your solution;
• how requests to the service will be processed, along with other decisions facing the team.

The answer to these questions is the microservice architecture pattern called Service Template. The service template is the foundation on which your solutions will be built. Which means:

• every team member will share the same understanding of the code;
• tasks across different services can be split among all team members, not just the experts in particular corners of the domain;
• developers won’t need to solve the same questions differently across different services; that reduces cognitive load, code review time, and “decision fatigue.”

Systematicity

Systematicity is the ability to maintain consistency as the product grows and evolves.

Example

The services in the previous example used the standard library to handle REST requests. There weren’t many endpoints and they were easy to maintain.

As the project grew, you realized that a more optimal solution would be to use a library specialized for REST.

Instead of leaving the old endpoints “as is” and using the chosen library only for new ones, you:

• update the service template, capturing the chosen solution in code;
• migrate every existing endpoint to that solution.

Now request handling for REST in your services is solved consistently and systematically.

Another example

In some legacy code, business scenarios might be handled directly in the controllers/handlers. Whether that was done out of ignorance, rejection of DDD, or to save time, we can’t say.

A systematic example here would be extracting all scenarios into separate services and committing to describing them only there.

Reproducibility

Reproducibility is the ability to carry the decisions you’ve made from product to product, repeating the expected result on a predictable timeline.

Example

After seeing your results, leadership extends your scope to several more projects and reinforces the team with new developers.

With prior experience to draw on, you reuse your time-tested practices to build new services, transferring know-how to the new team members and broadening and reinforcing the shared expertise.

A more down-to-earth example

In my previous posts you may have noticed that I place a lot of value on how easily experience can be transferred to coworkers. For example, when discussing local https setup¹, it mattered to me that the same set of steps could be easily automated and ported to my coworkers’ machines so that the result was the same — reproducible — for everyone.

I aimed for the same reproducible, portable result when configuring local DNS².

It’s worth recalling that, as part of solving the portability problem, I described my approach to containerizing tooling in a separate post³.

To finish, two more things.

First, many of you will ask: why does Service Template apply to a single team within a single direction? I’ve worked at different companies and on teams with different levels of engineering maturity. In some places, a template — or templates, in the various languages used at the company — really does apply to everyone. In other places, no one attaches importance to it, or simply doesn’t have the experience and expertise to.

Second, for these three terms — which I arrived at and formulated on my own — I want to thank N. V. Maksimov, who taught the information-technology course in my third (or was it second?) year. He’s probably the only teacher who significantly and positively influenced the development of my own engineering mindset.

I promise to dig into the Service Template pattern in a separate post — and try not to put it off for too long.