Slow is smooth, smooth is fast.
It’s just not the only form of chaos.
But if I solved the speed problem I might bitch about chaos. And if I solved the chaos problem I might bitch about freedom.
My definition of a solution is to trade a problem you have for a problem you'd rather have.
This is not a technical problem. Try to find out who is accountable. Who gets fired when the software doesn't perform the way it should. Notice nobody gets fired. Because the whole chain of command is afraid of accountability for themselves.
And the company probably pays a platform team to offer a limited but supported tech stack.
The platform team is accountable for balancing the deprecation of outdated dependencies and the productivity of their users.
Either decision could easily be justifiable. The higher ups may have deliberately wanted to assure the teams were not stifled, or a team may have had a goal which demanded an exception to the rule. Still though, somebody had to have made the call and should therefore be able to justify it.
If an organization does not know who is responsible for something, then that is a failing at an even higher level.
And so, everything from Hollywood blockbusters to software solutions is created by committee. The end products are all box-checking, lowest common denominator throwaway garbage. No risks are taken. And very little value is delivered.
You need power to exercice accountability. Otherwise anybody can come shit in your codebase, and you are now accountable for it. Because you do not have the power to refuse the turd.
Authority: you, ops director, decide what goes in production and what doesn't.
There are now a lot of unpatched systems running out there that need their applications replatformed. Won't happen.
With Helm, yea, that's awful to inflict on developers, use Kustomize with Templates instead (https://kustomize.io/)
However, like most companies, Ops is easy place to cut and they commonly reduce us below outstanding workload. However, when they do, they still push the dev teams to deliver so here we are.
Helm is great idea and awesome for software that is not exactly sure what cluster environment will look. However, for internal software, almost all companies have clear defined Kubernetes environments where you don't have to worry about any of that and kustomize works great.
Use least amount of power instead of most amount of power. If kustomize no longer works for you, Helm is always there if you feel like torturing everyone. FluxCD/Argo support both happily.
I think the general idea behind kustomize is great. Sadly the execution is a mess of complicated code, with a billion of useless abstractions. Culminating into a tool that doesn't do what it promises. Including infinite loops. Yes I have had it get stuck on infinite loops during text matching.
And before anybody tells me to contribute to kustomize instead of complaining: 1) pay me for it. 2) actually don't, I don't want to touch this codebase. Reading it was traumatizing enough.
/ Greetings disillusioned dev once excited by the potential simplifications the “cloud” could bring, but all I got was a Fear and Loathing in Las Vegas level binge in bloat and this T-shirt.
Modern software is similar to the pyramids: it consists of millions of blocks held together by nothing but sheer weight and the labor of thousands of slaves.
For projects which I've built from scratch, I move blazingly fast. I can get more done on the weekend one day per week on a complex project than I can get done at my full time day job 5 days per week on a simpler project.
The difference is that in my side project, there is 0 unnecessary complexity. All the difficulties I face are intrinsic, unavoidable barriers to solving the problem.
In my day job, 90% of the complexity is not intrinsic to the problem but are created by the code /architecture itself.
I've been saying this over and over for years but it just doesn't seem to register in people's heads just how important the foundations are. The word "technical debt" is a highly accurate way to describe the issue because the costs compound, just like real debt which is not serviced regularly.
If you join a project which has too much technical debt, you can easily end up in a situation where you have 100 engineers moving at the same pace as 1 engineer could working on their own project.
So the 10x or even 100x engineer is real but you can only discover them if they can work on their own codebase from scratch.
I've seen several times people who were very average developers working for a company who later became 10x devs working on their own startup. I've also seen people who were same speed everywhere; those aren't 10x devs. At best they're a 2x dev because maybe they can churn out buggy tech-debt-ridden code at twice the rate as a normal dev. I've worked with devs who could code at twice the speed (and sustained); large amounts of code but it had bugs and eventually, everyone on the team ended up working at half the speed... Requires twice the amount of code to implement the same feature with lower quality.
Also, sometimes a company may have one person on the team who comes across as highly knowledgeable, good communicator but maybe a bit slow and they don't seem like a 10x dev... But remove that person from the team and after a year or two the whole team is much slower and nobody can figure out why. 10x devs are team productivity multipliers. They make everyone around them approach 10x speed.
What's preventing the Chaos from getting under control is political desire to do so. Google ships 5 times a day? Why don't we? /s
I think there's miscommunication. Maybe I'm misunderstanding. But when I say speed is a problem I mean that the world is complex and to go fast you have to cut corners. There's a fundamental truth that I think many people forget: as civilization advances, complexity increases. Think about this from a simple way. When you are in a new domain you can get away with low order approximations. They're better than... well... nothing. Which is what you had before. But as we get better you have to take higher order approximations to improve your results, right? And those higher order approximations almost always increase complexity. So that's the problem.
The need for speed makes you overlook small details. But as we get better those details matter more and more. They're counter to each other. There's strategies that are good but they have nuance too and it's like cliques were we forget the second half. Move fast and break things is great. You learn fast when tearing things apart. But you left a giant mess behind you. If you don't clean it up then the mess just builds. It's way faster and cheaper to clean up now than later. Just like cleaning a dish is way easier right after using it than when it's had time for the grime to set in and harden. Which, of course, this all compounds complexity, like the author states is the problem. Tech debt has interest but we want to pretend the debt doesn't exist.
I'm convinced this is what's leading to so much shitware. There's little pressure to actually improve because of centralization but everyone feels the need to move fast, so we move fast into nowhere. We don't want to fix problems, or even acknowledge them, because "new features" is more rewarding.
It's just a waste of a lot of money and time
visviva•5h ago
lenerdenator•4h ago
Actually a lot of teams at Boeing would like a word.
harshreality•4h ago
The article (glorified ad piece), however, is entirely about software engineering.