4 ms·

Cultural challenges is just as a big of a component as the technical challenges

gmarx 10y ago
I'd say bigger and more frequent. I've never had a problem that went unsolved because the developers didn't have a reasonable tech solution. I have had things fail because developers don't grok the spec/requirements/domain. I'd rank technical challenges well behind culture and domain understanding as reasons software projects fail
- tonyedgecombe 10y ago
  That raises interesting questions about how we hire.
- brilliantcode 10y ago
  Would you say a groupthink is a possible cause? In the past I've seen developers band behind a specific technical platform or framework without considering the possible downsides and constraints that were raised by a few individuals. Not even having a conversation around it but "this is how we do things here, we are an X shop". It makes me uneasy when everybody's answer is exactly the same and they arrived it not through individual opinions but by adapting to whatever was set in place. This isn't bad if all options were thoroughly explored or possible pitfalls addressed (there are no absolute, only subjective and relative truths that come with pros & cons which each decision)....but when there won't even be a debate or conversation asking if what we are choosing to use is really the right thing because we thought it through independently or just because some big name at big company X declared it is the new paradigm. After all, we are all fallible, development and tools we use is influenced more by marketing than proper cost/benefit analysis. Whatever seems hip, new, cool tends to triumph. "What? PHP is sooo 2006, we need a React/Redux app for our blog so it will be easy to scale using node.js asynchronity"
  - zigzigzag 10y ago
    I wouldn't describe that as groupthink. Groupthink has a fairly clear definition and set of symptoms, well, clear by psychology standards anyway: https://en.wikipedia.org/wiki/Groupthink https://en.wikipedia.org/wiki/Groupthink What you're describing doesn't have any obvious "out" group in it. I think instead what you're describing is what you'd expect to see in an environment where judging the merits of tools or processes is very hard and requires a lot of experience, which may be lacking. In such an environment it's natural to look to very successful companies and just copy whatever they're doing, even if you don't fully understand it, in the hope that it works out. And sometimes it will. This isn't helped by the massive expansion of the developer workforce over the past decades, the fact that experienced people tend to get promoted up into management where they lose touch with coding and become 'architects' working entirely in the abstract, the fact that it's almost impossible for firms to correctly match team sizes to the amount of work required resulting in frequent periods of either overload or boredom (that then leads to reinvention of the wheel simply to find something interesting to do). And yes, finally, fashion plays way too large a role in things these days. If I had a dollar for every time I read a blog post along the lines of "we had entirely generic serving problem X and we had to pick between Rust, Node or Go", with the far older and more mature .NET/Java stacks not just discarded but entirely unconsidered, I'd be a rich guy. We end up locked in a vicious circle that works against maturity of tools and processes: - Profitable but slow enterprises look at startups, envy their ability to get things done and wonder if it's because of the stodgy old tools/processes they use. - Fast but money-bleeding startups look at enterprises and say "we aren't a stuffy enterprise shop so we'll do whatever cool thing I read about on hacker news the other day" and often end up boxing themselves into a corner with immature tools or business approaches. Eventually they (might) turn into big slow companies themselves, often entailing either a rewrite along the way to use more traditional tools or absurd investments into digging themselves out of technical debt (Facebook's PHP runtime efforts being a case in point)
    - brilliantcode 10y ago
      In your opinion, where does the current state of Javascript and it's fractured development tools, processes and frameworks fare against mature stacks? You are totally spot on in that mature stacks don't even make the list. Obviously, new developers are going to be exposed to the new and hip fashion trends while veterans prefer predictability and stability. It keeps me awake at night thinking about who is right. It could be that we are on the eve of a new paradigm where JS dominates the enterprise or we could be seeing another blip on the radar. I do however think that AWS is a definite paradigm shift in how developers work, especially as serverless is gaining momentum but this is more of a devops/serverops shift imo.
  - gmarx 10y ago
    I wouldn't. I also think it is a small subset of projects in which specific technology choices are critical. Also, it seems you are describing to opposing problems, one shop only wants to use the technology it knows (in my opinion this should be the default position) and another in which they mindlessly want to use the latest and coolest. It takes a very knowledgeable manager to tell the rare cases of "we need the latest tech" from "my engineers want to play with the latest tech"
rodgerd 10y ago
Technology is easy, people are hard.

gmarx 10y ago

I'd say bigger and more frequent. I've never had a problem that went unsolved because the developers didn't have a reasonable tech solution. I have had things fail because developers don't grok the spec/requirements/domain. I'd rank technical challenges well behind culture and domain understanding as reasons software projects fail

tonyedgecombe 10y ago
That raises interesting questions about how we hire.
brilliantcode 10y ago
Would you say a groupthink is a possible cause? In the past I've seen developers band behind a specific technical platform or framework without considering the possible downsides and constraints that were raised by a few individuals. Not even having a conversation around it but "this is how we do things here, we are an X shop". It makes me uneasy when everybody's answer is exactly the same and they arrived it not through individual opinions but by adapting to whatever was set in place. This isn't bad if all options were thoroughly explored or possible pitfalls addressed (there are no absolute, only subjective and relative truths that come with pros & cons which each decision)....but when there won't even be a debate or conversation asking if what we are choosing to use is really the right thing because we thought it through independently or just because some big name at big company X declared it is the new paradigm. After all, we are all fallible, development and tools we use is influenced more by marketing than proper cost/benefit analysis. Whatever seems hip, new, cool tends to triumph. "What? PHP is sooo 2006, we need a React/Redux app for our blog so it will be easy to scale using node.js asynchronity"
- zigzigzag 10y ago
  I wouldn't describe that as groupthink. Groupthink has a fairly clear definition and set of symptoms, well, clear by psychology standards anyway: https://en.wikipedia.org/wiki/Groupthink https://en.wikipedia.org/wiki/Groupthink What you're describing doesn't have any obvious "out" group in it. I think instead what you're describing is what you'd expect to see in an environment where judging the merits of tools or processes is very hard and requires a lot of experience, which may be lacking. In such an environment it's natural to look to very successful companies and just copy whatever they're doing, even if you don't fully understand it, in the hope that it works out. And sometimes it will. This isn't helped by the massive expansion of the developer workforce over the past decades, the fact that experienced people tend to get promoted up into management where they lose touch with coding and become 'architects' working entirely in the abstract, the fact that it's almost impossible for firms to correctly match team sizes to the amount of work required resulting in frequent periods of either overload or boredom (that then leads to reinvention of the wheel simply to find something interesting to do). And yes, finally, fashion plays way too large a role in things these days. If I had a dollar for every time I read a blog post along the lines of "we had entirely generic serving problem X and we had to pick between Rust, Node or Go", with the far older and more mature .NET/Java stacks not just discarded but entirely unconsidered, I'd be a rich guy. We end up locked in a vicious circle that works against maturity of tools and processes: - Profitable but slow enterprises look at startups, envy their ability to get things done and wonder if it's because of the stodgy old tools/processes they use. - Fast but money-bleeding startups look at enterprises and say "we aren't a stuffy enterprise shop so we'll do whatever cool thing I read about on hacker news the other day" and often end up boxing themselves into a corner with immature tools or business approaches. Eventually they (might) turn into big slow companies themselves, often entailing either a rewrite along the way to use more traditional tools or absurd investments into digging themselves out of technical debt (Facebook's PHP runtime efforts being a case in point)
  - brilliantcode 10y ago
    In your opinion, where does the current state of Javascript and it's fractured development tools, processes and frameworks fare against mature stacks? You are totally spot on in that mature stacks don't even make the list. Obviously, new developers are going to be exposed to the new and hip fashion trends while veterans prefer predictability and stability. It keeps me awake at night thinking about who is right. It could be that we are on the eve of a new paradigm where JS dominates the enterprise or we could be seeing another blip on the radar. I do however think that AWS is a definite paradigm shift in how developers work, especially as serverless is gaining momentum but this is more of a devops/serverops shift imo.
- gmarx 10y ago
  I wouldn't. I also think it is a small subset of projects in which specific technology choices are critical. Also, it seems you are describing to opposing problems, one shop only wants to use the technology it knows (in my opinion this should be the default position) and another in which they mindlessly want to use the latest and coolest. It takes a very knowledgeable manager to tell the rare cases of "we need the latest tech" from "my engineers want to play with the latest tech"

rodgerd 10y ago

Technology is easy, people are hard.