When you found a business, you become overloaded with choices. Choices are everywhere. If you desire to start your own business so that you can be your own boss, I would say, “be careful what you wish for”. Most of the time, there are no right answers, and you’re literally just guessing and hoping for the best. Anyone who claims otherwise is a lucky fool, and should look up the Wikipedia article on “regression toward the mean” – luck goes up and down in equal measure.
Unfortunately for those of us seeking to learn from the success of others, there are some lucky fools that live forever. They stay lucky. That’s the way randomness works. Flip a coin a 100 times, and you’re likely to see at least one run of six heads in a row.
There’s no magic, it’s just mathematics. That’s why stories of failure are more useful than stories of success – you can be more certain that the decisions made were indeed the cause of failure.
The thing to look for in these stories of failure is the strategic lesson.
Can you build a strategy to stay alive? One strategy that keeps coming up is how to make effective use of limited resources. This is no surprise in the context of a startup.
But it is not enough simply to recognise the problem. What is your strategy for dealing with it? How will you make decisions about resources?
Adopting a mental model of ‘trade-offs’ is the approach that has been most useful for me. You must accept that you just can’t have come things, and that you must leave some fires to burn, despite the damage they cause.
You deliberately choose to take damage in one place in order to maximize your force at another place. Many business writers talk about the power of focus, but they do not often acknowledge that focus requires trade-offs, and the bitter taste of low quality in other areas of your business.
This idea of making explicit trade-offs comes to me from my software development days. You never have enough resources or time to deliver the full specification – hence the old engineering aphorism: “time, money, features; pick any two”.
What ends up happening is that you delivery shoddy features that appear to be complete, usually late, so it costs more anyway.
Why does this happen? That’s a big questions, and speculation has filled many books on the subject. But once thing that stands out from my own experience is the impact of ‘technical debt’.
A few years ago my then six-year old daughter appeared in our bedroom early one Saturday morning to announce blandly that it was “raining in the kitchen”.
The ball valve in the water storage tank in the attic had finally failed. The tank filled with water. It overflowed into the attic, flowed down between the partition walls upstairs, and then pooled above the kitchen ceiling. At the time we had a stippled ceiling, which it turns out was also porous. Droplets were falling from each stipple. It was, very much, raining in the kitchen. A lovely weekend that was!
If you any practical knowledge of houses you will be asking about the overflow pipe. This is a pipe attached to the water tank at a high level to deal with exactly this failure mode. When the ball valve fails, the tank fills, but excess water flows out of the overflow pipe and into the gutters. This saves the interior from water damage.
There was indeed an overflow pipe. But there was also a deep cut into the other side of the plastic tank to make it fit into our ceiling rafters. The cut extended below the overflow. Whoever designed the house, and whoever ordered the tank, obviously did not speak to each other. The engineering failed, probably because everyone was just rushing to get the job done. Thirty years later, we paid the price.
This is technical debt. Corners are cut to make the deadline. Everything appears to be working, but things can explode at any moment. Worse, when improvements are to be made, perhaps a new ensuite bathroom, the problem is discovered and leads to a much more complex job, as the old problem has to be fixed first. That really slows down feature delivery after you go live.
This is bad in the physical world, but limited by the physics of our three-dimensional universe.
In the software world, you have infinite dimensions of data, and can accrue infinite amounts of technical debt. This is a big reason why many software projects fail.
Technical can be fatal for startups. Spend all of your investors’ money on a low-quality system, thus failing to gain customers, and it’s game over.
So this answer is to avoid technical debt? Impose strict controls on the software team? Make sure you ‘lawyer up’ to strike fear into your contractors?
No, you would be as King Canute sitting in his throne on the beach, ordering back the tide. The part of that story that is often missed is the point King Canute was trying to make – mere mortals cannot change the fundamental order of things.
So it is with technical debt. You will never have enough time. You will never have enough money. You will always stress out your software team, and they will always cut corners to make you happy.
And that technical debt will always have to be repaid with interest. You only survive if your business model works fast enough to outpace the mounting technical costs.
Do you have no choice but to accept technical debt? No. Of the many choices you face, this is one of the most strategic.
You can choose where you take out the debt, and where you do not. Make the right trade-offs, and you’ve just gained another lever to survive, and make better use of your resources. By accepting that parts of your system will be low-quality, and by accepting that this is inevitable, you choose where to apply engineering talent so that you get the best business result.
Here is a decision that we made in voxgig based on this principle: you can always solve a software problem with manual labour.
In our newsletter, we list three conferences, detailing their ticket price and location.
We also list five upcoming ‘call-for-papers’, so that prospective speakers can pick out good conferences to speak at. Generating these lists was done by hand, by me, in the early days. Then we brought on board a freelancer to do the research. She entered the data into a spreadsheet, and I wrote an ugly little macro (of exceedingly low quality code) to turn that data into formatted content for the newsletter.
It is only now, in the last month, that we have finally written some real production code to do this work. And even then, it is “quick and dirty” – there are no tests, no grand architecture.
It is written in Python, a language not known for it’s performance, as a simple batch script.
In the future, we will rewrite it again, and the generation of these lists of recommended conferences will delivered by the high-quality core system code. In the end we will have written three versions of the same code.
This is where your intuitions might fail you if you do not embrace technical debt as a weapon of choice.
It is not wasteful to do the same thing three times if it the effort to it right the first time was not useful to the business at that time. In the case of the newsletter, the output of the code was always the same. Who cares if the underlying code was muck, so long as the newsletter itself came out shiny?
By doing this we were able to spend effort elsewhere on our conference search engine, which has enabled us to deliver a demo-able system sooner.
So here is the strategic lesson: not all software code is the same, or needs the same level of quality. You can cut corners, especially when all you care about is the output. Reports, batch processing, content generation-these are all subject to the same forcing function.
Deliberately choose to incur technical debt when you build these parts of your system, and you will have more engineering resources for the hard parts like the user experience, where quality really counts.
(Newsletter numbers for this week: 1,402 subscribers with an open rate of 18pc)
Richard Rodger is the founder of voxgig. He is a former co-founder of NearForm, a technology consultancy firm based in Waterford.
Article Source: http://tinyurl.com/kbwqb42
