4 ms·

I highly agree here. Do not staff a very new startup with junior engineers and expect a good outcome. Furthermore, you absolutely do need to cut corners _somew

I highly agree here. Do not staff a very new startup with junior engineers and expect a good outcome. Furthermore, you absolutely do need to cut corners _somewhere_, but a seasoned team understands that taking on such tech debt will require a reduction in velocity at some point in the near future. It is then incumbent upon engineers to ensure management understands that the team is borrowing from future velocity to deliver quicker, and it's incumbent on management to facilitate remedying that tech debt at the earliest available convenience. If management does not facilitate removing tech debt by allowing for such refactoring/structural work it is then incumbent on engineering to stop offering the shortcuts that temporarily increase velocity, because there's already too much tech debt to be had, and to take on more will reduce velocity unacceptably. A good startup has experienced engineers and experienced managers who understand this dynamic.

raihansaputra 6y ago
Really, really agree. Especially on the last point. Having a small, experienced team is I think the least risky way to build products. Taking the right shortcuts is the big advantage here. Not only about technical debts, but also on reducing planning things to the last detail and reducing overhead on researching best practices for a non-proven stack.
- jrs235 6y ago
  Can you clarify your last sentence? Do you mean not spending too much time planning things out to too much detail?
  - cies 6y ago
    I think what is meant is that a senior can shoot these things more/less from the hip, hence needing less research time.
  - raihansaputra 6y ago
    cies is correct but I'd like to expand the point. A junior engineer (like me) might have encountered tens of systems, and work in less than ten. Senior/more experienced engineers encounter and work in much more. They know which things to implement. For example, let's implement an authentication system for a SaaS. The junior engineer will ask for specs to the brim to avoid missing anything. How to do forget password? Password requirements? Social logins? While the experienced can see the contexts, pick the suitable decision and implement it quickly. They will be more concerned whether the auth will need to support OAuth to smooth out onboarding or to put it off later because their target demographic is more familiar with email/password. These kinds of shortcuts compound to reduce anxiety, increase velocity, and to iterate faster when the product hits the market.
JamesBarney 6y ago
I really wish we had more precise terms for tech debt. For instance I think type/schema debt (where your domain model has changed from your original type/schema debt) is very painful and has a very high interest rate. I think duplicate domain logic has a medium to high interest rate. I think code organization(what methods go where) has a low to medium interest rate. I think white spacing, duplicate non-domain logic and code style has a low interest rate.
- miltondts 6y ago
  Even better if those could be demonstrated by studies/concrete data instead of "I think/feel..."
- tarsinge 6y ago
  My take is that the highest tech debt is never duplication but always abstraction. Duplication make the job tedious and error-prone, but a wrong abstraction in the start and suddenly you have an insurmontable rewrite of everything for the unexpected change or feature that comes in and wasn't envisioned in the beginning. And it'll come, until you have product market fit and are not a startup anymore.
  - ahefner 6y ago
    Agree, and in theory duplication is easy to refactor and clean up, but the nasty thing about duplication is that the instances can diverge in little ways, and then the person cleaning it up may not be able to tell if the differences are meaningful and need to be preserved, or accidents of maintenance.
    - muzani 6y ago
      My current job is cleaning up both kinds of tech debt for a startup. Duplication has created several bugs, but most of them were fixable in a few hours at most, and we finished cleaning them all up within 4 months. Bad abstraction has taken hours to months to clear up and we're still not done.
  - 6y ago

raihansaputra 6y ago

Really, really agree. Especially on the last point. Having a small, experienced team is I think the least risky way to build products. Taking the right shortcuts is the big advantage here. Not only about technical debts, but also on reducing planning things to the last detail and reducing overhead on researching best practices for a non-proven stack.

jrs235 6y ago
Can you clarify your last sentence? Do you mean not spending too much time planning things out to too much detail?
- cies 6y ago
  I think what is meant is that a senior can shoot these things more/less from the hip, hence needing less research time.
- raihansaputra 6y ago
  cies is correct but I'd like to expand the point. A junior engineer (like me) might have encountered tens of systems, and work in less than ten. Senior/more experienced engineers encounter and work in much more. They know which things to implement. For example, let's implement an authentication system for a SaaS. The junior engineer will ask for specs to the brim to avoid missing anything. How to do forget password? Password requirements? Social logins? While the experienced can see the contexts, pick the suitable decision and implement it quickly. They will be more concerned whether the auth will need to support OAuth to smooth out onboarding or to put it off later because their target demographic is more familiar with email/password. These kinds of shortcuts compound to reduce anxiety, increase velocity, and to iterate faster when the product hits the market.

JamesBarney 6y ago

I really wish we had more precise terms for tech debt. For instance I think type/schema debt (where your domain model has changed from your original type/schema debt) is very painful and has a very high interest rate. I think duplicate domain logic has a medium to high interest rate. I think code organization(what methods go where) has a low to medium interest rate. I think white spacing, duplicate non-domain logic and code style has a low interest rate.

miltondts 6y ago
Even better if those could be demonstrated by studies/concrete data instead of "I think/feel..."
tarsinge 6y ago
My take is that the highest tech debt is never duplication but always abstraction. Duplication make the job tedious and error-prone, but a wrong abstraction in the start and suddenly you have an insurmontable rewrite of everything for the unexpected change or feature that comes in and wasn't envisioned in the beginning. And it'll come, until you have product market fit and are not a startup anymore.
- ahefner 6y ago
  Agree, and in theory duplication is easy to refactor and clean up, but the nasty thing about duplication is that the instances can diverge in little ways, and then the person cleaning it up may not be able to tell if the differences are meaningful and need to be preserved, or accidents of maintenance.
  - muzani 6y ago
    My current job is cleaning up both kinds of tech debt for a startup. Duplication has created several bugs, but most of them were fixable in a few hours at most, and we finished cleaning them all up within 4 months. Bad abstraction has taken hours to months to clear up and we're still not done.
- 6y ago