There was another study that estimated 30% of SW engineers in the US are net negatives: the company could lay them off, close the job opening, and profits would go up.
Of course, that means that another chunk are at breakeven, or such low ROI that the company profitability would go up if they got rid of the dead weight.
Using round numbers, probably 50% of SW engineers could be let go with overall positive impact. That ignores getting rid of their managers, cancelling purchased licenses, etc.
Which is a truly sad statement - but what it really indicts is all the management that hired and then kept all those people. Theyāre the ones who truly failed.
I overheard a manager at a conference once who said he had 600 developers. Two of them did all the work, and his job was to keep the other 598 from interfering with the two. I always wondered why he didnāt just fire the useless ones.
One of my colleagues is a former Silicon Valley employee who said that the SV companies hired far more people than they needed because they were more afraid that these people would either (a) be hired by their competitors, or (b) convince a venture capitalist to fund some idea that would overturn their business model, than of short-term profitability.
At some point, they manage to figure out which of those people are actually worth keeping. Hence the mass firings in SV earlier over the last 2-3 years.
(I should add that he didnāt relate this information on his own initiative; I happened to read about it elsewhere, and asked him about it, and he agreed with it.)
This is why Google Ventures exists. They keep tabs on the engineers that leave to start companies and try to get in on the action if it looks promising. They get to outsource most of the risk of R&D to early stage investors, while still benefiting from the returns.
Thatās due to technical debt and bad engineering practices. People donāt thoroughly test before jumping to system integration. People jump to coding before the requirements are clear. The last SW project I ran, we were told we had 12 months to do a āMission:Impossibleā (at the kickoff, by the PM). I threw out the bad practices the division had always done, required standard best practices from the 80s/90s, and the team met all requirements in 1/2 the time. The customer couldnāt believe the quality - they had to repeatedly try to crash it, and they couldnāt get it to even quiver. The QA manager said sheād never seen such quality.
So itās not hard, but doing good SW development practices is like losing weight: everybody says they want to do it, but nobody does what it takes to do it.