4 ms·

That is probably true to a degree but IMO we make brutal decisions about code when we have to and get it wrong and so on. Why when it comes to organising peopl

by t43562 3y ago

That is probably true to a degree but IMO we make brutal decisions about code when we have to and get it wrong and so on. Why when it comes to organising people into some effort would we not have brutal decisions to make and get them wrong? Why expose yourself to blame when you could hide in the group? It's going to take ambition, desire, hard headedness, reward etc to make anyone do such an undesirable thing. The higher and more risky it gets the more tough people probably need to be. It's also a lot easier to be selfish and tough than caring and tough so there's a larger supply of bastards to be in charge than empathetic and kind but still somehow tough people who can take the nasty decisions.

torginus 3y ago
Lol this is all a smokescreen. Let me give you an analogy. There are 3 people in a car, one driver, one navigator, one manager. The manager provides 'oversight' and 'takes responsibility'. If they crash whose fault will it be? The answer is always the drivers' You cannot be held responsible for things that you have no direct control over. In software, if the infra goes down, who will need to fix it? Developers. If a feature is particularly tricky and technically challenging, who is responsible for getting out of a rut? The answer is the developers. Things like fixing a tricky bug in a million line lib I didn't write (IRL example). Managers can use the carrot and the stick, bring in more resources, communicate the developers pains upwards, but most likely they cannot do anything directly that will bring about success. To be clear if done properly, this can be helpful, but to say that they are under more stress and responsibility than ICs is just untrue, considering they literally cannot do anything to resolve the origin of said stress (see car analogy).
- throwaway828 3y ago
  The car occupants clearly didn't pay Boston Consulting Group or McKinsey to come up with an optimum span of control, as they'd surely been advised a management role wasn't necessary in a 2 person team. On the other hand, a tank with 5-8 functional roles does have the role of tank commander.
- epups 3y ago
  If the manager is responsible for hiring and managing the driver and the navigator, then obviously they can also be under stress, and will be held responsible for the outcome.
- t43562 3y ago
  The manager should almost always get the blame. Why didn't they get help from another team, why didn't they supervise that dev more carefully, how did the bug get into the code in the first case and were proper test procedures followed. Has there been a history of mistakes which show a pattern that's not being managed etc etc. Ultimately the CTO is responsible to the board for why a problem damaged the business (even if it was all the mistake of a developer somehow). And the board to the shareholders for losing money. In reality people, of course, try as hard as possible to evade blame or lay it elsewhere but in theory a developer who makes a big mistake should not have been in a position to do that damage solo and it's a fault in the system if they were able to - and in the people responsible for the system.
  - torginus 3y ago
    'Agile' has built-in ways of shirking management responsibility. When a developer is asked to solve some eldritch problem, it often goes: - How long will this take? - I don't know. This is very complex and I'm not familiar with the code. - You HAVE to know, we HAVE to plan for it. - Okay, then 5 days. - Hey 5 days has passed, why isn't this done yet? - I underestimated the complexity of the task. - Ah, so YOU estimated wrong, so it's YOUR fault! Hard problems exist. They can only be solved by hard-work and expertise and even then solve times are unpredictable and draining to the individual and are thankless endeavors. Management tries to paper over that, but this is a fundamental invariant of life. The fact that management makes solving these problems feel like punishment, only makes people try to avoid these problems more.
    - t43562 3y ago
      I heartily agree that the problems are hard and unpredictable things don't get made predictable by a method. I think, however, if you're in a company with bastards who don't care they will find out how to screw agile just as they screwed the scheme before that. In the waterfall projects the example you gave is just the same. In your example "I don't know, it's very complex" should lead to a spike where you have a chance to find out more. Then you'd give a high complexity estimate and everyone would try to think of ways to chip off a bit of the problem at a time. You're also trying to get your whole team to think about what can be done rather than each developer facing horrible problems alone. But if you're managed by arseholes then even the most positive ideas tend to get turned into nightmares.

by t43562 3y ago

torginus 3y ago

Lol this is all a smokescreen. Let me give you an analogy. There are 3 people in a car, one driver, one navigator, one manager. The manager provides 'oversight' and 'takes responsibility'. If they crash whose fault will it be? The answer is always the drivers' You cannot be held responsible for things that you have no direct control over. In software, if the infra goes down, who will need to fix it? Developers. If a feature is particularly tricky and technically challenging, who is responsible for getting out of a rut? The answer is the developers. Things like fixing a tricky bug in a million line lib I didn't write (IRL example). Managers can use the carrot and the stick, bring in more resources, communicate the developers pains upwards, but most likely they cannot do anything directly that will bring about success. To be clear if done properly, this can be helpful, but to say that they are under more stress and responsibility than ICs is just untrue, considering they literally cannot do anything to resolve the origin of said stress (see car analogy).

throwaway828 3y ago
The car occupants clearly didn't pay Boston Consulting Group or McKinsey to come up with an optimum span of control, as they'd surely been advised a management role wasn't necessary in a 2 person team. On the other hand, a tank with 5-8 functional roles does have the role of tank commander.
epups 3y ago
If the manager is responsible for hiring and managing the driver and the navigator, then obviously they can also be under stress, and will be held responsible for the outcome.
t43562 3y ago
The manager should almost always get the blame. Why didn't they get help from another team, why didn't they supervise that dev more carefully, how did the bug get into the code in the first case and were proper test procedures followed. Has there been a history of mistakes which show a pattern that's not being managed etc etc. Ultimately the CTO is responsible to the board for why a problem damaged the business (even if it was all the mistake of a developer somehow). And the board to the shareholders for losing money. In reality people, of course, try as hard as possible to evade blame or lay it elsewhere but in theory a developer who makes a big mistake should not have been in a position to do that damage solo and it's a fault in the system if they were able to - and in the people responsible for the system.
- torginus 3y ago
  'Agile' has built-in ways of shirking management responsibility. When a developer is asked to solve some eldritch problem, it often goes: - How long will this take? - I don't know. This is very complex and I'm not familiar with the code. - You HAVE to know, we HAVE to plan for it. - Okay, then 5 days. - Hey 5 days has passed, why isn't this done yet? - I underestimated the complexity of the task. - Ah, so YOU estimated wrong, so it's YOUR fault! Hard problems exist. They can only be solved by hard-work and expertise and even then solve times are unpredictable and draining to the individual and are thankless endeavors. Management tries to paper over that, but this is a fundamental invariant of life. The fact that management makes solving these problems feel like punishment, only makes people try to avoid these problems more.
  - t43562 3y ago
    I heartily agree that the problems are hard and unpredictable things don't get made predictable by a method. I think, however, if you're in a company with bastards who don't care they will find out how to screw agile just as they screwed the scheme before that. In the waterfall projects the example you gave is just the same. In your example "I don't know, it's very complex" should lead to a spike where you have a chance to find out more. Then you'd give a high complexity estimate and everyone would try to think of ways to chip off a bit of the problem at a time. You're also trying to get your whole team to think about what can be done rather than each developer facing horrible problems alone. But if you're managed by arseholes then even the most positive ideas tend to get turned into nightmares.