Hacker News new | ask | show | jobs
by kartickv 2048 days ago
Author here.

> Fast forward almost a decade

If your system lasted a decade, that's a success, and any startup that just started would love to be in your shoes.

> management still doesn't understand the concept of "overwhelming technical debt".

That's a problem with your company, not with the suggestion in my post of adding in layers of abstraction when needed rather than ahead of time.
2 comments
Netcob 2048 days ago
I'm not saying they weren't successful. As someone who tends to over-engineer things, I do admire their ability to get a product out quickly - I think for a startup that was probably the right decision!

But that's what I've been missing from your article - more on the distinction between the approaches, and the drawbacks of having a thin back-end layer as the product / company is growing. In the beginning I thought you were talking about how to make your startup more efficient and flexible - basically consciously building some technical debt, having weighed your options.

But if that's not the idea - personally I don't know how to scale with this approach, neither technologically nor in terms of team structure. The thin back end layer could work though if you have a lot of small products that are independent of each other - developed by small teams that can afford to act like early startups. Maybe that's what you meant, but I didn't really get that from the article.

link
onei 2048 days ago
I get that you've disagreed with almost every point telling you this is a bad idea, but I think the point is particularly pertinent.

They tried this system, and then realised they painted themselves into a corner. Businesses wants features they can sell to customers, and sometimes fixing technical debt is a luxury. Especially when technical debt hidden to customers.

Adding layers of abstraction when needed might sound like great advice to a startup that needs money ASAP. But down the line when requirements change, maybe those layers of abstraction cost too much time to implement, especially if you're firefighting a dozen other poor choices.

link