The Tyranny of closed source

27 Nov 2013

Horatio Alger, Strive and Succeed
"Work expands so as to fill the time available for its completion."-- Parkinson's law

The following are all things that have been said to me in a professional
software environment:

“It’s not that hard. We just need to build a globally distributed
key-value store and put some application logic in it.”

”[That open-source project] didn’t have a feature we wanted so we
forked it 3 years ago and now maintain this broken 3-year old version.”

“ActiveRecord validations aren’t flexible enough, let’s build a
framework for database triggers.”

“The problem with [an enormous repo] is that we haven’t finished
building all the parts of it yet.”

To a person each one of the engineers quoted was a capable developer and
had many years of experience. And at the time the decision to do these
things made perfect sense. Not only did it solve an immediate problem
– it was fun engineering.

We engineers like to build large things and nothing feels like it needs
a large solution quite like a large problem. The process of actually
solving a technical problem is quite methodical and requires great
discipline: You have to develop a strategy, you have to diligently get
feedback on your strategy, and you have to implement a small version of
your proposed solution so you can determine quickly if it’s actually
going to work.[1]


The best guide around on strategy is Richard Rumelt’s Good Strategy,
Rumelt teaches that a strategy has three essential parts: a diagnosis of
a problem, a guiding policy for how you will solve the problem, and
specific actions taken in line with that policy.

As an example let’s pretend somebody comes up to you and says “The
postgres database drives are full.” That’s a presenting problem but is
it really the issue? Rather than jumping to a “shard more!” or “buy
bigger drives!” solution Rumelt would suggest we identify if this is a
result of massive surge of new customers or a rogue logger or if “full”
actually only means 50%. That’s diagnosing the problem.

If, say, it’s an influx of new customers then you gotta develop a
policy. So you’d not just fix the postgres boxes because most of your
infrastructure is probably going to start creaking under the load. What
you need is a proper capacity plan that identifies bottlenecks and can
give you a rough estimate of how many and what kind of servers you’ll need.

Lastly you’d need to actually provision new machines. This
problem-solving step is the one we engineers tend to be good at but we
often arrive here too early. If, in this contrived scenario, we merely
reclaim 20% of disk space through an epic compression hack and call the
problem solved then we’ve not only wasted time but fooled ourselves.


Some Xooglers at Square introduced our formal design review process and
it’s proven very effective at improving engineering concepts before they
get committed to code. Our procedure is that you write up a 1-page
document saying what problem your new code is solving, what your code
will do, what it will explicitly not do, what resources is consumes and
what it produces.

This is small enough that it’s not onerous to either write or read. And
as long as your coworkers have worked at at least one other company
you’ll be surprised by the helpful ideas.


So you’ve got a strategy, you’ve got a design that has its most obvious
flaws patched, and now you have to build it. If you value your career
and you should probably not just spend the next 9 months perfecting this
new application. You might find that it’s so complex that staffing it is
more costly than the problem and the company will hate you for building
it. You might find that your company has no experience operating your
chosen database at scale and you need to switch to a datastore with a
totally different API. You might find that you built it in technology X
but everybody at your company and everybody you’re able to hire only
knows technology Y. An
MVP will let you
flush out these issues quickly.

No more software

The goal isn’t to write good software but to write as little software
as possible. If you’ve ever mentored a very junior engineer then you
know that they can produce vast quantities of code. They also devote
little time to maintaining. Veterans not only write clean-ish,
maintainable-ish code but do it as rarely as possible.

“In-house software expands so as to require the maintenance of the
entire engineering team.” – Jack Danger’s law of not-invented-here

The job of your company is to produce a product that is worth hard cash
to somebody. And your job is to build that product. Not to build a
database, not to build a javascript framework, and not to build a new
testing library. Those are great hobbies and if your company has the
in-house skill to build a best-of-breed tool and release it then
absolutely do it. But that’s rare.

It’s better to build a simple solution than a complex one, even better
to use an open-source solution, and if you see a path to do it without
software at all then take it.


  1. You could replace ‘feedback’ with ‘market testing’ and this is also
    the formula for effectively driving a startup.

Please if you found this post helpful or have questions.