Month: November 2020

The Tools We Use

“It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits.”

– Edsger W. Dijkstra

Object Oriented languages suffer from a forced paradigm that fits more for UI design than solving the large scale data problems we encounter today. Languages like Java force a developer to speak in nouns and create artificial structures that don’t actually represent the systems we encounter.  The result is an inheritance tree with more and more abstract ideas being forced into shapes that don’t make sense.

Remember the QuickTime volume control? For anyone who isn’t old enough to remember, Apple QuickTime used to have a scroll-wheel volume control.  It was meant to be intuitive to the user so they could easily understand how to adjust volume.  The actual results where not what was intended.  Most users took their mouse, grabbed the tiny edge of the wheel, moved it a quarter inch up or down, released, and re-grabbed it wheel over and over until they got the volume correct.  It was painful, annoying, and substituted 30 seconds of UI training for a lifetime of frustration.

Forcing a bad model on users only works to limit the usefulness of the problem being solved.  Worse, instead of accelerating progress it debilitates our understanding of the underlying issue.  Software language paradigms multiply this mis-model understanding 100x resulting in overly complex systems, that are harder to change, and even harder to maintain.

There are lots of examples of this kind of round peg, square hole problem.  SQL is another example.  Large scale scheme enforced structured data is a solved problem.  SQL and SQL databases have done an amazing job of getting performance and consistency from data; but those aren’t issues with most startups.  Flexibility, velocity, cost, and non-specialization are the primary problems of the success of small startup teams; ACID compliance is not.   Developers with deep experience in SQL databases often have the drawback of thinking of most data like it is a table; which limits options and slows the development cycle compared to less structured data.

This has become a bigger problem because of the prevalence of unstructured data and the usefulness of map-reduce in processing that data in ways are particularly useful in web-scale systems.

The point isn’t to suggest that there isn’t a place for things like OOP development or SQL databases, but software shops that rely exclusively on these tools are dramatically limiting themselves.  A carpenter that only uses hammers, hand saws, and screw drivers is at a decided disadvantage to one that uses those tools AND a 3D printer.  The abstract thinking required to use these tools is definitely a hurdle to overcome, but the payoff is substantial.

Proof of life

Users are the only real proof that you’ve created wealth. Wealth is what people want, and if people aren’t using your software, maybe it’s not just because you’re bad at marketing. Maybe it’s because you haven’t made what they want.

Paul Graham

Inside of technology companies we have a whole host of ways we measure our progress. Key performance indicators (KPIs) I’ve seen include page hits, unique visitors, assets registered in the system, and even Google page ranks. The problem with these kind of KPIs are that they are vanity metrics that make you feel good about your “startup” but don’t actually lead to any sales.

Do you want to know how valuable your startup is? Ask yourself how many actual users you have. Investors, acquirers, and even partners will use this metric to determine your value; so you are probably better off using it to measure yourself. Paying customers is an even better! Look at the largest acquisition value multiplier for any tech company in the last decade and they will have one thing in common, paying customers.

The number of paying users is such a valuable metric that whole business spring up around customer acquisition. One of my favorite examples is the home security space…

At my last company, my partner and I were discussing a business strategy that centered around a serial home security startup founder he knew. This particular entrepreneur had sold 3 or 4 companies so far, each for around $10 million. His methodology was that he started a home security company using third party hardware and outsourced call center resources. He would then sell these systems like a mad man. He would go door to door, viral marketing, contract HOA agreements, pitch to builders… anything he could think of, while working 20 hour days, to get customers.

The beauty, from his standpoint, was these were all reoccurring monthly revenue subscriptions on 36 month contracts. If he could get a critical number of contracts (I want to say it was around 10,000 active home security systems) before the 3 year window, he could sell the entire company to someone like ADP who was happy to pick-up, and pay for, these customer acquisitions given the RMR model. He was treating the home security industry as an optimization problem where the primary metric of success was the number of users under contract and he was RIGHT!