

Ask HN: Do you worry about technical debt? - adv0r

How do you deal with technical debt in startups?<p>Do you leave for later stage or you start worrying about it from day 1?
======
aaronblohowiak
Remember that debt is an analogy, what we're really talking about is bad code
we have chosen to live with.

More startups fail from not enough money coming in than from having tech fail.
Many mid-life startups fail because their technical debt causes them to be
unable to quickly grow and respond to changing conditions.

How to get the speed of development with short-term thinking but avoid long-
term pain?

* Keep it contained. The big-picture diagram should be pretty good, but the details of implementation can be shitty as long as the same interface would accomodate the better version. This sets you up for success later when you need to replace the bad implementation with a better one.

* keep your core clean. The more features and other code paths rely on a chunk of code, the more 'core' it is. "Core" code should be kept clean because of the risk that bad core code poses to the business.

* comment your regrets and thoughts about how you'd fix it in the code so when you burn out and some new hacker is trying to fix your crap they will at least be able to have an idea of what you were intending to do.

~~~
adv0r
Thank you for you answer ;) I'm actually making my master thesis on this
topic, and you are the first person I hear ( sort of) telling me that "Many
mid-life startups fail because their technical debt causes them to be unable
to quickly grow and respond to changing conditions."

If you could please support this statement somehow, I'd really appreciate (not
because I don't trust you or I disagree, but because researches need
references ;)

~~~
aaronblohowiak
Sorry, I only have anecdotes. You need data =D

~~~
adv0r
if you did worked in startups, you are data :D (did u? ) :D

------
monsto
The word "debt" has a couple of unstated meanings to most people. These are
things that nobody says out loud because it's not really coherent to the
individual but everyone pretty much has the same corner reserved in their head
specifically for the weight that true debt carries... if that makes sense.

I think people see "debt" as temporary but at the same time an ever-present,
albeit low-level, responsibility. that it deserves a constant trickle of
attention.

This is the wrong attitude to have towards technical debt. The avoidance of
down-the-line refactoring anything should be as high of a priority as customer
service. Keeping code clean, organized and documented allows the developer to
deal with bugs and new features quickly. An ounce of prevention, right?

* If users are clamoring for a feature, they will wait another week for it to be built properly. (A well built feature will easily make up for impatient customers by not generating bugs or other problems) * A lot of us have this niggling "gottamovegottamovenotgoodenuf" vibe all the time. But just because you FEEL like you're losing ground doesn't mean you are. And if you ARE losing ground, it's too late for that one thing that's behind schedule to save you anyway... meaning that your problems are likely elsewhere.

~~~
adv0r
It makes totally sense to me. What I've found interviewing many startups, is
that they just don't have the time to document anything, and other priorities
( time-to-market , burning investor cash, demo days, angry users ) are
definitely more important than documenting .

Or, more specifically, they usually start by planning and documenting
everything, and they end up with outdated documentation, spaghetti code, and "
issue-driven " development as they move forward.

Many of them told me that "using rails framework help us in not writing
documentation, because ruby standards are pretty well defined"

do you guys agree somehow?

------
clueless123
Technical debt is not always bad.

Imagine you can borrow cheap money to bootstrap your business idea, but you
only have to pay back if your business is wildly successful.

