Lessons for software developers from 1970s mainframe programming

I want this as a paid service. For example, hey there person using chrome, install this extension and let random people run tests on their website, for the time and resources used you will be paid n, ok?

Then imagine having access to real computers on real networks hit your site over whatever time horizon you want. It would be great. If this could somehow be done on mobile that would be great too (maybe in a push notification way "1x test ready to run, click here to start", app opens, does it's thing, then closes)

Absolutely, 100%, should you optimise for your resources. In a lot of scenarios those resources aren't CPU, HD, memory and bandwidth, instead they are developers time. But certainly if computer hardware becomes more of a bottleneck (cost, time, etc) than man power, then optimising for hardware makes sense. Like most things in life, it isn't binary, and I believe most developers already embrace this, making compromises in order to meet deadlines, create maintainable and debugable code, writing code to help with tomorrows tasks, learn new techniques but attempting to apply new coding ideas that may help in future tasks, make code run optimally enough for the given scenario, etc.

For that matter, app stores could profile apps. Apple already has an on-device list of apps which consume the most battery. They could normalize the metrics to account for variables like display time and network traffic.

No.

I disagree with most of this article, and I have ~25 years experience. No, I didn't program mainframes, but I'm tired, as are younger programmers, of even older programmers trying to say that the way they did programming is still "better".

The writer isn't entirely wrong, but the simple fact is that software isn't written the same way anymore. Stop trying to force antiquated methods down younger people's throats. The way I wrote programs 20 years ago is inherently different from the way that I wrote programs 10 years ago is inherently different from the way I write programs today.

15-20 years ago, we didn't write tests. We had QA that wrote our tests for us. We tested the code as well as we could (I became pretty damn good at testing my own code) and then we threw it over a wall to QA. Today, we have zero QA and I write tests for my own code.

10-15 years ago, you aimed for 0 defects, especially for enterprise code, because your enterprise customers couldn't afford downtime. Today, in a SAAS environment, you care about defects but your have a global set of customers, and you roll your code out slowly and watch metrics.

I have a friend in growth at Facebook and his manager got mad at him because he was focusing too much time on testing his own code. Apparently he's supposed to leave that to external QA, and you can always fix the code later. On some growth teams, code quality and maintainability don't matter, all that matters is getting customer growth with new features as quickly as possible. Is that inherently wrong? No, it's a different way of doing business. 10 years ago there was no such thing as a growth team.

The way software is used is different, and the way software is developed is different. Mainframe methodologies, while interesting to read, is not relevant. Things like Optimize Upfront is nonsense to me, especially in a global context. You iterate on your features quickly, including optimization. You couldn't do that in mainframe computing, but these days I deploy to production 10 times a day, and depending on how I deploy, I can see problems fairly quickly and iterate without affecting most of my users. That's definitely not a paradigm that you would see back then, when you would have to schedule time, etc.