Say what you want about European financial organizations but they are legally obliged to practice their recovery strategies. So every other month production clusters with all user data get teared down in one cloud region and set up in another one over night. This works surprisingly well. I guess they would never do that without the legal requirements.
... but then you have two competing organizations: OLD versus NEW. This is how it plays out: NEW starts as your shiny, agile, start-up-ish org with all the young people with the latest ideas. A company nearby got rid of all their freelancers? Great, let´s hire all of them. Think big. Great meetings and people seem to really make progress happen. We´re getting rid of all the REST APIs and introduce Apache Kafka as a message bus for the company. Only then progress stalls and OLD slowly begins to crawl back in. Legal department audits the agile process and unfortunately German laws are quite tough on bogus self-employment. All the freelancers have to go and NEW loses all their expertise. Other employees follow as this whole thing does not pay that great and looks more and more like any other 9/5 job.
Fast forward, 5 years later: the startup spirit is long gone. Corporate culture at NEW mirrors OLD. And not only culture wise. The NEW, "-tech" company is not seen as an independent company any more but supposed to be merged with the parent company. Because why have two of the same, right? Meanwhile OLD made some progress and introduced some reform projects. So developers do not have to fill out a printed paper application to get new servers any more. Only now you have two Kafka clusters with completely different setups as OLD also started their one one at some point.
My learning here: new is not new if the culture stays the same. Also: never underestimate the power of old. People always talk about the new, shiny stuff. But old was there first. And is much more resilient than it seems.
Paying good salaries (2x market rate) to 300 people will still be much cheaper than paying market rates to thousands of people (which is what legacy orgs currently do) and then the problem goes away. Disguised self-employment is not the only way to run a successful engineering team.
Same here. Tried to connect an old Midiman Midi interface to a recent MacOs. Oh boy. Someone built a driver and I´m grateful for that but it was quite something to get the thing working. It seemed to me a waste to buy a new piece of hardware for some antique technology like Midi, just because the driver of the old interface was not working any more. I don´t mind dealing with pain caused by computers in my day job. But in my free time as a musician all those technological hassles are a hindrance of creativity.
Last time I checked programming had something to do with computer science. You could say its applied computer science. So I ask myself: how come that this discipline, already 50+ years old, has almost no consensus of how its output aka written code should be structured? Why are there no established standards or rules? Not a rethorical question, happy to hear your thoughts.
"Structure and interpretation of computer programs", its not exactly in the same category but IMO is far better. At least it doesn't make you write tones of one line,single time used functions with 400 character length name.
The pragmatic programmer is really keen on code generators. Which is the right thing to do. It's also very difficult to do in practice as the languages that are sufficiently impoverished to need external code generators are invariably bound to build tools that can't sanely deal with them.
edit: oh, and also it's hard to avoid people checking in and/or editing the generated code
I don't understand why you would acronym your book recommendation. Anyone this would be a useful recommendation to would not know about it already, and hence not understand the acronym.
> If you're 100% serverless then this doesn't really apply, but if you're spinning up eight different Kubernetes clusters for eight different teams then you probably need to collaborate a bit better.
This is exactly the situation I´m currently in. Company decided to migrate from big on-prem kubernetes to AWS. Now every team got their own account and well... good luck, you´re on your own now. We´re a small team of three developers. Although we have three certifications under our belts (AWS Dev, CKA, CKAD) it took us almost three months to configure AWS and set up the Terraform pipeline and define processes like "upgrading cluster". The "enabling" part was basically missing in the whole cloud strategy of the company. It was more like: good luck, you´re on your own now.
In fact we made contact with a neighboring team. Only to find out that their use case was so different from ours that collaboration didn´t make any sense. For them Kubernetes was not a good fit, for us it was the way to go.
Speaking of sharing a cluster or AWS ressources: we figured out that it is not allowed due to billing reasons. Company policy is: One product per AWS account.
If you ask me I see a shift of paradigms happening here. Now you hear a lot about "enabling teams" instead a dedicated team for infrastructure providing services (e.g. the Kubernetes podcast from Google). I´m not convinced yet. I think this is more like kicking down responsibility down the chain. And then it feels more like: Someone needs to do the dirty work but nobody wants to do it.
It might work if you don´t have to provide Service-level agreements (in our case: we don´t). For us it is just more work to do. And our work shifts from dev to ops. Instead of writing software we´re mostly busy with configuring cloud resources. This will ease a bit once everything is running. However: I see this whole change more as ... uh, strong word... ideologically motivated. Cui bono? Neither our team, nor our users nor our infrastructure bill.
> it is not allowed due to billing reasons. Company policy is: One product per AWS account.
That's kinda funny because half the reason why AWS has tags in the first place is to get finer granularity into understanding billing. Not to mention products like Kubecost. Sounds like whoever wrote the policy doesn't understand how AWS works.
> Someone needs to do the dirty work but nobody wants to do it.
There are plenty of people willing to do the dirty work, they're just already working for other companies and their salaries are quite high. The labor market is tight.
> Cui bono? Neither our team, nor our users nor our infrastructure bill.
HR benefits. Having open positions that HR is failing to fill is a bad look for HR.
Not everything can be tagged to get the source of the cost - for example I don't think you can differentiate which of your products generated egress network traffic (which is quite costly as soon as you reach certain scale). I might be wrong, I switched to separate-account-per-product a while back and never looked back.
You are joking but this place exists, in California in the middle between SF and L.A. and spent 5 months there. Didn‘t write an article about it though.
Why does it have to be the CEO? My first association was that Winston Wolfe character from Pulp Fiction. Wouldn´t it be neat if companies had that kind of fixer who you could call for the real hard problems? Like problems that arise from the structure of the organization and cannot be fixed on a micro level. Asking half joking, half serious.
That's who I aspire to be, but my batting average isn't that fabulous, maybe .200, and it's really difficult to sell to people, because you have to catch it right on the cusp of being a recognizable problem.
So people are inherently skeptical, and by the time it becomes obvious that they need some outside heavy hitter, it's too late for that strategy to be effective.
I'd really like to systematize it, to be known as the solution for that kind of problem, but that's a different skillset than actually solving the problem, of course.
i have a bit of a reputation for doing this, and a few personal relationships with business leaders who have tapped me for these kind of projects. in the end its kind of dysfunctional every time because various people in the org own the relevant responsibilties already and you are basically micromanaging them against their will as a prelude to termination or reorganization.
its not like the solutions are usually that hard to figure out, it's always a problem with people and their incentives ultimately.
the fixer role is basically to give confidence to the CEO that disempowering certain people is safe and there's a path out.
