9 ms·

You do have an excellent point for part of the cases. We should IMO also entertain one more possibility: namely pressure from the top. A lot of people who I k

You do have an excellent point for part of the cases. We should IMO also entertain one more possibility: namely pressure from the top. A lot of people who I knew as sympathetic and calm before they took management roles turned into something I could code in one minute: namely a program that asks "how much is this going to take?" and if your answer is above N hours/days then they say "no, we're not doing it". And that's not because they are stupid or suddenly non-sympathetic. It's because their bosses optimize for those metrics and measure them (and their salary, and their bonuses, and even their vacation days) by the same metrics. Perverted incentives play a big part in the current state of things where everyone just looks baffled at thing X and is like "why in the holy frak isn't this working better?". Truth is, MANY, and I mean really A LOT of people know that their work is sub-optimal but pressure from above prevents them from making it better. And people are not independent -- for most people outside IT and other prestige / high-skill professions, standing up to the boss means 3 to 9 months of unemployment and maybe no food on the table. Hence everybody learns to suck it up and do the bare minimum that keeps them employed, perpetuating the cycle. Multiply that to at least 90% of our world and it's IMO quite easy to understand why it is like it is.

zaphar 6y ago
Some of what you say about management is true. But if you really want to fully understand then you need to keep following that trail of incentives. Your bosses boss doesn't optimize for those metrics "just because". There are reasons and persuading them requires understanding those reasons. A company has only so much revenue. Wasting that revenue in the best case reduces profits. In the worst case it kills the company. Changing a perverse incentive requires understanding whether it is actually perverse or not and then proposing a compelling alternative that results in better results for the company.
- tremon 6y ago
  Changing a perverse incentive requires understanding whether it is actually perverse or not and then proposing a compelling alternative that results in better results for the company. While that's true, considering those incentives and changing them if necessary is part of my boss's job, not mine. My job is only to report the misaligned incentives I perceive to my boss. If my boss isn't able to make me understand his decisions, that's my cue to find a new boss. And I concede, those bosses are rare. I've only had two in twenty years of employment. It takes time to recognize the qualities you need in a boss to perform well. I know myself well enough in that department to actively look for those qualities. Even to the point where I prefer a less challenging job under the right boss than the perfect job under the wrong leadership.
- pdimitar 6y ago
  I am sure that what you say is very true for not a small amount of businesses. My issue is mostly with my profession -- programming. Sometimes we are so micromanaged and our time is so sliced and diced that all of this short-term thinking easily gets 5x more expensive on a short time frame anywhere from 3 to 6 months. This has been observed numerous times yet IT managers seem to want to never learn. It's OK to try and save money. But saving money short-term in order to have a huge expense down the line is just being irresponsible from those managers.
  - hallway_monitor 6y ago
    Having led a team for about a year now let me tell you it's not easy. You are always trying to balance many priorities and even with over a decade of coding experience, it's not always obvious which refactorings or tech debt stories or architectural changes are worth prioritizing now, which can wait till later, and which are engineer pipe dreams that I need to gently but firmly kill as quickly as possible. I have had similar managers to what was described above, in those types of organizations. It may be a lost cause but it may be an opportunity to work on your influence skills; being able to explain and sell your solution is perhaps even more important than coming up with it in the first place.
    - deleted 6y ago
      [deleted]
    - tacitusarc 6y ago
      This is really difficult. Perhaps the best thing is to track the proposed technical debt stories, and do not discard them when they are rejected. Instead, also keep track of how much pain is hit that can be associated back to that particular technical debt. 3 years into major project, my team finally got prioritized to work on and improvement that will take us a couple weeks, that we were not able to work on previously because we could not justify its value. But for the past 3 years the organization has lived with pain that this would have resolved. So now we can justify it. And the thing is, it's not like we didn't know 3 years ago when we said we wanted to make this happen but things are going to be terrible if we were not able to prioritize it but in many organizations it's not good enough to just say how bad things will be. People need to actually have felt the pain. Honestly, I think that's okay on its face. My bigger issue is that frequently there is no or very little trust around engineers who predict what the major problems will be an advocate for them and then it's not like when they're proven right management now listens to them the next time. I think that's the real problem.
- marcosdumay 6y ago
  > Your bosses boss doesn't optimize for those metrics "just because". Your bosses optimize for those metrics because it's the one they can communicate higher up on the short time they can get higher ups attention. If it were because the metric was any good, there wouldn't be so many cases of companies bankrupted by technical and cultural debits pilling up.
  - pdimitar 6y ago
    > Your bosses optimize for those metrics because it's the one they can communicate higher up on the short time they can get higher ups attention. That's their problem and not mine, is it? A good manager doesn't just reflect the lightning bolt to their underlings. They absorb part of the shock and process / transform what they will transfer down below. If they aren't doing that then they aren't managers; they are uneducated opportunists in suits. > If it were because the metric was any good, there wouldn't be so many cases of companies bankrupted by technical and cultural debits pilling up. Really well articulated, kudos.
- alisonatwork 6y ago
  I agree that often there are good business reasons for killing projects, and plenty of so-called technical debt is actually just the result of pragmatic decision-making. Imo developers should get used to maintaining that stuff, because that's a huge part of the job in most profitable companies. But there is also a flip-side where I see the opposite happen - especially in startups and VC-funded companies. These companies can take massive losses while at the same time investing huge amounts into elaborate solutions that appear to primarily exist for the purpose of creating impressive bullet points on the resumes of careerist employees. In these companies, even in management, the work seems to be driven by everyone trying to maximize the impact of their own, personal "tour of duty", then making a profitable exit. These incentives are not the same as those of people working at more legacy/boring companies.
  - pdimitar 6y ago
    > These companies can take massive losses while at the same time investing huge amounts into elaborate solutions that appear to primarily exist for the purpose of creating impressive bullet points on the resumes of careerist employees. Yep, that's one of the things I had in mind when I said "perverse incentives".
- bobthepanda 6y ago
  It also takes time to turn a big ship, and by the time one realizes one needs to make the turn it may be too late. To extend this to non-tech examples, failing big companies, like Sears, do not disappear overnight; the decline was in full view for over a decade but ultimately the ship could not be turned. With tech the problem may be even worse; Uber still has not turned a net profit, but with tech investors like to throw money at losing businesses. Some turn around, but that's not guaranteed.
Xunjin 6y ago
"Hence everybody learns to suck it up and do the bare minimum that keeps them employed, perpetuating the cycle." In my point of view, that's how you lose solutions to stay in the comfort zone, and I'm not saying the people whom actually "just obey orders" but those who make them. As I gain more experience, with age and some wisdom (I hope), I see that most top-down decisions are actually the worst way to decide things, people who are "at the bottom" maybe not understand how a entire system works however they do really knows (and suffer) on how their work is sub-optimal.
- marcosdumay 6y ago
  That's evidently correct, and all the empiric results point into correctness too. As always I recommend reading Deming. Or go directly to the Toyota production system. The best working system is one where management sets the goals and workers decide the means, while one trusting each other to do their job. https://en.wikipedia.org/wiki/Toyota_Production_System https://en.wikipedia.org/wiki/Toyota_Production_System But somehow, management never accepts this reality. Even the Japanese auto industry is regressing into Taylorism.
  - NotPavlovsDog 6y ago
    There may not be that much difference between Lean (Toyota) and Taylorism. Don't forget that Toyota (Toyoda) is not that far from Fordism - "you get whatever color you want as long as it is black". Employees get to tweak the process but the fundamental model stays the same. They don't get to change the assembly line, nor the parts, nor what is assembled. And Toyota guaranteed life-long employment when it was implemented. I've worked the line twice - first time as a teen looking for any work, the second time as an undercover analyst hired to examine why Lean was failing at a plant, both doing the same type of job: electrical component assembly. I got physical injuries (minor) both times. The majority of the assembly line workers had repetitive stress injuries, including losing fine motor skills and wrist control due to use of impact wrenches and exposure to bad ergonomics. If a human delaminates, you can't glue them back. Although rational (Taylorism, Management by Objectives, MBO, OKR, Milestones, management by goals ) vs. normative (Lean / Toyoda, human-centric, Agile, humanist, culture ) division of management styles/rhetoric has been proposed, they should perhaps be seen through the prism of Creative Destriction (not disruption, and surprisingly, CD comes from Marx). In a vulgar approximation, imagine capital-backed entities served by the manager class, which are stressed by short deadlines and performance-tied bonuses and careers. They are constantly shifting basic approximations of solutions and perspectives, without challenging the system. Give employees more autonomy, and output and managerial control suffer. Instill more rigid control, and risk losing the ability to innovate and "knowledge producing" (Drucker of MBO fame) talent such as programmers. In an antagonistic system, whatever you come up with has its own roots of destruction on top of built-in conflict (Marx again). Hence the back-and-forth re-framing between "rational" (Taylorism) and normative "culture, baybe, Holocracy!" so fast that today it is a zombie that has both and neither. You end up with projectification, corporate "culture" that demands the soul and meeting arbitrary "milestones" from employees, but the corporation itself can only guarantee arbitrary termination. There is a great and influential analysis "Design and Devotion: Surges of Rational and Normative Ideologies of Control in Managerial Discourse" by Barley and Kunda. I would suggest reading "Management fashion" by Abrahamson as well. Both can be found through G.scholar, including no-registration copies. https://www.jstor.org/stable/2393449 https://www.jstor.org/stable/2393449 https://journals.aom.org/doi/abs/10.5465/amr.1996.9602161572 https://journals.aom.org/doi/abs/10.5465/amr.1996.9602161572
itsArtur 6y ago
> A lot of people who I knew as sympathetic and calm before they took management roles turned into something I could code in one minute: namely a program that asks "how much is this going to take?" and if your answer is above N hours/days then they say "no, we're not doing it". And that's not because they are stupid or suddenly non-sympathetic. It's because their bosses optimize for those metrics and measure them (and their salary, and their bonuses, and even their vacation days) by the same metrics. I had this exact same thought recently when reflecting on my behavior in my new role as a "technical product owner". All of it was reflexive, as if I suddenly forgot all of the software engineering knowledge I accumulated over the years and became a deadline-driven cog. I don't have a solution yet; I think it comes down to that I don't yet speak the same language that people I report to do, and thus I feel like I can't defend my position well enough. It comes with experience, I guess!
- pdimitar 6y ago
  Part of what makes you an enabler of programmers -- and not just a guy who screams "faster! harder!" -- is to be able to push back a little. There's sadly an inherent conflict of interest between the people doing the job on the ground (programmers) and the rulers (managers). Your job is to find the middle ground -- not to completely side with your higher-ups. That would be a good starting point for you IMO.
analog31 6y ago
If the manager is a former engineer, they might just be following a rule of thumb, that bigger tasks are impossible to manage, and above a certain size threshold, carry an existential risk for the business.
BurningFrog 6y ago
I think OPs point applies to organizational management as much as programming: > if a solution exists today, and it has yet to be replaced, it's at least possible that it's over all the best solution, and the reason you're not seeing that is because of a lack of understanding.
bradleyjg 6y ago
I’ve been reading these Dilbert rants for twenty five years. I probably made some of them on slashdot. We as an industry tried the all engineers thing and it didn’t work. Have you considered the possibility that the boss’ bosses have a point? That the intelligent people you once respected have been convinced rather than intimidated?
- pdimitar 6y ago
  I would be ashamed to call myself a thinking human if I never considered it. And as said in other comments, for some companies and businesses they are right indeed. But not in programming / IT in general. At least not where I worked (and where many of my former colleagues worked). It's all optimizing for short-term and never the long-term. And I have seen people playing the long game gaining a lot so I also know I am not imagining it.
  - kansface 6y ago
    Predictability in the short term has a definite business value in and of itself, regardless if it makes development slower - or perhaps, a value to management. Certainly the degree matters.
    - pdimitar 6y ago
      You know, I am actually VERY okay with short-term thinking but not when it's 100% of all decision making. Make it 75% short-term objective and give the other 25% to longer-term planning and/or simply playing with ideas and I'll be very happy to work in such a place. I am not a fanatic -- and most programmers are actually quite understanding (if a bit too timid sometimes) people. We just want the pendulum to not be on one of the sides 100% of the time. That's it really.
      - deleted 6y ago
        [deleted]
- tremon 6y ago
lamontcg 6y ago
There's an implicit assumption here that everyone is "doing a bad job" because of "perverse incentives". But I'd argue that most 'computer nerds' have pretty deeply seated perfectionism flaws. To take a simplified example, we tend to want perfect security, and like to prove that we're smarter than each other by understanding complicated attacks. When it comes to running a business, though, a 10 person startup cannot afford to act like their threat model includes defending from hostile nation state actors willing to do Stuxnet-levels of effort to hack them. If they do that much work on security their product will never get off the ground. The goal of most companies when it comes to security is never to have perfect security, but to have good enough security to stay out of the headlines. It is like tradeoffs that have evolved in nature. You don't see organisms that maximize one feature at the expense of everything else. That energy always needs to go into competing concerns. So sometimes as technical people we fetishize the perfect solution to some problem in the Enterprise, when actually doing that solution would be horrible for the Enterprise due to the costs. (Of course the flip side is sometimes management only cares about window dressing the company so they can bailout with some golden parachutes and that has nothing to do with running a healthy company -- but not every example of a company not being perfect is due to deeply cynical and perverse incentives like that, but may be entirely rational).
- pdimitar 6y ago
  > But I'd argue that most 'computer nerds' have pretty deeply seated perfectionism flaws. My goal here absolutely was not to turn this sub-thread into a ping-pong of "but managers bad at X" and "but but but programmers bad at Y". I am very aware of the nuance you introduced and I've been guilty of being a tech perfectionist much more times that I'd be comfortable with sharing. But finally I learned. (Granted, many haven't and maybe never will. In this regard you do have a solid point.) > So sometimes as technical people we fetishize the perfect solution to some problem in the Enterprise, when actually doing that solution would be horrible for the Enterprise due to the costs. Absolutely. Not denying it. It's just that what gets me is the reaction to some of the engineers' flaws is to go to the other extreme. Which is just as bad state of things. Both extremes are unproductive.
jakub_g 6y ago
This. It's also really difficult to build a mastery of things when you're constantly moving from one piece of code to another according to shifting priorities. And once you build mastery of $fwk/$lib/$tool, it's deprecated and you migrate to another one. GOTO START
- pdimitar 6y ago
  Sadly yes. I really want to... stand still for a bit and learn things properly, you know?
- zmmmmm 6y ago
  > It's also really difficult to build a mastery of things when you're constantly moving from one piece of code to another Conversely, it's surprisingly difficult to get engineers to master things they aren't intrinsically interested in. We've had a stable tech stack and core architecture for 4+ years and one of my major challenges is to stop employees constantly trying to introduce $new/$shiny or major refactor X because it wasn't built how they personally would have done it and get them to just learn and understand the stack we already have - which addresses all our needs at most 5% less optimally than $new/$shiny.
  - danieltillett 6y ago
    When someone’s future salary is tied to acquiring $new/$shiny skill then you are going to get this sort of rational behaviour from the engineers. Smart people respond to incentives.
  - pdimitar 6y ago
    This is very logical because engineers know they can be fired any minute with zero recourse. Inevitably, they want to invest part of their current work time into being able to to apply for the next job. If people have a good social safety net and a good job security, the depth of their skills improves by a lot.
    - zmmmmm 6y ago
cascom 6y ago
I’m not sure I’d call the incentives perverted (only perverted in the sense that “perfect” software is not the goal). Management and owners are a far from perfect group that make plenty of bad strategic decisions for a host of reasons, but they also have to deal with the real/perceived constraints of time, budget, market, competition, etc. that are easy to not appreciate when you are focused on the design/build portion of the business.

zaphar 6y ago

Some of what you say about management is true. But if you really want to fully understand then you need to keep following that trail of incentives. Your bosses boss doesn't optimize for those metrics "just because". There are reasons and persuading them requires understanding those reasons. A company has only so much revenue. Wasting that revenue in the best case reduces profits. In the worst case it kills the company. Changing a perverse incentive requires understanding whether it is actually perverse or not and then proposing a compelling alternative that results in better results for the company.

tremon 6y ago
Changing a perverse incentive requires understanding whether it is actually perverse or not and then proposing a compelling alternative that results in better results for the company. While that's true, considering those incentives and changing them if necessary is part of my boss's job, not mine. My job is only to report the misaligned incentives I perceive to my boss. If my boss isn't able to make me understand his decisions, that's my cue to find a new boss. And I concede, those bosses are rare. I've only had two in twenty years of employment. It takes time to recognize the qualities you need in a boss to perform well. I know myself well enough in that department to actively look for those qualities. Even to the point where I prefer a less challenging job under the right boss than the perfect job under the wrong leadership.
pdimitar 6y ago
I am sure that what you say is very true for not a small amount of businesses. My issue is mostly with my profession -- programming. Sometimes we are so micromanaged and our time is so sliced and diced that all of this short-term thinking easily gets 5x more expensive on a short time frame anywhere from 3 to 6 months. This has been observed numerous times yet IT managers seem to want to never learn. It's OK to try and save money. But saving money short-term in order to have a huge expense down the line is just being irresponsible from those managers.
- hallway_monitor 6y ago
  Having led a team for about a year now let me tell you it's not easy. You are always trying to balance many priorities and even with over a decade of coding experience, it's not always obvious which refactorings or tech debt stories or architectural changes are worth prioritizing now, which can wait till later, and which are engineer pipe dreams that I need to gently but firmly kill as quickly as possible. I have had similar managers to what was described above, in those types of organizations. It may be a lost cause but it may be an opportunity to work on your influence skills; being able to explain and sell your solution is perhaps even more important than coming up with it in the first place.
  - deleted 6y ago
    [deleted]
  - tacitusarc 6y ago
    This is really difficult. Perhaps the best thing is to track the proposed technical debt stories, and do not discard them when they are rejected. Instead, also keep track of how much pain is hit that can be associated back to that particular technical debt. 3 years into major project, my team finally got prioritized to work on and improvement that will take us a couple weeks, that we were not able to work on previously because we could not justify its value. But for the past 3 years the organization has lived with pain that this would have resolved. So now we can justify it. And the thing is, it's not like we didn't know 3 years ago when we said we wanted to make this happen but things are going to be terrible if we were not able to prioritize it but in many organizations it's not good enough to just say how bad things will be. People need to actually have felt the pain. Honestly, I think that's okay on its face. My bigger issue is that frequently there is no or very little trust around engineers who predict what the major problems will be an advocate for them and then it's not like when they're proven right management now listens to them the next time. I think that's the real problem.
marcosdumay 6y ago
> Your bosses boss doesn't optimize for those metrics "just because". Your bosses optimize for those metrics because it's the one they can communicate higher up on the short time they can get higher ups attention. If it were because the metric was any good, there wouldn't be so many cases of companies bankrupted by technical and cultural debits pilling up.
- pdimitar 6y ago
  > Your bosses optimize for those metrics because it's the one they can communicate higher up on the short time they can get higher ups attention. That's their problem and not mine, is it? A good manager doesn't just reflect the lightning bolt to their underlings. They absorb part of the shock and process / transform what they will transfer down below. If they aren't doing that then they aren't managers; they are uneducated opportunists in suits. > If it were because the metric was any good, there wouldn't be so many cases of companies bankrupted by technical and cultural debits pilling up. Really well articulated, kudos.
alisonatwork 6y ago
I agree that often there are good business reasons for killing projects, and plenty of so-called technical debt is actually just the result of pragmatic decision-making. Imo developers should get used to maintaining that stuff, because that's a huge part of the job in most profitable companies. But there is also a flip-side where I see the opposite happen - especially in startups and VC-funded companies. These companies can take massive losses while at the same time investing huge amounts into elaborate solutions that appear to primarily exist for the purpose of creating impressive bullet points on the resumes of careerist employees. In these companies, even in management, the work seems to be driven by everyone trying to maximize the impact of their own, personal "tour of duty", then making a profitable exit. These incentives are not the same as those of people working at more legacy/boring companies.
- pdimitar 6y ago
  > These companies can take massive losses while at the same time investing huge amounts into elaborate solutions that appear to primarily exist for the purpose of creating impressive bullet points on the resumes of careerist employees. Yep, that's one of the things I had in mind when I said "perverse incentives".
bobthepanda 6y ago
It also takes time to turn a big ship, and by the time one realizes one needs to make the turn it may be too late. To extend this to non-tech examples, failing big companies, like Sears, do not disappear overnight; the decline was in full view for over a decade but ultimately the ship could not be turned. With tech the problem may be even worse; Uber still has not turned a net profit, but with tech investors like to throw money at losing businesses. Some turn around, but that's not guaranteed.

Xunjin 6y ago

"Hence everybody learns to suck it up and do the bare minimum that keeps them employed, perpetuating the cycle." In my point of view, that's how you lose solutions to stay in the comfort zone, and I'm not saying the people whom actually "just obey orders" but those who make them. As I gain more experience, with age and some wisdom (I hope), I see that most top-down decisions are actually the worst way to decide things, people who are "at the bottom" maybe not understand how a entire system works however they do really knows (and suffer) on how their work is sub-optimal.

marcosdumay 6y ago
That's evidently correct, and all the empiric results point into correctness too. As always I recommend reading Deming. Or go directly to the Toyota production system. The best working system is one where management sets the goals and workers decide the means, while one trusting each other to do their job. https://en.wikipedia.org/wiki/Toyota_Production_System https://en.wikipedia.org/wiki/Toyota_Production_System But somehow, management never accepts this reality. Even the Japanese auto industry is regressing into Taylorism.
- NotPavlovsDog 6y ago
  There may not be that much difference between Lean (Toyota) and Taylorism. Don't forget that Toyota (Toyoda) is not that far from Fordism - "you get whatever color you want as long as it is black". Employees get to tweak the process but the fundamental model stays the same. They don't get to change the assembly line, nor the parts, nor what is assembled. And Toyota guaranteed life-long employment when it was implemented. I've worked the line twice - first time as a teen looking for any work, the second time as an undercover analyst hired to examine why Lean was failing at a plant, both doing the same type of job: electrical component assembly. I got physical injuries (minor) both times. The majority of the assembly line workers had repetitive stress injuries, including losing fine motor skills and wrist control due to use of impact wrenches and exposure to bad ergonomics. If a human delaminates, you can't glue them back. Although rational (Taylorism, Management by Objectives, MBO, OKR, Milestones, management by goals ) vs. normative (Lean / Toyoda, human-centric, Agile, humanist, culture ) division of management styles/rhetoric has been proposed, they should perhaps be seen through the prism of Creative Destriction (not disruption, and surprisingly, CD comes from Marx). In a vulgar approximation, imagine capital-backed entities served by the manager class, which are stressed by short deadlines and performance-tied bonuses and careers. They are constantly shifting basic approximations of solutions and perspectives, without challenging the system. Give employees more autonomy, and output and managerial control suffer. Instill more rigid control, and risk losing the ability to innovate and "knowledge producing" (Drucker of MBO fame) talent such as programmers. In an antagonistic system, whatever you come up with has its own roots of destruction on top of built-in conflict (Marx again). Hence the back-and-forth re-framing between "rational" (Taylorism) and normative "culture, baybe, Holocracy!" so fast that today it is a zombie that has both and neither. You end up with projectification, corporate "culture" that demands the soul and meeting arbitrary "milestones" from employees, but the corporation itself can only guarantee arbitrary termination. There is a great and influential analysis "Design and Devotion: Surges of Rational and Normative Ideologies of Control in Managerial Discourse" by Barley and Kunda. I would suggest reading "Management fashion" by Abrahamson as well. Both can be found through G.scholar, including no-registration copies. https://www.jstor.org/stable/2393449 https://www.jstor.org/stable/2393449 https://journals.aom.org/doi/abs/10.5465/amr.1996.9602161572 https://journals.aom.org/doi/abs/10.5465/amr.1996.9602161572

itsArtur 6y ago

> A lot of people who I knew as sympathetic and calm before they took management roles turned into something I could code in one minute: namely a program that asks "how much is this going to take?" and if your answer is above N hours/days then they say "no, we're not doing it". And that's not because they are stupid or suddenly non-sympathetic. It's because their bosses optimize for those metrics and measure them (and their salary, and their bonuses, and even their vacation days) by the same metrics. I had this exact same thought recently when reflecting on my behavior in my new role as a "technical product owner". All of it was reflexive, as if I suddenly forgot all of the software engineering knowledge I accumulated over the years and became a deadline-driven cog. I don't have a solution yet; I think it comes down to that I don't yet speak the same language that people I report to do, and thus I feel like I can't defend my position well enough. It comes with experience, I guess!

pdimitar 6y ago
Part of what makes you an enabler of programmers -- and not just a guy who screams "faster! harder!" -- is to be able to push back a little. There's sadly an inherent conflict of interest between the people doing the job on the ground (programmers) and the rulers (managers). Your job is to find the middle ground -- not to completely side with your higher-ups. That would be a good starting point for you IMO.

analog31 6y ago

If the manager is a former engineer, they might just be following a rule of thumb, that bigger tasks are impossible to manage, and above a certain size threshold, carry an existential risk for the business.

BurningFrog 6y ago

I think OPs point applies to organizational management as much as programming: > if a solution exists today, and it has yet to be replaced, it's at least possible that it's over all the best solution, and the reason you're not seeing that is because of a lack of understanding.

bradleyjg 6y ago

I’ve been reading these Dilbert rants for twenty five years. I probably made some of them on slashdot. We as an industry tried the all engineers thing and it didn’t work. Have you considered the possibility that the boss’ bosses have a point? That the intelligent people you once respected have been convinced rather than intimidated?

pdimitar 6y ago
I would be ashamed to call myself a thinking human if I never considered it. And as said in other comments, for some companies and businesses they are right indeed. But not in programming / IT in general. At least not where I worked (and where many of my former colleagues worked). It's all optimizing for short-term and never the long-term. And I have seen people playing the long game gaining a lot so I also know I am not imagining it.
- kansface 6y ago
  Predictability in the short term has a definite business value in and of itself, regardless if it makes development slower - or perhaps, a value to management. Certainly the degree matters.
  - pdimitar 6y ago
    You know, I am actually VERY okay with short-term thinking but not when it's 100% of all decision making. Make it 75% short-term objective and give the other 25% to longer-term planning and/or simply playing with ideas and I'll be very happy to work in such a place. I am not a fanatic -- and most programmers are actually quite understanding (if a bit too timid sometimes) people. We just want the pendulum to not be on one of the sides 100% of the time. That's it really.
    - deleted 6y ago
      [deleted]
tremon 6y ago

lamontcg 6y ago

There's an implicit assumption here that everyone is "doing a bad job" because of "perverse incentives". But I'd argue that most 'computer nerds' have pretty deeply seated perfectionism flaws. To take a simplified example, we tend to want perfect security, and like to prove that we're smarter than each other by understanding complicated attacks. When it comes to running a business, though, a 10 person startup cannot afford to act like their threat model includes defending from hostile nation state actors willing to do Stuxnet-levels of effort to hack them. If they do that much work on security their product will never get off the ground. The goal of most companies when it comes to security is never to have perfect security, but to have good enough security to stay out of the headlines. It is like tradeoffs that have evolved in nature. You don't see organisms that maximize one feature at the expense of everything else. That energy always needs to go into competing concerns. So sometimes as technical people we fetishize the perfect solution to some problem in the Enterprise, when actually doing that solution would be horrible for the Enterprise due to the costs. (Of course the flip side is sometimes management only cares about window dressing the company so they can bailout with some golden parachutes and that has nothing to do with running a healthy company -- but not every example of a company not being perfect is due to deeply cynical and perverse incentives like that, but may be entirely rational).

pdimitar 6y ago
> But I'd argue that most 'computer nerds' have pretty deeply seated perfectionism flaws. My goal here absolutely was not to turn this sub-thread into a ping-pong of "but managers bad at X" and "but but but programmers bad at Y". I am very aware of the nuance you introduced and I've been guilty of being a tech perfectionist much more times that I'd be comfortable with sharing. But finally I learned. (Granted, many haven't and maybe never will. In this regard you do have a solid point.) > So sometimes as technical people we fetishize the perfect solution to some problem in the Enterprise, when actually doing that solution would be horrible for the Enterprise due to the costs. Absolutely. Not denying it. It's just that what gets me is the reaction to some of the engineers' flaws is to go to the other extreme. Which is just as bad state of things. Both extremes are unproductive.

jakub_g 6y ago

This. It's also really difficult to build a mastery of things when you're constantly moving from one piece of code to another according to shifting priorities. And once you build mastery of $fwk/$lib/$tool, it's deprecated and you migrate to another one. GOTO START

pdimitar 6y ago
Sadly yes. I really want to... stand still for a bit and learn things properly, you know?
zmmmmm 6y ago
> It's also really difficult to build a mastery of things when you're constantly moving from one piece of code to another Conversely, it's surprisingly difficult to get engineers to master things they aren't intrinsically interested in. We've had a stable tech stack and core architecture for 4+ years and one of my major challenges is to stop employees constantly trying to introduce $new/$shiny or major refactor X because it wasn't built how they personally would have done it and get them to just learn and understand the stack we already have - which addresses all our needs at most 5% less optimally than $new/$shiny.
- danieltillett 6y ago
  When someone’s future salary is tied to acquiring $new/$shiny skill then you are going to get this sort of rational behaviour from the engineers. Smart people respond to incentives.
- pdimitar 6y ago
  This is very logical because engineers know they can be fired any minute with zero recourse. Inevitably, they want to invest part of their current work time into being able to to apply for the next job. If people have a good social safety net and a good job security, the depth of their skills improves by a lot.
  - zmmmmm 6y ago

cascom 6y ago

I’m not sure I’d call the incentives perverted (only perverted in the sense that “perfect” software is not the goal). Management and owners are a far from perfect group that make plenty of bad strategic decisions for a host of reasons, but they also have to deal with the real/perceived constraints of time, budget, market, competition, etc. that are easy to not appreciate when you are focused on the design/build portion of the business.