I often wondered why s/w development is always a rush at the expense of quality.
Well I do know why just don't agree with the principle of seeing how much the company can get out of a developer in x hours.
Well I do know why just don't agree with the principle of seeing how much the company can get out of a developer in x hours.
How on earth, you might wonder, did we ship software that worked?
I then saw all these things come down the pike one after another during the last half of my career.
Clearly to me every one of these benefit management who found themselves apparently unable to function without numbers, graphs, data of some sort. It has been a very obvious (to me) power struggle: management trying to get the upper hand and wrest any and all power (and autonomy, and decision making) from engineering.
It has been sad to me to have heard some new engineers come on board who like these things. It's just as well I retired when I did: it's probably me that is the odd man out now.
To my understanding even IBM in the 70s had stupid ways of measuring productivity (KLOCs?).
They did all that by walking around, chatting with everyone, helping devs, assigning tasks depending on the expertise level, sometimes doing boring work (like manual testing) to help devs, etc.
Of course, if a manager that has to handle Jira and Scrum meetings all day, then it gets difficult to do that.
Apple very much was engineer-driven when I began. That changed when Steve Jobs returned.
It's obviously cost cutting niggling and get-it-out-the-door histrionics causing this chaos. There is significant impact to longevity and durability, and required maintenance. Very wasteful from a global warming perspective.
Watch out for these late model ICE engines...do your research. If it's "newly redesigned!" step back and dig in.
Management though use the "percent coverage by unit tests" as some sort of safe/buggy software metric.
Management at one team I worked on was pushing for minimal 95% coverage with unit tests. I thought it was odd that they were so singularly focused on this issue. The impression I had was a that they felt that if you have full code coverage with unit tests, and the test pass — you can lay off the QA team because you are assured that you are shipping perfect software.
They are going to manage risk of low quality with risk of wrong product.