Tag Archives: lean startup

Technical Debt and the Lean Startup

A conversation on twitter between @david_harvey,  @rachelcdavies@RonJeffries and myself made me to think it was about time to post on my view of technical debt in a lean startup and how that view has changed since the days of running XP-based projects for established companies.

There’s a lot of information about Technical Debt out there on the web (including Ward’s Video, a clear summary by Martin Fowler, and an interesting, albeit somewhat flawed, article by Rod Hilton) and I’m not going to get into a detailed description here, but at its simplest level it says that making some quick-and-dirty choices today may lead to pain later on, and that pain is like a debt that you’re going to have to pay back at some point.

Its that ‘at some point’ which has led me to believe there is a difference between technical debt as applied to a lean startup vs. that applied to a project for an established business. In a project you are trying to deliver something which meets some kind of business case. You will know roughly who the customer is, roughly what their objectives are, roughly what you can spend (time and money) in order to achieve them, and so on. There’s going to be a lot of stuff that isn’t known but there are some constraints in place. When I used to use XP to deliver these kinds of project we had a very simple view of technical debt: don’t incur it if you can avoid it and, if you can’t avoid it, pay it down at the earliest possible time. Why? Because in these projects sustainability is a primary objective: you know you’ll have to pay the debt down at some point so why let it grow uncontrollably?

In a lean startup not only do you not know what your customers want, you don’t even know who they are, and you usually have less time and money to spend on finding out than most established companies would try and run a project with. Your primary objective is finding those customers and learning what they want, not sustainability. Which isn’t to say sustainability is unimportant, just that its not your primary objective; once you have a business, then you worry about how to make it sustainable. Its a High Quality Problem.

Here are some examples of technical debt we incurred at various stages of our search for customers and what they wanted:

  • Areas of the system understood by only one person. I’m a pair-programming fanatic and would love for everything in our system to be developed by pairs. But when you have only one developer in the company, that isn’t possible. When you have two developers and one has to go support a sales meeting, that isn’t possible. In fact, our experience is that until you have 5+ full-time developers there are going to be times when it isn’t possible to have everything paired. And do you know what? That’s okay. Code can be developed by a single developer but the fact that they built it on their own is a form of technical debt: until others have worked on the code, it is more widely understood, and has had the benefit of many eyes on it, you are in debt to the system.
  • Large scale refactorings left undone. We use a number of underlying platforms and tools. If the platform or tool doesn’t do what we need we develop custom code. It isn’t uncommon for the tool or platform provider to then release something that does what our custom code does at a later date and, until we refactor to use the new platform or tool feature, we have some debt to the system. But that’s okay – the custom code still works, its just not as simple as it could be nor as future-proof if the provider develops the feature further.
  • Limitations left in place. Sometimes a truly scalable solution is much harder than a simple but limited one. We had a situation where using in-memory collections led to a hard limit on the number of objects we could handle but the in-memory version of the code took a couple of hours to produce. We knew how to get around the limit – by adding in a system of creating permanent records and then processing them asynchronously using scheduled jobs – but that was several days work. The limit was okay – the function still worked, just for small collections of objects, and we had a debt to the system as and when our customers couldn’t live with the size limit.
  • Sub-optimal design approaches. Sometimes it is easier to deliver a simplistic design than a well-crafted one. For example we delivered a quick-and-dirty reporting function that was simple but slow because we were making it work, then making it right but hadn’t yet got to making it fast. But that was okay, the information was available to the users and correct, just not very quickly delivered.

But why would we live with such limitations? Aren’t we just delivering a shoddy system?

The answer to the first question is that we’re prioritising learning what makes our business work over some abstract notion of quality. If we develop a feature and it turns out that customers don’t want to pay for it, does it matter if it is only understood by one developer, that it could be refactored, that it is limited or sub-optimal? We develop the feature to get it into customers’ hands as quick as possible, to understand whether it is something valuable or not, to understand how it should work. Only if that features is valuable is it worth paying down any debt we have incurred building it. In fact, never mind the feature, the same applies to the whole system: unless the system is sufficiently valuable to customers we have no business and if we have no business the whole question of quality is moot. Customers pay for features and benefits, not fully-paired, beautifully factored, limitation-free, optimised code.

The answer to the second question is an emphatic ‘no’. We produce production quality, tested code. The testing is something we don’t compromise on simply because it is the mechanism by which we will pay down the debt if and when the time comes to do so. I can live with the fact that a design is sub-optimal if we have tests which will help us optimise it when we have to. I can live with code that need refactoring if we have tests which will help us refactor it when we have to. I can even live with something written by one person if … well you get the picture.

In a startup, technical debt is something to be managed, not minimised. We make sure we understand how much debt we have and which bits of the system it affects. We make sure we have the ability to pay down that debt as and when we need to. And we make sure we work the time and money required to pay down debt into any timsescales or budgets we agree.

Anything less would be irresponsible. Anything more is prioritising some notion of ‘code quality’ over learning what makes our business work and equally irresponsible.

Using eXtreme Practices to Run Your Business

To me the great innovation of XP was to shift the emphasis of software development away from realising a set of specifications to realising value for the customer and the twelve practices are all about maximising the team’s ability to do so. Its no great insight to recognise that running any kind of business is also about realising value for the customer and about a year after starting my first business I saw that we could usefully apply some of the XP practices to the business management as well as software delivery.

That was a number of years ago but this week I was reminded of the value of applying these practices, especially in the context of a lean startup where the need to discover your product/market fit and develop your business model is directly analogous to the XP team’s ‘discovery’ of the system implementation that achieves the greatest value for their customers and to keep on doing so.

Pairing – In a startup you can’t afford to do everything together; there has to be some division of responsibility and labour. However, the key business management activities – accounting, customer discovery, sales, marketing, product development – are best paired. Working as a pair to produce the monthly financial summary is so much more valuable than reviewing a spreadsheet produced by someone else and everyone on the management team needs to know what is going on in sales and customer discovery. The pair-programming benefits of lack of a single-point-of-failure, cross-pollination of skills, improved quality of output and so on are just as desirable in business management as software development.

Planning Game – However you execute the ‘planning game’ the same principles and outcomes are desirable in business planning as software delivery planning:

  • Quick and Easy. If you spend all your time plotting how to take over the world only one thing is certain: you wont.
  • Short-term Focussed. You need some idea of where you’re going but the emphasis has to be on what you do in the next few weeks to find out what your customers want and to make those sales.
  • Feedback-Driven. Don’t forget, in the relentless drive towards growth, to look at what has been working and what hasn’t.
  • Priority-Driven. There is no such thing as “not enough time” only “too much to do“. Make sure you’re doing the right things.
  • Visible. Getting the tasks up on the wall and making them visible to everyone is a powerful way of ensuring the priority tasks get delivered, everyone can see when things aren’t happening fast enough or when someone is struggling, and everyone can contribute to ensuring the goals for the business iteration are achieved.

Test Driven – My personal moment of epiphany with XP came when I realised how TDD meant we could spend a lot less time worrying about ‘architecture’ and ‘the design’ (less, not none) and more on saying what we wanted to happen and then making it happen. Setting simple tests for business management tasks like running a marketing campaign or pursuing a particular deal makes it easier to focus on getting things done and to learn from the outcomes.

Continuous Integration – Just as separately developing several streams of code and then trying to bring them together after a long period of time is usually a disaster, having the product people go off and develop the product separate from the sales and marketing people, separate from the people worrying about the money will usually end up with a bust company. Even in startups such as ours where the product people, the sales and marketing people and the people worrying about the money is actually a grand total of two people, the various strands of thinking and work need to be ‘integrated’ on a continuous (daily or weekly) basis.

Sustainable Pace – The first six months of a start-up are the hardest, except for all the months that come after. Which is to say that, if your startup is a success, you will work extremely hard to get it off the ground and then have to step your game up to keep it in the air. If you need to work 20 hours a day, 7 days a week just to get it off the ground, there’s a very good chance that you don’t have a business there. There’s also a very good chance that you’re just trying to do too much. Either way, you will have difficulty sustaining that level of effort when you get to the point the business really needs it.

As an aside, one thing that’s important to recognise about Sustainable Pace in running a startup is that for many people its not just your Sustainable Pace. If you have a partner and/or children, or just friends that you value, what’s the pace that you can sustain and that they can too?

I think its also worth saying that I don’t see XP as being a blueprint for lean start-up management and there are at least two XP practices that I think don’t really work:

Collective [Code] Ownership doesn’t really have an analog in business management. As mentioned earlier, most startups rely on some degree of division of labour. The fact that delivering a new sale or a marketing initiative requires building a whole load of relationships and interacting with people rather than a deterministic machine means that someone else can’t just step in at any point, make a bunch of changes and then roll back if it doesn’t work out. By all means collectively own the business and the objectives but no-one should be able to just go and interfere in someone else’s work at the drop of a hat.

Whole Team – Possibly a controversial one this but, after 13 years of running startup businesses, I’ve come to the conclusion that the running of a business is not a matter for the whole company. Yes objectives should be shared, there should be some form of vision for everyone to buy into, everyone should have a voice that is listened to. But not everyone has the skills and experience to make good judgements about the business direction or about the business’s current position. Especially in startup where things like cashflow, market conditions, and sales prospects are extremely volatile, the management team needs to know how and when to communicate about how the company is doing to everyone in it and how and when to respond to feedback and ideas from outside management.