There has been an incredible amount of principles and practices added to our profession. Most of which are silly. Like Clean Code which is just out right terrible in terms of causing CPU cache misses as well as getting you into vtable for your class hierarchies. Most modern developers wouldn’t know what a L1 cache is though, so they don’t think too much about the cost. What is worse is that people like uncle Bob haven’t actually worked in programming for several decades. Yet these are the people who teach modern programmers how they are supposed to write code.

I get it though, if what you’re selling is “best practices” you’re obviously going to over complicate things. You’re likely also going to be very successful in marketing it to a profession where things are just… bad. I mean, in how many other branches of engineering is it considered natural that things just flat out fail as often as they do in IT? So it’s easy to sell “best practices”. Of course after three decades of peddling various principles and strategies and so on, our business is in even worse state than it was before.

In my country we’ve spent a literal metric fuck ton of money trying to replace some of the COBOL systems powering a lot of our most critical financial systems. From the core or our tax agency to banking. So far no one have been capable of doing it, despite various major contractors applying all sorts of “modern” strategies and tools.

The issue here is all these caches. Back in my day we didn't have caches and memory access time was deterministic - and expensive! We kept things in our 4-8 registers and we were happy with it. Programs larger than that weren't meant to be fast!

In reality those caches are going to be relatively meaningless except for short bursts of speed, because the 100,000 API calls and user/kernel switches, that windows does because of absurd abstractions, that happen in the time slice your program isn't running will destroy any cache coloring you attempt to code for.

Unless you’re doing your computation on DDR5 ram you’re easily looking running your code 100 times slower when you’re hitting L1 and L2 cache misses. Add to this that even a relatively simple loop over a 1000 entities where you alter 4 properties on each will run 20 times slower with a class hierarchy compared to a flat structure and you’re quickly adding a large performance loss to what you’re already paying for your 100.000 api calls.

Which might be worth it if something like Clean Code by the book was actually easier to read, maintain or do any form of team work on. I’d wager it’s not just your hardware which is going to have memory issues when you split that code out over 9 files and 3 projects though. It’s very likely that your own memory load struggles to cope, especially if it’s not code you’ve worked on recently.

The issue is that there is a vast chasm between software written by some competent guy and software written by a development team.

Yes and "software written by some competent dev" is a thing that stops scaling after an org reaches 100s or 1000s of devs.

Management then moves to a model of minimizing outlier behavior to reduce risk of any one dev doing stupid things. However this process tends to squeeze the "some competent dev" types out as they are outliers on the positive side of the scale..

True, but maybe we should utilise principles which don’t suck. Things like onion architecture, SOLID, DRY and similar don’t appear to scale well considering software is still a mess. Because not only can’t your hardware find your functions and data, your developers can’t either.

It’s a balancing act of course, but I think a major part of the issue with “best practices” is that there are no best practices for every thing. Clean Code will work well for somethings. If you’re iterating through a list of a thousand objects it’s one and a half time slower than a flat structure. If you were changing 4 properties in every element it might be 20 times less performant though. So obviously this wouldn’t be a good place to split your code out into four different files in 3 different projects. On the flip side something like the single responsibility principle is completely solid for the most part.

Maybe if people like Uncle Bob didn’t respond with “they misunderstood the principle” when faced with criticism we might have some useful ways to work with code in large teams. I’d like to see someone do research which actually proves that the “modern” ways work as intended. As far as I’m aware, nobody has been able to prove that something like Clean Code actually works. You can really say the same thing for something like by the book SCRUM or any form of strategy. It’s all a load of pseudo science until we have had evidence that it actually makes the difference it claims to do.

That being said. I don’t think it’s unreasonable to expect that developers know how a computer works.

> In my country we’ve spent a literal metric fuck ton of money trying to replace some of the COBOL systems powering a lot of our most critical financial systems. From the core or our tax agency to banking. So far no one have been capable of doing it, despite various major contractors applying all sorts of “modern” strategies and tools.

To be fair, it's possible that the current systems are just poorly documented. All the best strategies in the world are hopeless against poor documentation/spec work.

This is probably the case for some, but not for all of them. There have also been attempts at completely replacing something like our digital registration for elections system. Basically every adult is issued a voter card when we have elections, in the “olden days” you’d register at tables with people with big voter books, where they’d need time to find you which can generate some rather large queues in rush hour. With the digital system every voting card has a barcode as well as the other info and they can just scan your barcode which is much faster.

Anyway the old thing was build when the public owned their own IT. It’s been something like 25 years since that was privatised and nobody has been capable of replacing that old system, meaning that the old organisation which is now a private company has a monopoly. Which is against our law.

There is really not a lot to it technically. But apparently it’s proving impossible to replace the mainframe way of dealing with it through the CISC input terminal thing. I have no idea why, we’ve had some of our biggest IT suppliers taking turns at cracking it and nobody has been able to so far. I think the ultimate “must not break” deadline was 10 years ago.

This was the “easiest” example. A lot of the others have decades of stuff build on top of them. There is the COBOL core and what has been hard for people to replace here is the bi-temporal data. But on top of the maintain there is a myriad of different Java services (only Java if you’re lucky) which turn the data into something which can be worked with and consumed by well, http.