One of the big ah-ha moments I had while reading <i>Start Small, Stay Small</i> by Rob Walling was that most developers have an aversion to carrying technical debt because they've experienced managers that never allow them to pay it back later. But when it's <i>your</i> startup (or small software company), you can choose when to pay back technical debt.<p>It sounds obvious, but I hadn't thought of it that way. Once I realized I had full control of when to pay back tech debt, it made me more comfortable accruing it strategically.
It's very simple; no juniors at the beginning!<p>They can make things work, but they don't have the experience to avoid tech debt even in the short term.<p>I have seen this as a CTO, unfortunately I came too late and the company broke.<p>The terrible management played a bigger part, but the code base was so terrible and the tech debt so big they couldn't ship even very simple features in a timely manner. Testing and release was insanely slow.
One technique I've used as a team lead to limit tech debt that makes it into production is to have devs write prototypes in a different language than what we actually support in prod. This has a few really nice advantages.<p>1. Devs enjoy getting to use new languages in the real world, and helps keep us learning.<p>2. The better you know a language, the more tempting it is to take shortcuts. When you don't know a language well enough to write really gross things that work "for now", you have to think carefully about the simplest possible solution to a problem that you can express clearly in an unfamiliar language.<p>3. You learn tons the first time you solve a particular problem. At the end of the solution, when all of your hacks and tradeoffs are fresh in your mind, you are the best possible person to tackle all the shortcomings and immediately do a rewrite in a language you are expert in.<p>3. Management really can't twist your arm to just go ahead and transition the prototype to MVP. All you can really do is throw it out there as a public beta with no guarantees while you build the MVP properly using everything you just learned from doing it the first.<p>4. You can start collecting feedback on what users want included in v1 and get an idea of where the user base is heading with their desires and plan some of that into your design, again reducing long-term tech debt.<p>If your prototype sticks the landing well enough for management to decide to move forward to MVP, then it's good enough to mark your territory in the problem space while you do the rewrite. You won't lose competitive advantage while it's sitting out there in a separate VPC collecting users and activity.<p>In a healthy company, this isn't a difficult sell to management. They'll understand the short and long-term value to the company. In more toxic environments, it will look more like you're throwing a poison pill into your dev process—which you kind of are. So, you know, tread carefully. But when people buy in to this process, it works really nicely and has far better long-term outcomes.
How many startups are actually killed by tech debt?<p>I saw many successfull companies with shitty software.<p>I had the impression the business part of things killed much more companies if they didn't get it right.
I work in a fear-based culture right now. The CTO never saw a kludge he didn’t want into production stat, and in his dual role as CEO won every disagreement. There are many pieces on tech debt that are true and valid, this one IMHO covers more salient issues than most.<p>If you’re reading this comment before you read the article: it’s about how to avoid getting caught too badly in the first place, not about magic bullets to get you out when you’re basically bankrupt.
I enjoyed this article and I think it's helpful for technical leaders in early stage startups. I feel like a lot of these companies will continue having problems mostly because the people that are attracted to smaller/early-early companies are the same kinds of people that don't want to work in structured (more corporate/deliberate) environments.<p>My experience is a bit more on the agency side where technical debt is caused by developers/project managers not really caring about the longevity of an application. The idea of going back and fixing anything that isn't specifically called out and invoiced for is so far away from the priorities of these businesses.
I've found it helpful consider the type of technical debt too. Get the data models right and most other technical debt is a lot easier to pay down. If you keep adding work on top of bad data models, things get more and more out of hand. I'll always fix data modelling as soon as the abstraction is found to be incorrect, even though that can cause a delay.<p>But, if you have repeated functions, or two similar react components which could be merged, that's a far lower risk to current and future development velocity.
Code is like a performance by musicians. They play together typically based on a plan known as "score".<p>But when they play a piece for the first time the performance is typically much lacking. They have to rehearse the symphony or rock-opera or whatever.<p>Removing technical debt is like playing the song again, this time better. You learn what works what not and can do it better. The challenge is how to know the code-performance is good enough.
The title is good, and contains an often overlooked point: startups need to survive tech debt precisely because they do not need or want to avoid tech debt. Startups generally don't have the resources to do things properly. They don't have the people, the cash, or the time. So they trade on their future value: get cash from investors on the promise of future returns. Pay below-market salaries but promise quick promotions and options packages. Take on tech debt to get to market now, and hope to pay it off later. And, when it works, this is a great strategy. Tech debt is good if you're a startup. But only if you survive it.<p>Personally I've never seen a startup that was actually killed by tech debt, although it does sometimes cause good employees to quit, and of course it causes product delays. It's like any form of debt: a dangerous but oftentimes necessary tool.
Every bug fix is paying down technical debt. We don't squash every bug, we fix the most important ones. Otherwise, we'd be swatting bugs all day.<p>If there is a bug in the woods, and the bug takes a shit, but no one is around to hear it...<p>Now, is it going to kill a startup? Hardly. At that point, an MVP, it's probably still small enough that the better decision is to rewrite it altogether. If you split the server and the UI to begin with, you can re-design the front-end and make a party out of it, try to make it pretty this time.<p>If you're at the point where you need more than 1 person to handle the whole app, then you're not a startup anymore, imo. You have a proven small business.
One tactic I have used with moderate success is to explicitly carve out time for fixing tech debt. A few things we’ve tried:<p>1. Pledge to schedule 20% (pick your percentage) of the sprint as tech debt payback rather than stories. The problem here is that this stuff tends to drift to the bottom of the sprint and then slip if anything else is delayed. This is where most teams start as you can start at an arbitrarily small percentage and scale up gradually.<p>2. Fixit Friday; the middle Friday of a sprint is for fixing tech debt, not working on sprint tasks. Engineers are encouraged to advocate for tasks they think would speed us up, and we also have done themed pushes where e.g. the whole team chips in to migrate the codebase to a new linter. One issue here is that it’s hard to make progress on larger initiatives, which leads to:<p>3. Fixit Sprint. At the beginning of the quarter there is often a bit of downtime as the leadership digests the last quarter and plans the new one. This can be a good time to take a sprint off product work, and really dig into some substantial re-tooling or refactoring.<p>Depending on how much resource you’re allocating to tech debt, you can mix and match these, I’d say 1 & 2 are probably mutually exclusive, but you could combine either with 3, or just do 3 instead.<p>I think it’s important to be clear about when you are taking on tech debt, and when you have cleared the hurdle and are paying it back, and clear rules like these help to communicate that message.
You also need to get comfortable taking out tech debt as a startup. A lot of times you can get away with it at little or no cost.<p>I wasted lots of time prematurely paying back tech debt only to have that code later deleted or rewritten.<p>It is important to properly prioritize tech debt and pay back things that the business is currently paying high interest on.<p>Once the product matures it makes sense to be more proactive in doing things right, but in the early stages, things are changing too fast that you just need to get out a rough prototype.
Exit before the technical debt comes due.<p>Also, if you're growing fast enough that it matters, you'll need to redesign the whole thing anyway. Google did that on their search engine at least five times. In the early days, it took weeks to update the index.
There's another way: Move fast enough to justify rewrites. This even happens at larger companies like Facebook when they rewrote React. <a href="https://engineering.fb.com/2017/09/26/web/react-16-a-look-inside-an-api-compatible-rewrite-of-our-frontend-ui-library/" rel="nofollow">https://engineering.fb.com/2017/09/26/web/react-16-a-look-in...</a>
I wonder how many startups were killed solely due to tech debt repayment. I had this sin too. Not that there were too much of debt, but it's unbalanced wish to repay it and stuck with that was the source of never finished refactoring that took enough time to kill everything.
If you're a startup, there is no way you will move fast if you don't incur tech debt. Why is it seen as a bad thing? It should be a given.<p>Once you know that your company is there to stay, you hire experienced people and create a strategy to pay it back.