[xondono]

I disagree.

Building complex solutions that you don't really need is also "bad engineering". Part of the complexity comes from the fact that the needs that software projects solve are not fixed, they change during the products life cycle.

Even architects use technical debt, it just comes in different ways. Instead of trying to plan what every room is for, architects leave empty sections, to be determined later. A lot of buildings have little spaces reconverted to closets just because there was leftover space there. That's technical debt, you know the "best approach" (according to waterfall engineering) would be to find out how things will work and then build it, but you'd rather write "IOU" on that section and move on to the important bits. You can then solve the kinks with plasterboard.

The best example of technical debt is code that doesn't scale. You know you should write your code to support 1M users, but you currently have ~100 users. Instead of spending a month serving 990k users you don't have, I would say it's good engineering to solve the problem for say 10k users if that means you'll spend a week, and have the rest of the time to solve other more pressing concerns.

[dub]

Seems like you feel that establishing data access patterns that have the possibility of scaling up to 100x more users requires an additional 3 weeks of initial developer time

I'm not sure I agree that an engineer experienced in building scalable systems will need 3 extra weeks to pick a schema and data access pattern that's scalable.

You don't have to actually _use_ spanner or cockroach or vitess in your initial prototype if you don't want to, but it seems entirely reasonable to have an _idea_ of what the story would look like to migrate to a horizontally-scalable approach if product gains traction so it doesn't end up being a multi-year project later.

[shynrou]

Most teams I have encountered so far don't have an anyone that experienced with scalable database systems. So you have to choose the best you can do at that moment without loosing your momentum. When more users come more funding will come and you can hire someone who can repay the technical dept chosen before.

[dub]

Agreed that it's a result of not having people experienced with building systems at scale.

That's not a technical choice since the person writing code wasn't aware of the options, so it's a business choice. How good of a business choice is it, though?

We all know at some level that a well-intentioned but inexperienced engineer can make a decision in an afternoon that will take weeks or years to clean up. I often see junior engineers spend several days over-engineering something that a senior engineer would have done simpler and better in a fraction of the time. I don't think it's a given that junior engineers provide better return on investment early on that a senior engineer.

Getting some worthwhile feedback and advice from a seasoned engineer doesn't need to cost a fortune in up-front cash, and personally I think it'll pay for itself. You either compensate them with stock or hire them as a temporary or part time consultant.

[q-big]

> When more users come more funding will come and you can hire someone who can repay the technical de[b]t chosen before.

The problem is rather that the technical debt is often not repaid.