When Good Enough Is The Better Engineering

Engineering blogs are full of stories about perfect refactors, elegant abstractions, and multistage pipelines. I’ve admired those stories myself.

But after years of working in real-world environments, one pattern has become clear to me: completing several projects to 80% often delivers more value than completing a single project to 100% (besides the fact that you will never reach 100% anyways).

This isn’t about embracing sloppiness. It’s about working effectively within real-world constraints. In many organizations, teams are small, resources are limited, and multiple foundational problems need attention. In these situations, focusing all effort on perfecting a single project can delay progress across the broader system.

The Reality of Too Many Topics, Too Few (Good) People

In an ideal world, engineers could dedicate themselves to one project and polish it to perfection. But in most organizations, especially those working on complex systems, the reality is different. Multiple urgent problems compete for attention. Foundational systems often need iterative improvement rather than perfection, and small teams cannot afford to freeze progress while waiting for the final 20% of polish.

In these situations, bringing several projects to a functional level can create more tangible value. It provides broader coverage of fundamental issues and surfaces critical learning earlier than perfecting a single project.

And sometimes we simply do not have the engineers who can take a problem from good to exceptional in the first place. Reaching a truly polished solution often requires deep expertise, significant context, and the ability to see and solve problems that are not obvious at first. Not every team has that capability available, and pretending otherwise does not make the gap disappear.

There is also a more human factor. People naturally want to work on new and interesting problems. Once a project is functional, going through another round of discussions, edge cases, refactoring, and small design decisions can feel like diminishing returns compared with starting the next challenging project. The last details can easily become the work nobody wants to own. This is where prioritization becomes more important than completion. Sometimes the better engineering decision is to get a solution into a useful state, move on to the next important problem, and return later when further refinement has enough value to justify the investment.

And even when you do have these highly talented engineers, there is another question worth asking: what happens when they leave?

A system that was built and maintained by someone with exceptional expertise can become difficult for everyone else to understand and evolve. The solution may be technically excellent, but if maintaining it requires the same level of expertise as building it, the team has created a dependency on a very small number of people. I genuinely admire teams that are able to build sophisticated systems like this. When you have the right people, the right context, and the right resources, you can achieve an impressive level of engineering quality. But the uncomfortable reality is that most teams simply do not have a large group of these exceptional engineers.

For the majority of teams, engineering also means building systems that other engineers can understand, maintain, and continue improving. A slightly less sophisticated solution that the whole team can work with may ultimately be more valuable than an exceptionally elegant one that only a few people can safely change.

Automation Is Not Always the Answer

This approach may mean that there are still a few manual steps left in any process. That is not necessarily a problem.

Full orchestration often sounds straightforward until you account for the number of variables involved. Different environments, inputs, dependencies, edge cases, and operational requirements can quickly turn a seemingly simple task into a complex engineering effort.

Automation is often the right answer, but it is not always the highest-priority one.

If automating the remaining steps requires significant engineering effort while other problems are already costing the team time every day, it can make more sense to address those problems first. The goal is not to eliminate every manual action. The goal is to reduce the overall operational burden and deliver the greatest value with the available engineering capacity.

Practical Guidance

The approach is straightforward.

Ship core value early. Solve the important problem first, make the solution useful, and then decide whether further investment is justified. Start by identifying the core value the project needs to provide. Get that part working instead of spending time on secondary concerns that do not materially change the outcome.

Iterate across systems. Once a solution is useful, look at the broader landscape. Ask whether another unresolved problem would benefit more from the engineering capacity required to continue refining the current one.

Refine where it matters. Finally, come back to refinement when it matters. Better abstractions, additional automation, performance improvements, and edge-case handling are worthwhile when they solve a real problem or create measurable value. They are much harder to justify when the main motivation is simply making an already-working solution feel complete.

A Real-World Example: Building a Forensics Pipeline

A good example is building a forensics pipeline for a SOC or incident response team. Instead of trying to build an entire forensic processing platform from scratch, you can combine proven tools such as Timesketch for timelining and OpenRelik for the heavy processing. Will it be a pain to setup, nevertheless? Yes, absolutly. But not as much as creating it from scratch. Believe me.

The first step is not to build every possible OpenRelik worker. It is to build a framework that makes it easy to create new workers for your specific environment, and then implement the first two or three workers that cover the tasks analysts perform in most of the cases.

Could you build many more workers to handle the last arbitrary file format or obscure artifact that might appear in 1% of investigations? Absolutely. But until that case actually becomes a meaningful problem, spending weeks building and maintaining functionality for it is difficult to justify.

The important part is that the framework makes that final 1% easy to address when it eventually matters. When an unusual artifact appears, you can create a dedicated worker without having to redesign the entire pipeline.

This approach delivers more value because the analysts can already use the pipeline for the other 99% of their work. More importantly, the time saved by automating those common cases can be invested somewhere else.

For example, that time could go into one of the less glamorous but often more impactful areas of detection engineering: fixing the biggest sources of false positives and building a useful exclusions list. Instead of having the SOC repeatedly investigate and close the same false positives, engineering effort can be spent addressing the underlying problem.

The goal is not to leave systems unfinished. The goal is to make deliberate decisions about where the remaining work creates value, and where it simply consumes engineering capacity that could have a much greater impact elsewhere.

Conclusion

The engineering blogs and conversations I read often showcase beautifully refactored code, elegant abstractions, and sophisticated multi-stage, multi-target build pipelines. I admire that level of engineering, but I also have to be honest with myself: I may never become the kind of 10x engineer who can consistently produce those solutions, and even if I could, that does not mean they should always be my goal.

I work within the constraints of my own skills, my team, and the problems in front of me. At some point, the question is no longer “Can this be made better?” Of course it can. The more important question is “Is making it better the best use of our engineering capacity right now?”

For me, engineering is ultimately about creating useful systems and solving meaningful problems. I would rather have several systems that provide real value and leave some refinement for later than spend all my time trying to produce one piece of perfect engineering.

Accepting my own skill boundaries is not an excuse for poor engineering. It is a constraint I can work with and one that helps me decide where my effort is most valuable.

Maybe this is just my own coping mechanism. Who knows?