3 ms·

Sometimes I feel I'm the only person who thinks tech debt is not that difficult to solve. Everything needed to be solved is under your control. It may take tim

by tanin 4y ago

Sometimes I feel I'm the only person who thinks tech debt is not that difficult to solve. Everything needed to be solved is under your control. It may take time and be boring, but you have everything you need to solve it. Product-market-fit, customer acquisition, and etc. are often much more urgent/difficult to solve, and we should focus on those first. What I've seen in a lot of teams is tech debt (or speculative tech debt if we move quickly) is exaggerated to the point that they cannot launch quickly to acquire and iterate with customers, which is a huge mistake in product development.

intelVISA 4y ago
I'm fond of: v1 - shitshow for product market fit, deliberately debt heavy for speed/iteration v2 - from the ashes, this is what v1 should've been, emphasis on the long-term You've already done the hardest bit (imo) by figuring out the kludge blueprint that is v1 it's reasonably easy to build v2 with the lessons learned from v1 fresh in mind. Of course, v1 is the default model in most shops and there is no v2.
- tanin 4y ago
  That is a good way of development. In a lot of the times, there is no V2 due to 1 of the 2 states: 1. V1 is too successful. You cannot slow down the growth. It is bad, but not as bad as people make it out to be. Many startups are trying very hard to be in this state. 2. V1 fails, so there is no point for V2. In a large company, there is an additional state: long term ownership is hard. By the time, we should implement V2. The original team is already promoted for PMF and move on to a new shiny project. The new team would just complain tirelessly about the tech debt because obviously they aren't getting the reward and are stuck with a shit job. Now nobody would advocate for this way again. Not sure why my argument now turns the opposite direction.
  - intelVISA 4y ago
    There wouldn't be tech debt for v2 is the point: it'd be from scratch code-wise whilst applying the design/architecture lessons learned. A lot of tech decisions are only apparent after the project is built - revealing them with a rapid protoype and then scrapping it to build "what should have been". Ultimately, as you say, it is pointless as there is little business incentive to work like this as most customers would gladly accept the crappy prototype as final.

by tanin 4y ago

intelVISA 4y ago

I'm fond of: v1 - shitshow for product market fit, deliberately debt heavy for speed/iteration v2 - from the ashes, this is what v1 should've been, emphasis on the long-term You've already done the hardest bit (imo) by figuring out the kludge blueprint that is v1 it's reasonably easy to build v2 with the lessons learned from v1 fresh in mind. Of course, v1 is the default model in most shops and there is no v2.

tanin 4y ago
That is a good way of development. In a lot of the times, there is no V2 due to 1 of the 2 states: 1. V1 is too successful. You cannot slow down the growth. It is bad, but not as bad as people make it out to be. Many startups are trying very hard to be in this state. 2. V1 fails, so there is no point for V2. In a large company, there is an additional state: long term ownership is hard. By the time, we should implement V2. The original team is already promoted for PMF and move on to a new shiny project. The new team would just complain tirelessly about the tech debt because obviously they aren't getting the reward and are stuck with a shit job. Now nobody would advocate for this way again. Not sure why my argument now turns the opposite direction.
- intelVISA 4y ago
  There wouldn't be tech debt for v2 is the point: it'd be from scratch code-wise whilst applying the design/architecture lessons learned. A lot of tech decisions are only apparent after the project is built - revealing them with a rapid protoype and then scrapping it to build "what should have been". Ultimately, as you say, it is pointless as there is little business incentive to work like this as most customers would gladly accept the crappy prototype as final.