4 ms·

Early tech decisions can become myopic in the long run. If you're not careful and admit that you made quick decisions early on these early decisions can become

Early tech decisions can become myopic in the long run. If you're not careful and admit that you made quick decisions early on these early decisions can become entrenched as gospel. This can alienate later, more experienced developers and become a factor in burnout as they are forced to deal with, "this is how we do things around here." One way to deal with tech debt is to take advantage of the experience and skill of your developers and embrace change. You might not want to be switching databases every time someone suggests, "X is better than Y," for sure! Inertia has its uses. But you don't want to stagnate either. Conclusion of tfa is solid: the truth is somewhere in the middle. The keyword for me is sufficient: the local minimum that meets all of our requirements. If we need to be able to be able to ship changes faster and it takes weeks to get changes merged, something is not sufficient in our stack/process/etc.

synu 4y ago
It can be helpful to write down the context of why you made your decision, so that if/when you revisit it later it’s more clear. ADRs are one way to do this: https://adr.github.io/madr/ https://adr.github.io/madr/
- agentultra 4y ago
  Great advice. I also use learning milestones to manage our novelty budget and record our findings/decisions/context/etc. I don't know if this is formalized or written down anywhere. The idea is that when your team wants to try something and learn from it you record down your thoughts and ideas into a document. You then have a triggering condition in that document for when to review it later. When you do the review you record what you learned and what decisions you make as a result. Over time your teams build up little libraries of these learnings and it can help build organizational continuity. People come and go, leaving teams or the company, joining other teams, etc. It's a good practice to avoid having to re-transmit what your organization has learned through re-telling folk-lore.
- troelsSteegin 4y ago
  Short of something structured, any format that captures key assumptions and intentions is good. The problem we are solving is X. The "pre-mortem" is the idea is that if we fail, it would be because of Y. Then in your design or decision, you address Y as a contingency. The collateral idea for code would be "good until" - this is good until (we expect) some threshold.
- hinkley 4y ago
  I've run into at least a few people who can't understand why my answer changes when the context changes. I said we were going to do A because of C, D and E. Why are you acting like it's a gotcha when we find out E doesn't apply anymore and now I agree B is a better option? Did you think we were joking when we said, "It depends"?
BurningFrog 4y ago
One solution is to design things so swapping out one component isn't harder than it needs to be. Easier said than done, but still quite doable with modular design, which you should do anyway.
- 8n4vidtmkvmk 4y ago
  that's also how we end up with an excessive number of microservices
hinkley 4y ago
Some of the most uselessly toxic behavior is defending X now because it was critical to our survival 3 years ago. This world is absolutely rife with ideas, actions and substances that are appropriate to a situation but are detrimental or even deadly once that moment has passed. Oxy because of a bone graft is not the same as Oxy because it's a Tuesday. We aren't questioning your wisdom because you did this thing three years ago. We are questioning your wisdom because you won't let us kill it right now.
dilyevsky 4y ago
There’s a flip side to this when people who come later totally underestimate the problem space and difficulty when trying to “fix” things.
- agentultra 4y ago
  Definitely and highlights another reason why it’s important to document these things for future maintainers and developers.
  - dilyevsky 4y ago
    Good in theory but in practice nobody is going to have the time to document every one of hundreds (or thousands) little decisions with potentially large implications while trying to keep the product afloat. Even for those they do, in my experience, nobody bothers to read them...
    - agentultra 4y ago
      Can’t help people who don’t want to help themselves.
      - dilyevsky 4y ago
        It’s true but it’s worth keeping in mind that there are some underwater rocks that OGs didn’t tell anyone bc they had better things to do
aledalgrande 4y ago
Had to deal with this in the past, where junior engs made choices on the initial architecture and by the time I joined they were in management/high roles. They refused any change that was too complicated for them to understand and never tried to improve their knowledge. Meantime our team was suffering under the load of technical debt vs non technical POs wanting to dish out features experiments fast. > this is how we do things around here resonates so much

synu 4y ago

It can be helpful to write down the context of why you made your decision, so that if/when you revisit it later it’s more clear. ADRs are one way to do this: https://adr.github.io/madr/ https://adr.github.io/madr/

agentultra 4y ago
Great advice. I also use learning milestones to manage our novelty budget and record our findings/decisions/context/etc. I don't know if this is formalized or written down anywhere. The idea is that when your team wants to try something and learn from it you record down your thoughts and ideas into a document. You then have a triggering condition in that document for when to review it later. When you do the review you record what you learned and what decisions you make as a result. Over time your teams build up little libraries of these learnings and it can help build organizational continuity. People come and go, leaving teams or the company, joining other teams, etc. It's a good practice to avoid having to re-transmit what your organization has learned through re-telling folk-lore.
troelsSteegin 4y ago
Short of something structured, any format that captures key assumptions and intentions is good. The problem we are solving is X. The "pre-mortem" is the idea is that if we fail, it would be because of Y. Then in your design or decision, you address Y as a contingency. The collateral idea for code would be "good until" - this is good until (we expect) some threshold.
hinkley 4y ago
I've run into at least a few people who can't understand why my answer changes when the context changes. I said we were going to do A because of C, D and E. Why are you acting like it's a gotcha when we find out E doesn't apply anymore and now I agree B is a better option? Did you think we were joking when we said, "It depends"?

BurningFrog 4y ago

One solution is to design things so swapping out one component isn't harder than it needs to be. Easier said than done, but still quite doable with modular design, which you should do anyway.

8n4vidtmkvmk 4y ago
that's also how we end up with an excessive number of microservices

hinkley 4y ago

Some of the most uselessly toxic behavior is defending X now because it was critical to our survival 3 years ago. This world is absolutely rife with ideas, actions and substances that are appropriate to a situation but are detrimental or even deadly once that moment has passed. Oxy because of a bone graft is not the same as Oxy because it's a Tuesday. We aren't questioning your wisdom because you did this thing three years ago. We are questioning your wisdom because you won't let us kill it right now.

dilyevsky 4y ago

There’s a flip side to this when people who come later totally underestimate the problem space and difficulty when trying to “fix” things.

agentultra 4y ago
Definitely and highlights another reason why it’s important to document these things for future maintainers and developers.
- dilyevsky 4y ago
  Good in theory but in practice nobody is going to have the time to document every one of hundreds (or thousands) little decisions with potentially large implications while trying to keep the product afloat. Even for those they do, in my experience, nobody bothers to read them...
  - agentultra 4y ago
    Can’t help people who don’t want to help themselves.
    - dilyevsky 4y ago
      It’s true but it’s worth keeping in mind that there are some underwater rocks that OGs didn’t tell anyone bc they had better things to do

aledalgrande 4y ago

Had to deal with this in the past, where junior engs made choices on the initial architecture and by the time I joined they were in management/high roles. They refused any change that was too complicated for them to understand and never tried to improve their knowledge. Meantime our team was suffering under the load of technical debt vs non technical POs wanting to dish out features experiments fast. > this is how we do things around here resonates so much