4 ms·

This is why it's important that early team members are experienced engineers. They know which corners should be cut today to get the prototype out, and which sh

This is why it's important that early team members are experienced engineers. They know which corners should be cut today to get the prototype out, and which shouldn't because they'll take 30 mins to do "properly" and save a day of work before the runway is even up. I work in a small company that has all the things the author mentioned and that can work quickly as a result. Almost none of it comes from "we'll do it this way", almost all has evolved over time as we've been able to gradually introduce more rigour to our development process. Much is down to some great engineers at the beginning setting us on that path.

rezonant 6y ago
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
eitally 6y ago
I suggest it's frequently less about knowing which corners to cut, and more about knowing hard from easy, to avoid future impedance mismatches between eng & sales/marketing (or even internal business leadership). One of the very most frustrating things for an exec is downtime. The next worst is inaccurate time estimates for IT work. If you don't have at least some experienced architects/developers, it's normal to find yourself in the position where nobody knows what they don't know, and that's a bad look for everyone involved. It's also why a lot of bigco's have been outsourcing internal appdev to MSPs over the last 10+ years. It de-risks projects, eliminates skilled labor shortages, and ensures reasonable QoS... in theory. It doesn't always work out that way, but that's the objective.
danjac 6y ago
Experienced engineers are hard to get though, unless they are founders themselves. Early-stage startups tend to rely on the cheapest engineers they can find, and only hire more experienced devs when they've accumulated a pile of technical debt and poor decisions.
- Zenbit_UX 6y ago
  That's why who your technical partner is is so important. Pick someone smart who you wouldn't be able to afford otherwise or pay for it now and later.

rezonant 6y ago

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

eitally 6y ago

I suggest it's frequently less about knowing which corners to cut, and more about knowing hard from easy, to avoid future impedance mismatches between eng & sales/marketing (or even internal business leadership). One of the very most frustrating things for an exec is downtime. The next worst is inaccurate time estimates for IT work. If you don't have at least some experienced architects/developers, it's normal to find yourself in the position where nobody knows what they don't know, and that's a bad look for everyone involved. It's also why a lot of bigco's have been outsourcing internal appdev to MSPs over the last 10+ years. It de-risks projects, eliminates skilled labor shortages, and ensures reasonable QoS... in theory. It doesn't always work out that way, but that's the objective.

danjac 6y ago

Experienced engineers are hard to get though, unless they are founders themselves. Early-stage startups tend to rely on the cheapest engineers they can find, and only hire more experienced devs when they've accumulated a pile of technical debt and poor decisions.

Zenbit_UX 6y ago
That's why who your technical partner is is so important. Pick someone smart who you wouldn't be able to afford otherwise or pay for it now and later.