5 ms·

You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept

You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

watwut 5y ago
But agile project get effed where management is not messing into internal process too. Developers make agile into hell too.
brtkdotse 5y ago
You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.
- yobbo 5y ago
  > As much as devs try to disagree, technology is not a goal in of itself Can you find one dev that has ever disagreed with this?
  - brtkdotse 5y ago
    I can find a ton of devs paying lip service disagreeing, but the second they utter “we need to rewrite this in…” the facade falls apart.
    - choeger 5y ago
      Management in turn doesn't pay any attention whatsoever to the technology. They have no idea how quality and productivity is influenced by outdated or poor choices or simply a lack of investment into maintenance. You need people that care about the how you do it as much about the why and the what. Everything else is going to be disfunctional rather soon.
      - sorokod 5y ago
        I would argue that technology is in general not management's responsibility, but resource allocation is. If you care about quality and productivity, please quantify those and present your findings in terms of tradeoffs.
      - Ma8ee 5y ago
        It’s part of your job to explain that to them. And you have to do it in business terms, that is, how it will impact budget and schedule for the project. And prepare for questions like “ok, you have convinced me that Kotlin is superior to Java, but you are the only one in the team with any Kotlin experience, and we have a rather hard deadline for this project in 9 months. Are you hundred percent sure that we will both manage to train the team and deliver in that timeframe? And you know Karl, who’s retiring in a few years, he doesn’t seem to be very eager to learn something new. And he’s a damn productive Java programmer.”
    - rgblambda 5y ago
      When I hear “we need to rewrite this in…”, it's usually because someone isn't familiar with the language it's currently in and wants to switch to the old language/framework they like best. I don't think I've ever actually heard someone trying to advocate for shiny new x just because.
  - sorokod 5y ago
    "CV driven development" is a thing. "I am bored with the old framework, let's use the new shiny one" is a thing.
  - Ma8ee 5y ago
    I’ve seen countless systems built where technology choices where more exciting than economical. Why build something in c# on top of SQL-server in six months when it can be done in three years with micro services, Kotlin, Cassandra, Kafka, mongoDb etc…
    - brtkdotse 5y ago
      For real. That why I’ve focused my consulting on pure Microsoft stack at insurance companies. My knowledge _acumulates_ for each assignment, rather than having to start over with the tech du jour.
      - pjmlp 5y ago
        Java, .NET and C++ over here. Get to rewrite the micro services, Kotlin, Cassandra, Kafka, mongoDb hardly documented, back into C# on top of SQL Server when the teams have left for the new jobs after haved pimped up their CV.
    - Aeolun 5y ago
      To be fair, this can also be because one random developer suggests this, management hears a fancy new term for their buzzword bingo, and they decree that that tech shall henceforth be used.
  - tchalla 5y ago
    It’s a constant daily struggle to explain technology experts that inferior technology with superior business/customer/product results can be prioritised over superior technology with inferior business/customer/product results.
  - avereveard 5y ago
    The whole JavaScript ecosystem
    - ratww 5y ago
      I'm all for shitting on the JS ecosystem, but honestly there haven't been any noticeable shifts whatsoever in its ecosystem for at least 6 or 7 years now. Both React and Vue.js are now older than jQuery was when both were released. Same for Babel and Webpack. Typescript is older than all of these. SASS/SCSS also older than Typescript. Those are the only things you see in 99% of the frontend job descriptions out there. If anything, frontend is kinda boring, and it can be argued that some of those tools above need some disruption.
      - avereveard 5y ago
        They keep releasing versions that break backward compatibility forcing whole app rewrite left and right, that counts too
        treeman79 5y ago
        Had a year long project in Angular. Most of the time was spent rewriting the app and learning the right way “again”
        ratww 5y ago
        The track record for compatibility in the tools I mentioned is extremely good. Even when new approaches were launched (Hooks, Composition in Vue), backwards compatibility was kept. You can even mix and match approaches in the same app. Of course there's Angular, but that's the exception to the rule. Heck, Microsoft has completely changed the way of writing native Windows apps in the last 10 years more ways than Javascript frameworks have introduced new stuff. Apple even changed the language to one that (unlike Typescript) is not backwards compatible. Complaining about the JS ecosystem evolving too fast is anachronistic, that happened more than 8 years ago.
        5y ago
smokey_circles 5y ago
The air quotes sell it. It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does. Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners. Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I absolutely hate how accurate that is because I always thought I was a big boy and I wouldn't need management if I just had "1 good tech idea". Docker had the philosophy. Now they are dying after losing the container wars. That's what happens when you have no idea what a product actually is... >but insist to intercept every decision Yes, because left to our own devices, developers will not contribute meaningful business value. There is a better way, evidently it's not agile, but it needs management's buy in, because well they're in charge (get over it in all honestly, none of us actually want the job, trust me). WE as engineers need to find a better way to engage management. But those of you who just grumble "management ruin everything" deserve the pain that such a divide causes and we need to stop wasting lifeboat's on that mentality please
- sorokod 5y ago
  I agree and want to add that sometimes the devs are not very good at, well... "deving". It is very convenient then to shift attention to inadequacy of others.
- denton-scratch 5y ago
  > Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I beg to differ. A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint. You need this team lader role to keep the suits off your back, and to ensure the demands are achievable. Project managers used to be people who wandered around with GANTT charts, and signed-off expenses and timesheets. Very rarely, I worked with a PM who saw their role as removing roadblocks, and shielding devs from suits. Those few PMs were a delight to work with (this was long before the appearance of Agile etc.) > Yes, because left to our own devices, developers will not contribute meaningful business value. I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.

You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

watwut 5y ago

But agile project get effed where management is not messing into internal process too. Developers make agile into hell too.

brtkdotse 5y ago

You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.

yobbo 5y ago
> As much as devs try to disagree, technology is not a goal in of itself Can you find one dev that has ever disagreed with this?
- brtkdotse 5y ago
  I can find a ton of devs paying lip service disagreeing, but the second they utter “we need to rewrite this in…” the facade falls apart.
  - choeger 5y ago
    Management in turn doesn't pay any attention whatsoever to the technology. They have no idea how quality and productivity is influenced by outdated or poor choices or simply a lack of investment into maintenance. You need people that care about the how you do it as much about the why and the what. Everything else is going to be disfunctional rather soon.
    - sorokod 5y ago
      I would argue that technology is in general not management's responsibility, but resource allocation is. If you care about quality and productivity, please quantify those and present your findings in terms of tradeoffs.
    - Ma8ee 5y ago
      It’s part of your job to explain that to them. And you have to do it in business terms, that is, how it will impact budget and schedule for the project. And prepare for questions like “ok, you have convinced me that Kotlin is superior to Java, but you are the only one in the team with any Kotlin experience, and we have a rather hard deadline for this project in 9 months. Are you hundred percent sure that we will both manage to train the team and deliver in that timeframe? And you know Karl, who’s retiring in a few years, he doesn’t seem to be very eager to learn something new. And he’s a damn productive Java programmer.”
  - rgblambda 5y ago
    When I hear “we need to rewrite this in…”, it's usually because someone isn't familiar with the language it's currently in and wants to switch to the old language/framework they like best. I don't think I've ever actually heard someone trying to advocate for shiny new x just because.
- sorokod 5y ago
  "CV driven development" is a thing. "I am bored with the old framework, let's use the new shiny one" is a thing.
- Ma8ee 5y ago
  I’ve seen countless systems built where technology choices where more exciting than economical. Why build something in c# on top of SQL-server in six months when it can be done in three years with micro services, Kotlin, Cassandra, Kafka, mongoDb etc…
  - brtkdotse 5y ago
    For real. That why I’ve focused my consulting on pure Microsoft stack at insurance companies. My knowledge _acumulates_ for each assignment, rather than having to start over with the tech du jour.
    - pjmlp 5y ago
      Java, .NET and C++ over here. Get to rewrite the micro services, Kotlin, Cassandra, Kafka, mongoDb hardly documented, back into C# on top of SQL Server when the teams have left for the new jobs after haved pimped up their CV.
  - Aeolun 5y ago
    To be fair, this can also be because one random developer suggests this, management hears a fancy new term for their buzzword bingo, and they decree that that tech shall henceforth be used.
- tchalla 5y ago
  It’s a constant daily struggle to explain technology experts that inferior technology with superior business/customer/product results can be prioritised over superior technology with inferior business/customer/product results.
- avereveard 5y ago
  The whole JavaScript ecosystem
  - ratww 5y ago
    I'm all for shitting on the JS ecosystem, but honestly there haven't been any noticeable shifts whatsoever in its ecosystem for at least 6 or 7 years now. Both React and Vue.js are now older than jQuery was when both were released. Same for Babel and Webpack. Typescript is older than all of these. SASS/SCSS also older than Typescript. Those are the only things you see in 99% of the frontend job descriptions out there. If anything, frontend is kinda boring, and it can be argued that some of those tools above need some disruption.
    - avereveard 5y ago
      They keep releasing versions that break backward compatibility forcing whole app rewrite left and right, that counts too
      - treeman79 5y ago
        Had a year long project in Angular. Most of the time was spent rewriting the app and learning the right way “again”
      - ratww 5y ago
        The track record for compatibility in the tools I mentioned is extremely good. Even when new approaches were launched (Hooks, Composition in Vue), backwards compatibility was kept. You can even mix and match approaches in the same app. Of course there's Angular, but that's the exception to the rule. Heck, Microsoft has completely changed the way of writing native Windows apps in the last 10 years more ways than Javascript frameworks have introduced new stuff. Apple even changed the language to one that (unlike Typescript) is not backwards compatible. Complaining about the JS ecosystem evolving too fast is anachronistic, that happened more than 8 years ago.
        5y ago

smokey_circles 5y ago

The air quotes sell it. It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does. Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners. Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I absolutely hate how accurate that is because I always thought I was a big boy and I wouldn't need management if I just had "1 good tech idea". Docker had the philosophy. Now they are dying after losing the container wars. That's what happens when you have no idea what a product actually is... >but insist to intercept every decision Yes, because left to our own devices, developers will not contribute meaningful business value. There is a better way, evidently it's not agile, but it needs management's buy in, because well they're in charge (get over it in all honestly, none of us actually want the job, trust me). WE as engineers need to find a better way to engage management. But those of you who just grumble "management ruin everything" deserve the pain that such a divide causes and we need to stop wasting lifeboat's on that mentality please

sorokod 5y ago
I agree and want to add that sometimes the devs are not very good at, well... "deving". It is very convenient then to shift attention to inadequacy of others.
denton-scratch 5y ago
> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I beg to differ. A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint. You need this team lader role to keep the suits off your back, and to ensure the demands are achievable. Project managers used to be people who wandered around with GANTT charts, and signed-off expenses and timesheets. Very rarely, I worked with a PM who saw their role as removing roadblocks, and shielding devs from suits. Those few PMs were a delight to work with (this was long before the appearance of Agile etc.) > Yes, because left to our own devices, developers will not contribute meaningful business value. I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.