4 ms·

"They know that they’re going to have to manufacture endless explanations for why seemingly simple things take them a long time." This is what kills me. You ca

by blunte 10y ago

"They know that they’re going to have to manufacture endless explanations for why seemingly simple things take them a long time." This is what kills me. You can't say to the boss, "Your beloved senior dev built this arcane and fragile system, so everything I do takes forever." Instead you have to find diplomatic/meaningless explanations for why you're moving so slowly.

quantumhobbit 10y ago
I've found that I can win over my immediate superiors with low level grumbling about real technical issues in the code base. They eventually internalize the state of the code base and have realistic expectations for how long things will take. The key is to diplomatically voice all your WTF moments, and have a boss technical enough to get it. Problem is their bosses still think that the spaghettified joke that is the internal framework we have to use is manna from heaven and would take a very dim view of anyone caught trashing it in the open.
michaelfeathers 10y ago
I'm convinced that the issue overall is lack of transparency about design quality. In an org with non-technical leadership, technical staff should periodically present assessments of their systems' readiness for change. Non-tech people need to understand technical debt and see how it changes over time. In my experience, companies with technical founders tend to have cultures that handle this issue better.
- richmarr 10y ago
  > ...lack of transparency about design quality Totally agree. Technical debt isn't a problem as long as the team has good communication & low levels of political behaviour. IMO articles like this that paint Tech Debt as a universally negative thing (without trying to balance the view, or mention the context in which the tech exists) do more harm than good. Update: Recommend reading "5 Dysfunctions of a Team" for guidance on improving communication and reducing political behaviour in an organisation.
  - PaulHoule 10y ago
    Funny I get the opposite take on this article in terms of meaning, yet I still think it is off base. "Technical Debt" is a dangerous analogy because most of what people call technical debt would best be called "ignorance" or "wishful thinking". Debt is a complex social invention that includes methods of accounting, a repayment schedule, etc. MBA types will have to negotiate with banks, senior executives, the board, etc. about the debt taken on by a corporation. Worse yet, ignorance often takes the form of overengineering, so what is done in the name of "saving time now" is often completely wasted.
    - mattkrause 10y ago
      >a complex social invention that includes methods of accounting, a repayment schedule, etc. Isn't that the point? There are similar reasons to take on real and technical debt, like expanding into a new market. You also come up with a "repayment schedule" for technical debt, which involves allocating time for checking/updating the documentation, refactoring code, etc. Some people use "technical debt" to mean "no one knows how this works", but I think the actual debt there is in the documentation or the lousy quality of the code, not the ignorance.
    - michaelfeathers 10y ago
      It's a metaphor and it can definitely be taken too far. One of the abuses I don't care for is the notion that Technical Debt can be quantified and calculated for a code base. That's wrong in a number of different ways.
      - OpenDrapery 10y ago
        Agreed. It's another instance of making a tech to finance analogy that just doesn't hold up. It's really nice when you can just put a number on something. And it really sucks when you can't, but that doesn't prevent people from trying. Why does the sales guy get to go play golf after closing a big deal? And yet the developer still has to show up and sit in his seat after he performs some equivalent wizardry? Because the sales guy's effort has a number attached to it, that's why.
bradleyjg 10y ago
From the bosses' point of view it is very difficult to tell the difference between "we have a crap codebase" and "the new guy sucks at reading code and is going to want to rewrite everything he touches".
- whack 10y ago
  If 5 different people are all saying the same thing, that makes it a lot easier.
  - clifanatic 10y ago
    > that makes it a lot easier. Should make it.
  - marcosdumay 10y ago
    It's not rare that a company hires 5 bad developers (or more) for each 1 good one.

by blunte 10y ago

quantumhobbit 10y ago

I've found that I can win over my immediate superiors with low level grumbling about real technical issues in the code base. They eventually internalize the state of the code base and have realistic expectations for how long things will take. The key is to diplomatically voice all your WTF moments, and have a boss technical enough to get it. Problem is their bosses still think that the spaghettified joke that is the internal framework we have to use is manna from heaven and would take a very dim view of anyone caught trashing it in the open.

michaelfeathers 10y ago

I'm convinced that the issue overall is lack of transparency about design quality. In an org with non-technical leadership, technical staff should periodically present assessments of their systems' readiness for change. Non-tech people need to understand technical debt and see how it changes over time. In my experience, companies with technical founders tend to have cultures that handle this issue better.

richmarr 10y ago
> ...lack of transparency about design quality Totally agree. Technical debt isn't a problem as long as the team has good communication & low levels of political behaviour. IMO articles like this that paint Tech Debt as a universally negative thing (without trying to balance the view, or mention the context in which the tech exists) do more harm than good. Update: Recommend reading "5 Dysfunctions of a Team" for guidance on improving communication and reducing political behaviour in an organisation.
- PaulHoule 10y ago
  Funny I get the opposite take on this article in terms of meaning, yet I still think it is off base. "Technical Debt" is a dangerous analogy because most of what people call technical debt would best be called "ignorance" or "wishful thinking". Debt is a complex social invention that includes methods of accounting, a repayment schedule, etc. MBA types will have to negotiate with banks, senior executives, the board, etc. about the debt taken on by a corporation. Worse yet, ignorance often takes the form of overengineering, so what is done in the name of "saving time now" is often completely wasted.
  - mattkrause 10y ago
    >a complex social invention that includes methods of accounting, a repayment schedule, etc. Isn't that the point? There are similar reasons to take on real and technical debt, like expanding into a new market. You also come up with a "repayment schedule" for technical debt, which involves allocating time for checking/updating the documentation, refactoring code, etc. Some people use "technical debt" to mean "no one knows how this works", but I think the actual debt there is in the documentation or the lousy quality of the code, not the ignorance.
  - michaelfeathers 10y ago
    It's a metaphor and it can definitely be taken too far. One of the abuses I don't care for is the notion that Technical Debt can be quantified and calculated for a code base. That's wrong in a number of different ways.
    - OpenDrapery 10y ago
      Agreed. It's another instance of making a tech to finance analogy that just doesn't hold up. It's really nice when you can just put a number on something. And it really sucks when you can't, but that doesn't prevent people from trying. Why does the sales guy get to go play golf after closing a big deal? And yet the developer still has to show up and sit in his seat after he performs some equivalent wizardry? Because the sales guy's effort has a number attached to it, that's why.

bradleyjg 10y ago

From the bosses' point of view it is very difficult to tell the difference between "we have a crap codebase" and "the new guy sucks at reading code and is going to want to rewrite everything he touches".

whack 10y ago
If 5 different people are all saying the same thing, that makes it a lot easier.
- clifanatic 10y ago
  > that makes it a lot easier. Should make it.
- marcosdumay 10y ago
  It's not rare that a company hires 5 bad developers (or more) for each 1 good one.