Hacker News Reader

Comment by JKCalhoun | Hacker News Reader

Having been in the industry since the around 1990, I can tell you that in the first half of my career we had no code reviews, no scrum, no story points, no unit tests.

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.

View on HN

Definitely cultural. I have been watching engine teardown videos. The difference between the Japanese motors and American motors is stark if you know what to look for. Engineers were clearly in charge of designing every aspect of the Japanese motors. American engines have so many compromises and they flip-flop on internal parts and designs, that look whilly-nilly in comparison.

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.

I would be interested to know your career history in more depth.

To my understanding even IBM in the 70s had stupid ways of measuring productivity (KLOCs?).

I'm pretty sure there were companies doing stupid things in the old days but in my experience, back then managers were supposed to know what developers were doing, and if they were delivering value or not.

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.

I wrote games until 1995, then started at Apple. I worked at Apple until 2021 when I retired.

Apple very much was engineer-driven when I began. That changed when Steve Jobs returned.

Scrum and story points I agree with, but unit tests? You'll have to pry those out of my cold, dead hands!

That's fine. Myself I have little use for them, I prefer functional testing. (Also, before unit tests we leaned on parameter checking in the live code — a kind of always-on unit test I guess).

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.

Reply on news.ycombinator.com