5 ms·

In my experience most of these problems are cultural and there is nothing to be done once bad software dev culture takes root. The most common manifestation is

• ryandrake 10y ago
  The good software companies I've worked for had a culture where people are able and empowered to push back on terrible ideas. The best ones are where that behavior is not just possible but expected.
  • chocolatebunny 10y ago
    What wonderful utopian companies did you work for? In the last round of layoffs in my company, I saw good, experienced, developers get pushed out because they promoted good ideas and tried to stop bad ideas from happening. Now everyone keeps their head down and projects are always in panic mode.
    • ryandrake 10y ago
      Unfortunately the places you describe far outnumber the places I describe. My "utopian" companies both degenerated into into "head down panic mode" places and I bailed.
      • AnimalMuppet 10y ago
        I've seen that happen, too. A place has realistic, sane management... until it doesn't. If you are at a place with sane management, though, don't be in a great hurry to leave...
        • nine_k 10y ago
          When an engineer makes a stupid decision, there are peers who point at it during code review. What is the equivalent in management? Does it exist?
          • ryandrake 10y ago
            Every profession contains at least some form of feedback: From your manager, from your peers, and/or from your subordinates.
          • cookiecaper 10y ago
            No, not as far as I know. Management is very different from engineering because there is no objective right or wrong, it is all subjective and all about the feelings of the people around you. Management is essentially a babysitting exercise. If you keep your people from throwing tantrums, having meltdowns, and going against the grain, you succeeded, and if you didn't, you failed. Peer criticism is thus inherently orthogonal to management because very few people can maturely handle even a mild quantity of criticism. Keeping colleagues and superiors in a good emotional state is even more important for career development than executing your job description in a non-disastrous way. Directing a business is much different from management, even if some management is required, but even then it's difficult to pinpoint cause and effect because there are so many externalities. You'd think this would mean that good people who can deftly juggle a ton of variables are attracted to such positions, but in practice it seems that people who are bad at things and depend on having many ambiguous potential causes to diffuse fault over take them instead. That's definitely the case in management; people who are incapable fall into those positions because their performance can't be definitely measured.
            • samnwa 10y ago
              That's not true. Managers are measured on delivery, customer satisfaction, and revenue or profitability. These measures are directly related to ability to manage inputs (engineering resource) to outputs (finished code that drives those measures).
      • alexvoda 10y ago
        Let me guess, one of the places was VmWare?
      • cookiecaper 10y ago
        Yes, this is critical. 99% of companies are run by cogs. It really takes a committed visionary at the top to set the tone for the culture, and at some point, those visionaries have to go away due to retirement, death, etc. There is a 99% likelihood that they will be replaced with another cog when this happens. We must not become overly committed to a company, because a company is only as good as its people, and people come in and out all the time.
• jordache 10y ago
  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)
• awinter-py 10y ago
  Very important point on good tech managers. Strong engineering orgs hire managers who could do and have done most of what their team does. Most TPMs at G, for example, have CS degrees. Non-technical managers have the organizational leverage to undo any amount of design & planning that skilled people underneath them set up. It's the brain equivalent of having ADHD -- your executive control shuts down and that sabotages long-term goals. If you've never lived through this, watch the beginning season 3 of silicon valley where their new CEO wants them to 'just build a box' and gets angry when the conversation gets any more specific than that. (If you have lived through this, don't watch it -- it's too real).
  • gmarx 10y ago
    Another point WRT Silicon Valley episode that has lessons for the real world. Developer will do a much better job on a project they picked rather than one that was assigned to them. This might be a lot of the advantage tiny, new startups have over the giants.
  • samnwa 10y ago
    There's an assumption here that the amount of design and planning is the correct amount of design and planning. Your statement suggests you want your cake and to eat it too. You want freedom from management, but then want exact specification when advised to "build a box." There is likely a happy medium and I would suggest that your manager probably understands that dynamic more completely than you. Edit: Agree that technical managers are best suited to evaluate the level of design and planning.
• samnwa 10y ago
  I have seen this work the other way. Manager asks for something reasonable. Devs do not execute successfully on timeline. Devs complain it was unreasonable or unrealistic but refuse to review the process that got them there.