Five Million Lines of Code Later, Here’s What I Wouldn’t Build Again

Coverity has accumulated something on the order of five million lines of code across its history, branches, generated artifacts and the surrounding ecosystem. Before somebody writes to explain that lines of code are a terrible productivity metric: yes. They are. That is not why I mention the number.

I mention it because once a system becomes sufficiently large, it starts teaching you things that architecture diagrams cannot.

Some abstractions that looked elegant become annoying. Some “temporary” decisions develop grandchildren. Features you thought would be central barely get used, while a small utility becomes infrastructure everybody depends on. And occasionally you discover that the clever thing you spent three days building could have been replaced by a boring managed service and a credit card.

I don’t regret building Coverity. I do have a much better idea now of what deserves custom software.

I would build less before proving the boundary

Early in a product, it is easy to generalize too quickly. You see two similar workflows and immediately start designing the universal workflow engine that will someday power every industry from escrow to plumbing to interstellar cargo logistics.

Sometimes that abstraction is real. Sometimes you have merely found two things that look similar from far away.

Today I prefer proving the operational boundary first. What is actually invariant? What changes by customer, jurisdiction or vertical? Which parts deserve configuration and which are genuinely different products?

The cost of a premature abstraction is not just extra code. It is that every future feature has to negotiate with an idea you invented before you understood the problem.

I would buy more boring infrastructure

Founders have a dangerous superpower: if we dislike a product, we can build another one.

This is not always a gift.

There are things worth owning because they create differentiation, control or economics that matter to the business. Dispatch logic, workflow behavior, exception handling and the pieces that make Coverity actually Coverity belong in that category.

There are other things where the market has already solved the problem adequately and my time is worth more than the subscription fee.

The older I get, the more beautiful a boring commodity service becomes.

I would design exceptions earlier

Happy paths are seductive. The customer submits the request, the notary accepts, everybody arrives on time, documents are correct, signatures happen, scanbacks appear and the package ships.

Then production meets humans.

Someone enters the wrong address. A signer doesn’t have email. A notary loses connectivity. A document changes after dispatch. A customer needs to reschedule while another appointment is being inserted into the calendar.

The exceptions are not edge cases once the system operates at scale. They are the product.

I now think exception handling deserves first-class architecture much earlier than most teams give it.

I would still build more than a normal person

This is not going to end with a revelation that I have become a no-code minimalist.

I know myself better than that.

I like building systems. I like understanding the entire stack. I like discovering that something everyone treats as an unavoidable manual process is actually a solvable integration problem.

And sometimes owning the stack creates capabilities you simply cannot buy.

The lesson is not “build nothing.” It is to be much more deliberate about what deserves to become part of your permanent maintenance surface.

Software has carrying costs

Every custom component becomes something you may eventually have to patch, secure, monitor, document, migrate and explain to another engineer at 2:00 in the morning.

That does not mean it was a mistake. It means the decision to build creates a liability alongside the asset.

Five million lines later, the question I ask more often is not “Can I build this?”

Of course I can build it. That’s usually the problem.

The better question is: Is owning this code part of the advantage I am trying to create?

If the answer is yes, build the hell out of it.

If the answer is no, there may be something wonderfully boring available for $49 a month.