

Ask HN: Avoiding techical debt - uptownhr

I saw a another ask hn post today regarding technical debt and I wanted to ask this.<p>If technical debt is a big deal, KISS should be the most important decision. Let me elaborate.<p>Even before writing a single line of code, chosing the frameworks and or introducing a framework to you application stack is a big decision. For example, does your web app need a frontend rendering framework?<p>If there is a single engineer, he will be the devops, backend dev, and frontend dev. Even if the dev is familiar with angular or react, the simple introduction of such a framework is an immediate take on a debt. This is one way too look at it.<p>Do you just write the so called jquery spaghetti code that people frown upon so kuch these days? Or is writing jquery code more of a technical debt?<p>As a startup, do you slowly incur debt or immediately take on lump sum with more frameworks, betting that it will pay off.
======
thwarted
Recognizing, managing, curating, and killing technical debt is something that
only comes with experience.

It's all about trade offs, and trade offs are informed by the environment they
are in. When it's early and getting an MVP and revenue is important, you need
to go with what you're comfortable with and have significant experience in. To
do otherwise is going to distract you from the area you still need to explore
and become an expert in: the business logic.

Really, this is why you'll see startup job postings saying they are looking
for specific languages or frameworks: when they start seriously hiring for the
first time, they need more people to help grow what they already have, no
matter what that is, not people who want to come in and replace it with their
favorite whatever.

There is no one-size-fits-all solution, and few technical debts are exactly
similar. All are multifaceted and look different from different perspectives.
What may be technical debt for one company, group of engineers, or at a
specific time, may not be for another company, group, or time.

Presumably, before writing a single line of code, you aren't approaching the
task totally green: your very idea must have been influenced by your abilities
and experience. You should know if your web app needs a frontend rendering
framework, and you're comfortable with one already or are willing to learn one
in the short term. If you know JSON and are familiar with libraries and
language support for it, don't bother looking at protobuf or thrift or
serialization format du jour.

There will be technical debt, or at least there will be things that you
know/think are technical debt that you wish you could have done differently.
But that's the trade off you make. It's not going to be perfect ("perfect is
the enemy of finished", or whatever that line is). The thing to do is make
sure you're making informed decisions, know the tradeoffs, and that you're
comfortable with them _at that time_. This is the only way to make progress,
and progress is the most important thing, especially early on. Later on,
progress will take on a different definition, which may include evaluating
past decisions and recognizing them as technical debt and fixing them up (aka
creating new technical debt).

