4 ms·

There's a meta-pattern here. I've seen countless (especially younger) dev teams focus on new and hot tech to the detriment of solving the business problem. I'

There's a meta-pattern here. I've seen countless (especially younger) dev teams focus on new and hot tech to the detriment of solving the business problem. I've seen this happen in two, sometimes overlapping, cases: 1. When the devs' agenda is about learning new tech rather than solving business problems. The ways to solve this are to incentivize devs at the business problem level (hard) or find devs who care more about solving business problems instead of learning hot new tech (easier). 2. When the product management function is weak within an org. Product defines the requirements, and makes trade-offs around the solution. A strong PM will recognize when a bazooka is being used to kill a fly, and will push dev to make smarter trade-offs that result in a cheaper, faster, more maintainable solution. This is especially challenging when the dev team cares more about shiny tech than solving business problems.

brazzy 9y ago
It's not necessarily devs pushing for hyped technologies that don't fit the business problem. Half- or nontechnical managers often follow tech hypes as well and may push for the project to use "Big Data technology" simply because it makes them feel more important to lead a project that is part of the hyped topic.
- mrec 9y ago
  Yes, I've seen this syndrome coming from (pretty senior) management far more than from developers. My suspicion is that it's more about padding the CV than just "feel[ing] more important" - they may well be behaving rationally at the individual scale, they're just responding to perverse incentives in the job marketplace.
- kareemm 9y ago
  Agreed! This falls into the "weak product management" category imho. FWIW I think most devs could learn how to push back on poor decisions like this made by non-technical managers as it really shouldn't be the manager's responsibility to dictate technology choices for a solution. It should be their responsibility to push the dev team to make tradeoffs in order to achieve a business result. Devs who are good at understanding the business objectives and pushing the non-technical team to make better decisions are both wonderful to work with and command higher salaries / fees.
jdmichal 9y ago
I would say that business work and new tech should basically never meet. Scout the technology ahead of business needs. If you want to look at new tech, you should be doing a proof-of-concept that the business is not depending on. If you are doing business work, then you can either use things you know, or use a completed proof-of-concept to move in a new direction. But you should not mix business needs with that initial proof-of-concept.
komali2 9y ago
>incentivize devs at the business problem level What does this mean? What is "the business problem level?"
- metaphorm 9y ago
  the technical problem is "create secure tokens and distribute them in authenticated messages to N clients that have not established trust" whereas the business problem is "we want a user login system".
kwillets 9y ago
It's a cargo cult.
flamedoge 9y ago
I realize this whole thread is pushing back against undue scalable tools, but what if problem actually scales? Is it that foolish to take a risk on learning and deploying scalable tools vs. simpler ones?
- emiliobumachar 9y ago
  Good point. Maybe it's actually a good risk mitigation. Even if the odds of scaling that far are small, it may be worth it to make sure you're not squashing them further by introducing scaling issues to trigger the moment you have a big break.
FLUX-YOU 9y ago
Developers have been telling other developers that they need to study and learn new tech to survive. Developers have also been telling other developers that switching jobs is the best way to maximize their paycheck. It's debatable whether developers should study this new tech on their own time or not, but there's clearly developers who would prefer to do it on the company's time. Naturally, some developers will learn new tech while solving a company's problem so they can get paid to learn new tech. Combining all of these things, it's rather obvious why developers are building solutions to simple problems with new tech. If you want developers to act differently, you have to change the narrative (or incentives) around new tech, jobs, and salaries. You can't blame us for doing the things we've been told to do by our peers for at least the last 5 years.

brazzy 9y ago

It's not necessarily devs pushing for hyped technologies that don't fit the business problem. Half- or nontechnical managers often follow tech hypes as well and may push for the project to use "Big Data technology" simply because it makes them feel more important to lead a project that is part of the hyped topic.

mrec 9y ago
Yes, I've seen this syndrome coming from (pretty senior) management far more than from developers. My suspicion is that it's more about padding the CV than just "feel[ing] more important" - they may well be behaving rationally at the individual scale, they're just responding to perverse incentives in the job marketplace.
kareemm 9y ago
Agreed! This falls into the "weak product management" category imho. FWIW I think most devs could learn how to push back on poor decisions like this made by non-technical managers as it really shouldn't be the manager's responsibility to dictate technology choices for a solution. It should be their responsibility to push the dev team to make tradeoffs in order to achieve a business result. Devs who are good at understanding the business objectives and pushing the non-technical team to make better decisions are both wonderful to work with and command higher salaries / fees.

jdmichal 9y ago

I would say that business work and new tech should basically never meet. Scout the technology ahead of business needs. If you want to look at new tech, you should be doing a proof-of-concept that the business is not depending on. If you are doing business work, then you can either use things you know, or use a completed proof-of-concept to move in a new direction. But you should not mix business needs with that initial proof-of-concept.

komali2 9y ago

>incentivize devs at the business problem level What does this mean? What is "the business problem level?"

metaphorm 9y ago
the technical problem is "create secure tokens and distribute them in authenticated messages to N clients that have not established trust" whereas the business problem is "we want a user login system".

kwillets 9y ago

It's a cargo cult.

flamedoge 9y ago

I realize this whole thread is pushing back against undue scalable tools, but what if problem actually scales? Is it that foolish to take a risk on learning and deploying scalable tools vs. simpler ones?

emiliobumachar 9y ago
Good point. Maybe it's actually a good risk mitigation. Even if the odds of scaling that far are small, it may be worth it to make sure you're not squashing them further by introducing scaling issues to trigger the moment you have a big break.

FLUX-YOU 9y ago

Developers have been telling other developers that they need to study and learn new tech to survive. Developers have also been telling other developers that switching jobs is the best way to maximize their paycheck. It's debatable whether developers should study this new tech on their own time or not, but there's clearly developers who would prefer to do it on the company's time. Naturally, some developers will learn new tech while solving a company's problem so they can get paid to learn new tech. Combining all of these things, it's rather obvious why developers are building solutions to simple problems with new tech. If you want developers to act differently, you have to change the narrative (or incentives) around new tech, jobs, and salaries. You can't blame us for doing the things we've been told to do by our peers for at least the last 5 years.