5 ms·

Stop talking to business about technical debt. Stop creating technical debt. No one ever asked me why in particular something took 3 days. I don't explain to

by Tretio 5y ago

Stop talking to business about technical debt. Stop creating technical debt. No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests. Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written? If you accept technical debt it's the development teams fault. And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt. Instead lern to talk back: "oh you promised our customer that this feature will be ready tomorrow? I'm seeing a big risk in this as there are still issues we haven't figured out, you might want to manage their expectation." "Ah sry I can't work longer today I already have a reservation" "On the weekend? Mh I booked a hotel already" "How long this takes? Mh let's see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update." "I can prioritize your new request but I will talk to x to tell him that his task will be delayed." "Didn't you promise customer x feature y already? Should I stop working on y to start with your new request?"

EugeneOZ 5y ago
Sorry, but how old are you? Add the line “stop creating bugs” into this text to make it complete.
- Tretio 5y ago
  I'm 34 and work like this, successful for 12 years. I have a min. Standard I achieve and will not compromise this standard to keep me sane. I will not create things which will fall back to me in 3 month. I develop slower but have to revisit things rarely.
  - EugeneOZ 5y ago
    And you are working alone and on the new codebases only and your code is perfect from the beginning and you are not discovering better ways with time. I got it ;)
    - samhw 5y ago
      These are the people we avoid like the plague when hiring: people who are obsessed with the intrinsic beauty of their code, rather than its business utility. They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say, an MVP feature with a 70% chance of being ditched.
      - EugeneOZ 5y ago
        We were talking about another topic. “Temporary dirty MVPs” are only acceptable if their code will be completely thrown away. Otherwise, “there is nothing more permanent than temporary patches” (c) forgot who.
        samhw 5y ago
        Yeah, certainly the tech debt code should be thrown away. I think this is hard to discuss without a concrete example in mind, though. Or rather without both having the same concrete example in mind. I get the sense that everyone here is imagining their own - very different - concrete example of tech debt, and talking entirely at cross purposes as a result.
        EugeneOZ 5y ago
        If the foundation, base of the project is quickly created just for MVP - it should be rewritten. If just some of the small parts were created without care - then throwing them away is not a problem.
        samhw 5y ago
        I really need to emphasise, 'tech debt' does not imply 'without care'. Just to link to the last comment where I emphasised this: https://news.ycombinator.com/item?id=30286955 https://news.ycombinator.com/item?id=30286955 This is why I say it's fruitless to discuss this without making clear what concrete examples we're imagining when we say 'tech debt'. I'm almost certain that you and I are not thinking of remotely the same thing. 'Tech debt' is very different from plain old shitty code.
samhw 5y ago
The point of technical debt is that you don't want to invest an amount of time appropriate for [long-term business-critical feature which will be built upon] into something which is currently [basic experimental feature which may well be ditched]. When the latter is validated and becomes the former, that's when - and why - you repay your tech debt. A team that builds everything as though it were a business-critical feature, which needs to be architected as safely as the control loop on a rocket, is a business which is pathologically unable to experiment and iterate.
- Tretio 5y ago
  I'm not writing prototype Software. Everything will find its way back to you. Bugs are very costly. I always make sure I für understand what the problem is. This can lead to me having discussions of 2-3 h and the outcome is that we actually don't need it. Or that we reduce the scope to deliver on time. I'm not aware of things I write which will not bite me back one way or the other if I'm doing it shitty and having development standards is not developing a rocket.
  - samhw 5y ago
    Well, that seems like a wasteful amount of time to spend on prototype products or functionality. It's up to you if you want to do that, but other people will likely out-manoeuvre you by being agile enough to iterate quickly.
    - Tretio 5y ago
      I did not say that I'm slow due to this or not agile. But I will not build a sync feature and not having alerting if it fails. I will not write nee Features and will not think about a proper index. If you do it right and actually learn those things from an early point those things become obvious. And yes there is also that believe that a bug in production costs 10x what it would cost to find while developing. Yes I'm aware of the fallacy that a manager might praise you if you are fast and accepts bug as a common normal thing.
chrisweekly 5y ago
Agreed. But what is "Mh"?
- Tretio 5y ago
  It's a written sound like hmmm humming
  - chrisweekly 5y ago
    Ok, thanks. FWIW, I'm 47yo, a former TEFL teacher, I pay attention to language, and I've literally never encountered "Mh" before. Hmm...
almostdeadguy 5y ago
There's (at least) three causes of technical debt that aren't due to engineering negligence (but I agree in general that many sources of "technical debt" are self-inflicted): 1. Domain modeling shifts. Engineers get a sample of the business rules for the domain they're trying to model every time they build a feature, but it's an incomplete picture. And in fact sometimes the very nature of what the business is trying to accomplish changes. That can require fundamental shifts in how the problem is modeled. 2. Changes of scale. What was engineered to support 10,000 MAU will not necessarily tolerate 100M MAU. Scale can be insidious for tech debt because it's often a slower creep of a problem w/ a high cliff in the amount of effort required to solve for it. 3. Planning/communication failures. Sometimes a critical aspect of a feature is not fully understood or articulated. Or an important delivery date for a promise is overlooked. Depending on the nature of the company's business, an early stage company often doesn't have a choice but to deliver on things that weren't properly scheduled.

by Tretio 5y ago

EugeneOZ 5y ago

Sorry, but how old are you? Add the line “stop creating bugs” into this text to make it complete.

Tretio 5y ago
I'm 34 and work like this, successful for 12 years. I have a min. Standard I achieve and will not compromise this standard to keep me sane. I will not create things which will fall back to me in 3 month. I develop slower but have to revisit things rarely.
- EugeneOZ 5y ago
  And you are working alone and on the new codebases only and your code is perfect from the beginning and you are not discovering better ways with time. I got it ;)
  - samhw 5y ago
    These are the people we avoid like the plague when hiring: people who are obsessed with the intrinsic beauty of their code, rather than its business utility. They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say, an MVP feature with a 70% chance of being ditched.
    - EugeneOZ 5y ago
      We were talking about another topic. “Temporary dirty MVPs” are only acceptable if their code will be completely thrown away. Otherwise, “there is nothing more permanent than temporary patches” (c) forgot who.
      - samhw 5y ago
        Yeah, certainly the tech debt code should be thrown away. I think this is hard to discuss without a concrete example in mind, though. Or rather without both having the same concrete example in mind. I get the sense that everyone here is imagining their own - very different - concrete example of tech debt, and talking entirely at cross purposes as a result.
        EugeneOZ 5y ago
        If the foundation, base of the project is quickly created just for MVP - it should be rewritten. If just some of the small parts were created without care - then throwing them away is not a problem.
        samhw 5y ago
        I really need to emphasise, 'tech debt' does not imply 'without care'. Just to link to the last comment where I emphasised this: https://news.ycombinator.com/item?id=30286955 https://news.ycombinator.com/item?id=30286955 This is why I say it's fruitless to discuss this without making clear what concrete examples we're imagining when we say 'tech debt'. I'm almost certain that you and I are not thinking of remotely the same thing. 'Tech debt' is very different from plain old shitty code.

samhw 5y ago

The point of technical debt is that you don't want to invest an amount of time appropriate for [long-term business-critical feature which will be built upon] into something which is currently [basic experimental feature which may well be ditched]. When the latter is validated and becomes the former, that's when - and why - you repay your tech debt. A team that builds everything as though it were a business-critical feature, which needs to be architected as safely as the control loop on a rocket, is a business which is pathologically unable to experiment and iterate.

Tretio 5y ago
I'm not writing prototype Software. Everything will find its way back to you. Bugs are very costly. I always make sure I für understand what the problem is. This can lead to me having discussions of 2-3 h and the outcome is that we actually don't need it. Or that we reduce the scope to deliver on time. I'm not aware of things I write which will not bite me back one way or the other if I'm doing it shitty and having development standards is not developing a rocket.
- samhw 5y ago
  Well, that seems like a wasteful amount of time to spend on prototype products or functionality. It's up to you if you want to do that, but other people will likely out-manoeuvre you by being agile enough to iterate quickly.
  - Tretio 5y ago
    I did not say that I'm slow due to this or not agile. But I will not build a sync feature and not having alerting if it fails. I will not write nee Features and will not think about a proper index. If you do it right and actually learn those things from an early point those things become obvious. And yes there is also that believe that a bug in production costs 10x what it would cost to find while developing. Yes I'm aware of the fallacy that a manager might praise you if you are fast and accepts bug as a common normal thing.

chrisweekly 5y ago

Agreed. But what is "Mh"?

Tretio 5y ago
It's a written sound like hmmm humming
- chrisweekly 5y ago
  Ok, thanks. FWIW, I'm 47yo, a former TEFL teacher, I pay attention to language, and I've literally never encountered "Mh" before. Hmm...

almostdeadguy 5y ago

There's (at least) three causes of technical debt that aren't due to engineering negligence (but I agree in general that many sources of "technical debt" are self-inflicted): 1. Domain modeling shifts. Engineers get a sample of the business rules for the domain they're trying to model every time they build a feature, but it's an incomplete picture. And in fact sometimes the very nature of what the business is trying to accomplish changes. That can require fundamental shifts in how the problem is modeled. 2. Changes of scale. What was engineered to support 10,000 MAU will not necessarily tolerate 100M MAU. Scale can be insidious for tech debt because it's often a slower creep of a problem w/ a high cliff in the amount of effort required to solve for it. 3. Planning/communication failures. Sometimes a critical aspect of a feature is not fully understood or articulated. Or an important delivery date for a promise is overlooked. Depending on the nature of the company's business, an early stage company often doesn't have a choice but to deliver on things that weren't properly scheduled.