I like that idea as well, but the problem is that your manager will, over the long term, change. Most people have no insurance against some person they've never met being hired above them. You need enough independent credibility to protect yourself against that. You have 5 years of managerial experience, so you probably have enough work experience that any job move would be a likely promotion, so your company has incentives not to treat you badly.

I used to think the software industry was about programming: writing great code to solve hard problems. It's not. It's about credibility and technical risk. The software industry is 90% industry and only 10% software. Most of your time will be spent convincing people to allow you to do useful stuff, not actually doing useful stuff.

The ironic thing is that, as software jobs increasingly slide toward looking more like widget-making and less like research, programmers become a lot less effective. Valve established that open allocation works. (http://michaelochurch.wordpress.com/2012/09/03/tech-companie...) Every other software shop has proven that the alternative (still more popular) doesn't.

The Death of R&D, I think, will be looked upon as the "conscious" decision (of course, large groups such as nations do nothing "consciously"; it's a historian's metaphor) of the United States to go from a world leader to third-rate in a few decades.

Most of my experience has been in product-focused teams, so there is a good mixture of R&D and polish work. The company as a whole has to spend time convincing customers that our product is useful, but the development team is able to focus on actually making a useful product.

I can see how what you're saying could be a much bigger problem in a project-focused organization (or if you're working on a product that isn't actually useful). So maybe my advice is twofold: "find a good manager and stay with them, and work for a company that values software for its long-term potential."

My version of "values software" is that it be mission-critical. If it breaks, we're going to be chatting at 2 AM and testing a patch at 3, because we'd lose vast sums of money or customers by waiting until after breakfast. I met my favorite manager turning around a shop like this.

Most software is utter garbage because everyone knows better than to actually rely on it and nothing bad happens to incompetent people maintaining it.

Just making heads roll is not going to magically improve software. You can keep firing your teams but if there are other issues like unrealistic deadlines, bad process you are going to get bad output even from good people; all firing will achieve is churn.

I don't necessarily mean firing people (though there are some who really aren't good fits for this work). I mean I see better work from people who literally lose sleep over bugs, rather than merely shrugging.