by Yadi on 7/26/15, 12:50 AM with 54 comments
I work as a web architect contracting with startups on smaller complicated pieces of technologies. These days lots of startups I talk with have a very high technical debt in their product(s) and most of them don't seem to care.
My first advice to them is that things like that can kill a product, but I've had some strange feedback after passing on that advice.
So I wonder if technical debt does actually have pitfalls along the way? (Bootstrapping yeah I agree, but not when you have 8 engineers on the team)
by pedalpete on 7/26/15, 1:15 AM
Another example is Instagram, I read recently (but can't find the link) that the founders were learning to code when they built it, and that some of that code is still in production, and apparently, it's embarassingly bad, but it gets the job done.
On the other hand, I worked for a consulting firm and one of our clients sites was absolutely riddled with technical debt. The result was that any changes they wanted to make were significantly more expensive than if they would have been on a better architected system. The thing is, it did't matter to them because the cost of re-creating the system was significantly more than the cost of working with what they had.
I hate technical debt, but have come to realise that it is a debt much like any other, and if you can cover the cost of that debt, it doesn't really matter down the line.
This isn't an excuse for bad programming, I consider that to be something slightly different from technical debt which often works but is not an idea implementation.
by davismwfl on 7/26/15, 1:09 AM
Also, I would say to much concern over technical debt can cause failure. I personally lost what I conservatively would say was 30% of our net revenue last year letting my prior lead dev address technical debt that never benefitted a single client and that in areas we have now replaced (or are in process of replacing) entirely in the product. I am as much (if not more so) to blame as he was because I approved the time.
by autarch on 7/26/15, 2:59 AM
My definition of technical debt would be "problems in the code base that make it harder than it should be to do work," whether that work is adding new features, fixing bugs, scaling up, etc. The startup that can implement new features quickly because their code base isn't a disaster is more likely to succeed. They can try out new features quickly, seeing what customers respond to.
Customers need things like uptime, minimal bugginess, quick bug fixes, etc. Technical debt reduces uptime, increases bugginess, and makes it harder to fix bugs.
I think it would be hard to point at a startup and say "technical debt killed it". In most cases I imagine there are many inter-related causes of failure, but an inability to quickly add new features, fix bugs, and keep the system stable can't be a good thing!
by dudul on 7/26/15, 1:38 AM
I have never been at a startup that failed for technical/technology reasons. All failures I've seen were due to issue with delivering what customers were interested in paying money for. Most often, product owners and developers were not able to establish good communication, which led to developers basically creating a product that didn't match what customers wanted. Period.
I would be interested in your definition of technical debt though. What some people call "technical debt" or "hack", I often call "the best/fastest way to address the current business concern and deliver immediate value". In a startup environment I think these is a critical workflow.
by narsil on 7/26/15, 2:18 AM
Anything that delays shipping is going to contribute to the failure of a startup.
by rgbrenner on 7/26/15, 3:36 AM
Along the way to delivering that value, sometimes a less than perfect solution is chosen (often because of resources--time, money, or lack of human resources) OR the perfect solution is chosen, but the product changes and that solution no longer is perfect.
Technical debt should be managed, but it can't be eliminated... unless you want to give up producing anything new, and just work on polishing your previous work forever.
When will it kill your startup? If it turns out that your product is NOT what your customer actually wants, but the shortcuts (tech debt) you took prevent you from making the necessary adjustments to meet your customers needs.
by mikhaill on 7/26/15, 4:19 AM
A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.
The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.
They didn’t use a framework.
This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand the that code instead of working on the revenue generating features.
We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.
It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.
by Zigurd on 7/26/15, 2:10 AM
More often it's not "technical debt" but outright failed implementation when technology kills a startup
See how far it takes you and if you are wise enough not to press your luck, you'll have the chance to do it right with cheaper money.
by alcima on 7/26/15, 5:00 AM
Trade off an extra day to do each release versus 30 days to fix the release process? Trade off an extra week to add a feature versus a month to refactor and a month of customer turmoil on the refactored release? Trade off a month of getting complete test coverage versus saving two days on a future feature development?
My guess would be that the startup founders are doing a better investment calculation than it might appear to you.
by theodorewiles on 7/26/15, 2:56 AM
When you get X customers, you'll have to commit Y resources to fix this one thing.
Taking on technical debt is a smart thing in early stages because it's essentially low-cost, non-dilutive financing. So you should recognize that very real benefit.
However, if they are young startups they might not even realize they are doing this smart thing. You can add value by telling them are smart and giving them the schedule of technical interest payments they will have to pay one way or the other if they are still in business.
by brudgers on 7/26/15, 2:04 AM
Good luck.
by trunnell on 7/26/15, 4:29 AM
To figure out which ones do, I sometimes think about the correctness vs. completeness spectrum.
Correctness is how well the architecture fits the problem, how well edge cases are handled, if it's a service then whether it's built to scale horizontally, etc.
Completeness is how shippable the thing is. Are the important features there, are the bugs not too severe, could the thing live in production without causing severe harm, etc.
Some problem domains live only at the far end of the correctness spectrum, like software that life depends on, flight control, nuclear reactors, etc.
Other domains might be all the way on the completeness side, like the throw-away prototypes, temporary stand-alone marketing sites, etc. If it works at all, you can ship it. Problems there don't count as technical debt.
Obviously most projects are somewhere in the middle.
Most high-growth companies can get away with erring a bit toward the completeness side, and ignoring correctness for many things, because a lot of stuff will be re-written every year or so to handle the changes in the business brought on by customer growth. Since it will be re-written anyway, it might not be useful to think about the lack of correctness as technical debt because you won't ever pay the debt. The real trick is figuring out which things must be perfect now and which can be improved later.
Getting that wrong either way could lead to the failure of your startup. Settle for nothing but perfectly correct architecture for everything, and it might take too long to ship. On the other hand, ignoring severe problems in a critical system might somehow limit growth, cause a legal problem, etc., and eventually sink the company.
by vezzy-fnord on 7/26/15, 2:13 AM
Though, much of this was exacerbated my management's insistence on implementing a myriad of side jobs to bring revenue while deliberately ignoring the main part of the website being unresponsive.
by geofft on 7/26/15, 11:34 AM
It may be true that technical debt directly kills some products, but if it's bad enough that you can't get certain things done, even if what you do instead is also important to the business, the debt is a sign of bad engineering management (either in the past or the present). And bad engineering management will kill the product.
by bliti on 7/26/15, 3:21 AM
by pbreit on 7/26/15, 4:14 AM
by dylanjermiah on 7/26/15, 3:35 AM