4 ms·

Not disagreeing, but some points from a different perspective: a) Arguments don’t work because team doesn’t listen and/or doesn’t want to change because they w

Not disagreeing, but some points from a different perspective: a) Arguments don’t work because team doesn’t listen and/or doesn’t want to change because they wish to stay in their comfort zone. b) The responsible manager is incompetent and/or does not understand the things he/she’s responsible for and/or is a micromanager which kills any spontaneous action. c) Those who see a bigger picture do not care to or cannot explain it and/or keep it a secret. d) Sometimes the best option is to just do it (and improve it later) instead of going through a slow and energy consuming process of gathering consent etc. e) Software architects

carlisle_ 8y ago
None of these are a license to forge ahead anyway. All of these problems have their own solution that should be addressed, and most definitely not by just doing what you want anyway.
- Udik 8y ago
  And while you address and solve all those problems one by one, I'll just go ahead with my solution, thank you :)
  - LaGrange 8y ago
    Yes, I think that it's likely that a dysfunctional institution would be unable to prevent you from doing that, and it's likely the reason why you're a part of it.
    - ukj 8y ago
      An alternative perspective: If you think you work in an institution that CAN and DOES prevent that (e.g the engineers are NOT in control), then how quickly can you respond to real emergencies? You can make such actions visible (and hold people accountable after the fact), but blocking engineers from taking action is a no-no!
    - gowld 8y ago
      Dysfunctional institution beats a non-functional institution that dissolved because it got nothing done and lost cash flow to pay the workers.
kartan 8y ago
> a) Arguments don’t work because team doesn’t listen and/or doesn’t want to change because they wish to stay in their comfort zone. It is a problem if there is no communication. To bypass all formality only hides the real problem is not solving it. It is not easy to know who is right. That is part of my job when one person is in a fight with the rest of the team my job is to listen to everybody and help to get a decision thru. I have seen all combinations, the team is right the lone ranger wrong, the lone ranger is right and the team is wrong, all are right and one path needs to be decided, all are wrong and I help them to find a different solution. > c) Those who see a bigger picture do not care to or cannot explain it and/or keep it a secret. Again this happens and it is a big problem that needs to be addressed. To hide it doing things rogue stile only perpetuates the problem. Sometimes is better to get everything to a halt until information is shared than to tag along for years of painful fights. > e) Software architects Yes. I am one. And my main problem is the arrogance of other architects, not the managers, product owners or developers in the teams. :P
- rvanmil 8y ago
  You're right that the root cause needs to be fixed. My points are within an assumed context of a dysfunctional environment where the status quo is either actively maintained or simply neglected, and the person bypassing formality is only doing so because there are no other options available. As greedo mentions in another reply to my points, you really can't have "lone rangers" on a team who do this without a valid excuse. The point about architects was somewhat joking; of course there are good ones (such as yourself judging from your comments), but in my experience most of them are at best a useless burden and at worst an utterly destructive influence on teams.
- OpenDrapery 8y ago
  I can tell that you are an architect from they way that you like to use the terms "right" and "wrong". There is no right and wrong. There are only opinions and stylistic preference. There are solutions that are better and there are ones that are worse. But when you black box it and look at it from the outside, it either works or it doesn't.
  - 8y ago
greedo 8y ago
Just to address "d" in your list. Consensus is hugely important in team environments. If you're an indie dev, do what makes you happy (and profitable). But if you're in a team, be a team member. My team just had an coworker leave for another team. This coworker was very smart, very hardworking, and very dedicated. But he continually chafed against any sort of documentation or communication. He also chafed against any established standards or policies; pretty much did what he wanted, and was never really called on the mat for these issues. He got away with this because he was a "rockstar." He could solve some pretty hairy problems fairly quickly. But explaining these fixes to others was difficult for him, and many of his solutions were MacGyver-esqe. He had come from a small shop where he wore many hats; we're a large enterprise with lots of teams. This means that communication is probably the most vital skill for team success. Since he didn't share or document his changes and fixes, the remaining team members are now left trying to divine what he did. While I blame him for a lot of this behavior, I primarily blame his manager who continually tolerated it. Ironically, this manager is shocked and confused as to why he lost his rockstar.
- OpenDrapery 8y ago
  Skill and talent are at odds with process heaviness. Oftentimes I think it's a "pick one" type of scenario. Do you want critical thinkers who just "get it" when it comes to complex technical matters? Or do you want process rigor? Someone will say "false dichotomy", to which I say, "maybe".
  - jib 8y ago
    Process heaviness is not a goal. The secret is to be as close to the minimally viable as is safe. Undocumented code and decisions are just a more slowly accumulating cost, it is no less costly than bad or failing code. This is a reason I love having outspoken and extroverted devs. The guys who love to talk so much that they will explain in extreme detail and at length. I was reading through an old bug yesterday, and the guy who had done some work in that area had left a 5 paragraph explanation of what had gone wrong, what he thought may have caused it and some things he was planning on doing. Having that written down was invaluable when I got to the thing a year later. Process rigour is not the goal. Communicating what is strange and different is. If you have guys who do that naturally, great. If not, you need some process.

carlisle_ 8y ago

None of these are a license to forge ahead anyway. All of these problems have their own solution that should be addressed, and most definitely not by just doing what you want anyway.

Udik 8y ago
And while you address and solve all those problems one by one, I'll just go ahead with my solution, thank you :)
- LaGrange 8y ago
  Yes, I think that it's likely that a dysfunctional institution would be unable to prevent you from doing that, and it's likely the reason why you're a part of it.
  - ukj 8y ago
    An alternative perspective: If you think you work in an institution that CAN and DOES prevent that (e.g the engineers are NOT in control), then how quickly can you respond to real emergencies? You can make such actions visible (and hold people accountable after the fact), but blocking engineers from taking action is a no-no!
  - gowld 8y ago
    Dysfunctional institution beats a non-functional institution that dissolved because it got nothing done and lost cash flow to pay the workers.

kartan 8y ago

> a) Arguments don’t work because team doesn’t listen and/or doesn’t want to change because they wish to stay in their comfort zone. It is a problem if there is no communication. To bypass all formality only hides the real problem is not solving it. It is not easy to know who is right. That is part of my job when one person is in a fight with the rest of the team my job is to listen to everybody and help to get a decision thru. I have seen all combinations, the team is right the lone ranger wrong, the lone ranger is right and the team is wrong, all are right and one path needs to be decided, all are wrong and I help them to find a different solution. > c) Those who see a bigger picture do not care to or cannot explain it and/or keep it a secret. Again this happens and it is a big problem that needs to be addressed. To hide it doing things rogue stile only perpetuates the problem. Sometimes is better to get everything to a halt until information is shared than to tag along for years of painful fights. > e) Software architects Yes. I am one. And my main problem is the arrogance of other architects, not the managers, product owners or developers in the teams. :P

rvanmil 8y ago
You're right that the root cause needs to be fixed. My points are within an assumed context of a dysfunctional environment where the status quo is either actively maintained or simply neglected, and the person bypassing formality is only doing so because there are no other options available. As greedo mentions in another reply to my points, you really can't have "lone rangers" on a team who do this without a valid excuse. The point about architects was somewhat joking; of course there are good ones (such as yourself judging from your comments), but in my experience most of them are at best a useless burden and at worst an utterly destructive influence on teams.
OpenDrapery 8y ago
I can tell that you are an architect from they way that you like to use the terms "right" and "wrong". There is no right and wrong. There are only opinions and stylistic preference. There are solutions that are better and there are ones that are worse. But when you black box it and look at it from the outside, it either works or it doesn't.
- 8y ago

greedo 8y ago

Just to address "d" in your list. Consensus is hugely important in team environments. If you're an indie dev, do what makes you happy (and profitable). But if you're in a team, be a team member. My team just had an coworker leave for another team. This coworker was very smart, very hardworking, and very dedicated. But he continually chafed against any sort of documentation or communication. He also chafed against any established standards or policies; pretty much did what he wanted, and was never really called on the mat for these issues. He got away with this because he was a "rockstar." He could solve some pretty hairy problems fairly quickly. But explaining these fixes to others was difficult for him, and many of his solutions were MacGyver-esqe. He had come from a small shop where he wore many hats; we're a large enterprise with lots of teams. This means that communication is probably the most vital skill for team success. Since he didn't share or document his changes and fixes, the remaining team members are now left trying to divine what he did. While I blame him for a lot of this behavior, I primarily blame his manager who continually tolerated it. Ironically, this manager is shocked and confused as to why he lost his rockstar.

OpenDrapery 8y ago
Skill and talent are at odds with process heaviness. Oftentimes I think it's a "pick one" type of scenario. Do you want critical thinkers who just "get it" when it comes to complex technical matters? Or do you want process rigor? Someone will say "false dichotomy", to which I say, "maybe".
- jib 8y ago
  Process heaviness is not a goal. The secret is to be as close to the minimally viable as is safe. Undocumented code and decisions are just a more slowly accumulating cost, it is no less costly than bad or failing code. This is a reason I love having outspoken and extroverted devs. The guys who love to talk so much that they will explain in extreme detail and at length. I was reading through an old bug yesterday, and the guy who had done some work in that area had left a 5 paragraph explanation of what had gone wrong, what he thought may have caused it and some things he was planning on doing. Having that written down was invaluable when I got to the thing a year later. Process rigour is not the goal. Communicating what is strange and different is. If you have guys who do that naturally, great. If not, you need some process.