Lessons for software developers from 1970s mainframe programming
No.<p>I disagree with most of this article, and I have ~25 years experience.  No, I didn&#x27;t program mainframes, but I&#x27;m tired, as are younger programmers, of even older programmers trying to say that the way they did programming is still &quot;better&quot;.<p>The writer isn&#x27;t entirely wrong, but the simple fact is that software isn&#x27;t written the same way anymore. Stop trying to force antiquated methods down younger people&#x27;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.<p>15-20 years ago, we didn&#x27;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.<p>10-15 years ago, you aimed for 0 defects, especially for enterprise code, because your enterprise customers couldn&#x27;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.<p>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&#x27;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&#x27;t matter, all that matters is getting customer growth with new features as quickly as possible. Is that inherently wrong? No, it&#x27;s a different way of doing business. 10 years ago there was no such thing as a growth team.<p>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&#x27;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&#x27;s definitely not a paradigm that you would see back then, when you would have to schedule time, etc.