Our economic model encourages this kind of race to the bottom enshitification of everything. Unfortunately there are no high-tech solutions to this problem. The technology we need to improve is our political/economic system.
Perhaps with wealthy country populations projected to fall dramatically we will finally be forced to find a way other than "growth" to value human endeavour. That would be the most likely path to a solution, I fear it will be rather painful.
> I'm curious: in your many years of being a consultant to these bad teams, where the manager really thought they were top 20%, did you get a chance to talk to the rank-and-file team members, and did they paint a very different picture of the team health and software quality than their manager?
Yes, generally I join teams and work as an engineer or sometimes as a team lead, so I'm talking to all the team members.
Most start up teams are composed of junior developers, often pretty smart people. Usually 5 or fewer years of experience. Many times these are people who have already accomplished stuff they didn't think they could do. So that generally means that yes they think pretty highly of themselves. To a degree it is quite justifiable, they tend to be very accomplished but in a narrow domain. Unfortunately they don't realize that their technical accomplishments in a specific field does not mean that they are experts everywhere. Their managers understand that these are smart people and assume again that this is therefore a good team.
Non start ups that I join are usually just plain dysfunctional.
> Also, did you run across any orgs where they basically refused to use a process like Agile, and instead just did ad-hoc coding, insisting that this was the best way since it worked just fine for them back when they were a 5-person startup?
Usually more the opposite. In my experience I come across teams that are sure they must not need any help because they follow all the rules in Scrum and have great code coverage metrics.
It is really common to see this kind of thing. I call it "the proxy endpoint fallacy". It can crop up anywhere that there is something that can be measured. In that example, it would be confusing adherence to Scrum with having a working SDLC or perhaps confusing code coverage metrics with the objective of having bug-free releases.
This isn't a software only fallacy. In politics, GDP is often confused with societal well-being. Always be wary of your metrics and change them as required to keep you tracking your actual goals.
> Does it make sense to degrade the performance of good software teams because bad software teams exist?
Consider the classic statistic "most drivers think they are above average".
I posit that the same is true of software teams, almost every team will self-assess as above average, i.e. good. Those teams will then imagine that, being good, they build quality into the process and very little verification QA is done.
I have worked as a software consultant for 15 years now. I've worked with at least 40 separate software teams in that time. Every single team manager would pep talk with "this is the best team I've ever seen". Some of this is obviously blowing smoke to get people to work harder and feel good. But over the years I've had candid conversations with managers and realized that most of the time the genuinely think their team is really good, truly top 10-20%.
Here's the rub. Being a consultant, I'm almost always brought in by higher level management because something is going horribly wrong. The team can't deliver quickly. The software they deliver is bug ridden. They routinely deliver the wrong software (i.e. incorrect interpretation of requirements.)
Often times these problems are not only the fault of the development team, management has issues too. But in every single case, the development team is in dire straits. They have continuous integration sure, and unit tests, and nightly builds, and lots of green check marks. But the unit tests test that the test works. The stress tests have no reality based basis for expected load. The continuous integration system builds software but it can't be deployed in that form for x, y & z reasons, so production has a special build system, etc...
In 15 years I have never once encountered a team that would not benefit from a QA team doing boring, old school, black box manual testing. And the teams that most adamantly refuse to accept that reality are precisely those that think they are really top tier because they have 90+% unit test coverage, use agile and do nightly builds.
So, my question is, do you (I don't mean the specific "you" here, rather everyone should ask themselves this, all the time) think that most bad software teams know they are bad? Including the one you are part of? Would it really hurt to have some ye olde QA, just in case, you know, you are actually just average? :)
Not only do students come into university (and sometimes even into CS) not knowing what a file system is, many of them have a total lack of interest in learning what is perceived by them to be pointless.
I'd argue it is going to be pretty difficult to engage with any of those foundational topics if you aren't willing to engage with the basic metaphor of most operating systems, files and directories.
> My sales team keep asking me to add AI to X product. Doesn't matter if it's not required, or even makes sense they ask because the competition is doing it and they get asked by our clients/prospects in an expecting tone, if we offer some AI on our products.
It could be worse, they might be asking you to put it on a blockchain :P
We use Microsoft Azure AD B2C to manage users. AD itself is a nice (for enterprise software), is used all over the place and is pretty stable.
B2C on the other hand is a different story. Every few months we have to roll out a new tenant in our system. Tenants are identified by B2C "applications". Every single time, the new application doesn't work. Every single time the fix involves editing the JSON spec, changing something random (like a "true" to a "false"), saving, and changing it right back again.
Doesn't exactly inspire confidence... we're planning a migration to AWS.
Also, try Googling for documentation related to "Microsoft Azure AD B2C". Almost every shred of internet wisdom is related to AD and not B2C. Even with Microsoft's own documentation you sometimes follow a link from a B2C API reference and find yourself in AD-only land and it isn't obvious. This makes the task of researching features and debugging infuriating.
First, Boeing doesn't prioritize safety anymore. Profit is the driving factor in their decision making. You can read about the issues they have assembling the 787 in South Carolina. It is so bad some airlines are refusing to take delivery unless the plane is validated by the assembly line in Washington.
Second, the FAA was caught being complacent with the 737 Max. It will take some time to fix that, but it is clear they don't want to make the same mistake. Also, the EASA is no longer just rubber stamping approvals following the FAA. Both agencies are combining to improve safety, which is highlighting the management problems at Boeing.
> Simpler code base from not having to worry about concurrency and multi-threading
This kind of thing irks me when I read it. I don't understand why people think of microservices as an architecture pattern. To me they seem more like an implementation detail.
When it comes to concurrency and multi-threading, microservices mean you have different problems to worry about, not that they go away. I try to get people on my projects to imagine microservices as network function calls. If you diagram out how your data flows, how your concurrency works, you tend to see that a microservice is roughly a thread in a monolith. You gain not worrying much about mutexes or shared memory, but you lose on performance. Languages like Rust let you get close to having your cake and eating it too.
It is also a useful exercise for teams to consider "how big does my service need to get before microservices on Python scale better than a 64-core monolith in C/C++/Java/Rust?" Another good question, "if a monolith is stateless, does it scale as well as microservices?"
Sure one way to read this story is "I don't want to work harder" and criticizing that attitude.
Here's another way. As the worker, already working full-time, maybe you have better things to do with your life than working harder. Furthermore, the worker is probably thinking:
"If they want me to work more hours, why not pay me for more hours, including time-and-a-half overtime, per the law? Why offer a profit-share? Answer, mostly likely because the profit-share costs them less, and therefore, pays me less".
In that light, unless the factory management can explain how the extra hours they want people to work is likely to work out better for them then just getting paid for more hours, why should they accept?
Sure you can find an edge case in my general statement.
> The evidence of people usually choosing to retire
The key word in that is "choosing". A huge number of people even in G7 countries comprise the working poor. They cannot, and likely will never be able to "choose" to retire. They work 40hrs/wk, often with two incomes and have no savings.
While we can debate the life choices of some of these people, it remains that working 40hrs/wk should not lead to an outcome where you can only just scrape by.
This kind of concern crops up in UBI discussions all the time, but I think it gets things backwards.
Instead of asking if some significant number of jobs will go unfilled because people are paid a poverty line level of income by the government, we should be asking:
"Why aren't we paying people who work 40hrs/wk a living wage?"
The decision not to work and live off of UBI is only attractive to people who are currently working many hours and earning about the same as what UBI is offering -- and that should give us pause.