The answer to the titular question seems to be “No”, of course, and the OP gives some interesting detail.
Producing data on the productivity of software engineers is really hard, as OP acknowledges, because anything that we can reliably measure and specify, we can program. The only work left for humans is the stuff with some creativity or finesse in it, and that stuff’s usually quite hard to estimate. Since most programming projects are, by definition, only worth doing once, there is no way to create repeatable experiments that isn’t prohibitively expensive. This game definitely has a “those who can, do; those who can’t, evaluate the work” aspect to it.
On estimates: the purpose of estimates is mostly to demonstrate power. Asking someone for an estimate is a way of reminding him that you can fire him or (much more likely) jerk him around if he doesn’t work fast at all times. It’s about humiliation and control, and this is something that programmers don’t get. They think that they should give a good-faith answer, when the real right answer is “Why do you want to know? Please involve me in the decision process that this information will be feeding into.” Make the trade of information a negotiation, not a genuflection.
Regarding Agile and Scrum, I’m comfortable calling it all a bunch of worthless, anti-intellectual junk. And the people who say, “So you’re a Waterfall guy” are just execrable. Waterfall and Agile are both subcases of business-driven development, which is fucking stupid in either case, unless your goal is to load up on useless commodity programmers because you plan on getting acquired and your price will be figured on a per-head basis. I say that we throw Waterfall and Agile both out and focus on technical excellence and letting the shots be called by the people doing the work as much as possible. This might mean not being so ready to hire everyone who graduates from a 6-week code bootcamp.
Agile is actually a reincarnation of “scientific management” or Taylorism, a collection of ideas that mostly failed, but that was immensely popular in the 20th century for its combination of management pseudo-science and mean-spirited denial fetishism. Basically, the ideas that failed everywhere else still find life in the software industry. Why? That’s a topic for another day.
Choosing a technology stack or programming language is legitimately hard, though. I would say that a company should resist being an “X Shop”, where X is a language, for as long as possible. Even the really good languages (e.g. Haskell) aren’t right for everything. It’s better to be a computer science shop and to accept that there’s more than one language in the world that is worth using.
The answer to the titular question seems to be “No”, of course, and the OP gives some interesting detail.
Producing data on the productivity of software engineers is really hard, as OP acknowledges, because anything that we can reliably measure and specify, we can program. The only work left for humans is the stuff with some creativity or finesse in it, and that stuff’s usually quite hard to estimate. Since most programming projects are, by definition, only worth doing once, there is no way to create repeatable experiments that isn’t prohibitively expensive. This game definitely has a “those who can, do; those who can’t, evaluate the work” aspect to it.
On estimates: the purpose of estimates is mostly to demonstrate power. Asking someone for an estimate is a way of reminding him that you can fire him or (much more likely) jerk him around if he doesn’t work fast at all times. It’s about humiliation and control, and this is something that programmers don’t get. They think that they should give a good-faith answer, when the real right answer is “Why do you want to know? Please involve me in the decision process that this information will be feeding into.” Make the trade of information a negotiation, not a genuflection.
Regarding Agile and Scrum, I’m comfortable calling it all a bunch of worthless, anti-intellectual junk. And the people who say, “So you’re a Waterfall guy” are just execrable. Waterfall and Agile are both subcases of business-driven development, which is fucking stupid in either case, unless your goal is to load up on useless commodity programmers because you plan on getting acquired and your price will be figured on a per-head basis. I say that we throw Waterfall and Agile both out and focus on technical excellence and letting the shots be called by the people doing the work as much as possible. This might mean not being so ready to hire everyone who graduates from a 6-week code bootcamp.
Agile is actually a reincarnation of “scientific management” or Taylorism, a collection of ideas that mostly failed, but that was immensely popular in the 20th century for its combination of management pseudo-science and mean-spirited denial fetishism. Basically, the ideas that failed everywhere else still find life in the software industry. Why? That’s a topic for another day.
Choosing a technology stack or programming language is legitimately hard, though. I would say that a company should resist being an “X Shop”, where X is a language, for as long as possible. Even the really good languages (e.g. Haskell) aren’t right for everything. It’s better to be a computer science shop and to accept that there’s more than one language in the world that is worth using.