Paid For Solutions, Not The Pursuit

A fun read via HN this morn – You Are Not Paid to Write Code.

I’ve touched on this many times here, including an entry a decade ago where I called SLOC the “Most Destructive Metric in Software Development“. A decade of experience has only made me double (neigh, quadruple) my belief in that sentiment: outside of truly novel solutions, SLOC often has a negative correlation with productivity, and high SLOC shops almost universally slow to a crawl until they hit the rock bottom of no progress. Eventually a new guard is brought in, a giant volume of code is trashed, and the same futile pursuit started fresh again.

This time, you see, it’s a giant node.js codebase instead of that silly giant python codebase they pursued the last time, replacing the giant Delphi codebase that replaced the giant Visual Basic codebase that…

This time it’s different.

An entry on here that gets a number of daily visitors is one from 2005 – Internal Code Reuse Considered Dangerous (I’ve always wondered why, and my weak assumption is it’s coworkers trying to convince peers that they need to move on from the internal framework mentality). That piece came from firsthand observations of a number of shops that had enormous volumes of internal frameworks and libraries that were second-rate, half-complete duplications of proven industry options. But it was treated as an asset, as if just a bit more code would give them the swiss army knife that would allow them to annihilate competitors. Every one of those shops eventually failed outright or did a complete technology shift to leave the detritus in the past.

It isn’t hard to figure out how this happens. If someone asks you to process a file from A to B — the B is the part they care about, not particularly how you do it — and you present a solution including some free and appropriate ETL tools and options, there is no glory in that. If, on the other hand, you make a heavily abstracted, versatile, plug-in engine that can (hypothetically and in some future reality where it ever gets finished) process any form of file to any form of output with a pluggable reference engine and calculation derivative, you can pitch the notion of IP. That instead of just providing a solution, you’ve also built an asset.

This is a lie almost all of the time. There is incredibly little code theft in this industry. That giant internal framework, when uncoupled from the internal mythology of a shop, suddenly has negligible or even negative value to outsiders. A part of that is a not invented here syndrome endemic in this industry (I’ve been in the business of trying to sell completed, proven solutions, and even then it’s tough to find customers because everyone imagines that they can build it themselves better), but a larger part is simply that broadly usable, generalized solutions don’t happen by accident.

This is one of those sorts of entries where some might contrive exceptions, and of course there are exceptions. There are cases where the business says “turn A to B” and you discover that you really need to turn A to B-Z, and 0-9, and… There are many situations where novel solutions are necessary. But so many times they simply aren’t.

Some of the most fulfilling consulting engagements I’ve taken on have been fixed deliverable / fixed price contracts. These are a sort that everyone in this industry will tell you never to do, but really if you have a good grip on your abilities, the problem, and you can obtain a clearly understood agreement of scope and capabilities and deficiencies of the proposed build, it is incredibly liberating. Being literally paid for the solution leads to some of the most frictionless gigs.