Ask HN: Do you worry about technical debt?
How do you deal with technical debt in startups?
Do you leave for later stage or you start worrying about it from day 1?
Do you leave for later stage or you start worrying about it from day 1?
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.
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 ;)
In my mind, this is what is meant by phrases like "excellent startup teams are good at execution". They can ride the line between getting features done without becoming bogged down in their own code. It's easy to hack something out. It's easy to spend all your time making in an architectural masterpiece. It's really hard to balance that in a way that allows for continued growth.
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.
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?
Imagine you can borrow cheap money to bootstrap your business idea, but you only have to pay back if your business is wildly successful.