That's kinda dumb, but the book is super good, I learned a whole lot from it, and apply the principles basically all the time.
He's been banging the drum on testing for longer, and that makes up for a lot of craziness (I'm with you on microservcies, except where you have 1k+ developers where they might make sense).
But its a bit like a health influencer telling people to stay hydrated and blame him for his fans damaging themselves by trying to drink 10 liters a day.
On the other hand I don't know that having people dedicated to refactoring is necessarily ridiculous. At least "in theory, given unlimited resources".
Have any openings?
Most of my nightmares with microservices comes from where there has been > 1 per team. That came from people who read his "microservices are great!" blog post and just thought that they should build as many as possible. I used to hate him because of that - because it was a logical response to his blog post and people would use it to justify their technical decisions - with argument-from-authority.
In another company I worked at each team maintained ONE microservice and it worked really well.
Because it was a corporate environment with all the usual power politics, control freakery and lack of effective inter-team communication, even though it was more work overall and definitely a technically inferior solution, it did a neat end run around those systemic corporate issues by giving teams relative freedom of development, freedom of deployment and a deliberately simple, loosely coupled, standardized JSON interface to microservices run by other teams whom they didn't talk to much.
So, I get it, but I lost a lot of respect for him over his inability to parameterize his suggestions and the fact that he didn't seem to initially really understand why microservices worked so well for him.
Micro services are an attempted solution for having highly bespoke infrastructure that required difficult, long, manual, fragile deployments that were high risk, and thus didn’t happen often and delayed business value. The problem was that they saw that issue and thought it was monolithic applications, not just having bad infrastructure. 99% of the benefits of devops with almost none of the drawbacks are done by having all of the standard dev ops stuff like Cicd, containers, software defined infra, etc and just doing it on the normal monolith.
Eventually you do need to break things up, but the micro services single functionality, single team per service type of micro services goes way to far and harms more than it helps.
To me, it's the Clean Code of web services.
There in lies the rub, the majority of engineers don't work at companies that need the kind of scale that Facebook has.
The majority of us work at smaller shops that can get by fine without all the overhead that microservices introduce. The problem that I see is that there are to many folks not weighing the pros and cons of the architectural decisions they are making, and are just joining the cargo cult.
The same people are now saying creating microservices is a sign of incompetence and the smart thing to do is create monoliths.
But not to sound ridiculous, they bring a spin to it: they now say they create modules within the monolith.
Software engineering is like fashion. It goes full circle every X years.
If that were true, then moving to a microservice architecture they'd need 5 million instances of the microservice that replaces the part of the monolith that required 5 million instances in the first place, plus a couple of millies for all the other services.
On a small-medium vertical team at a large company? Probably-maybe not.
Many, many engineers (and managers maybe even more so) immediately jump to micro-services (often resume-driven development) where most companies have poor tooling and poor security knowledge that turn them into a living productivity-crippling nightmare to work with.
a lot of people are giving Martin flack that the idea sucks when the reality is they're implementing it poorly or inappropriately.
I generally hate the term “micro services”. They are just “services” and nothing new.
I’d love to hear more about your experience with a platform team and why you say they don’t work.
Yes it creates friction and reduces velocity at ticket level but it prevents misalignment errors in UAT and production. This can be solved somewhat by having dedicated product owners in each module but it's often not feasible for smaller companies and brings in too much non-technical chatter.
For example, if your product acts as a metadata repository as well as a task execution engine it is important that the execution engine modules access the metadata only using streamlined (and maintained) internal APIs and not hit the database or maintain duplicate metadata for different engines. This way you actually improve velocity at milestone/release level because you're free to make changes to the metadata codebase without breaking features in various downstream execution engines.
In my experience, with a well-scoped platform team, the integration phase of a release gets significantly smoother with fewer defects. YMMV based on product type and company size.
- Business hates and underfunds these teams because they are often blamed as being a blocker because of the previous statement. They are a pure cost center too. Career suicide joining them.
- Unless you have a very motivated team lead you will end up doing the work of the most aggressive and loud team leads from other teams. Anyone good at playing politics will dictate your roadmap.
- Given the first statement, how do you hire someone for these teams? If they are responsible for platform evolution, upgrades, CI + CD, making frameworks, writing scripts, improving developer experience PLUS you are the backstop for the full backlog of every other team so need a lot of domain expertise. You would need to pay someone a lot to do this right? Well no - because of point 2.
The idea of a platform team is one of those weird things that sounds obvious and clearly needed - until you marry the idea to that of any org that has layers of management + politics and a misunderstanding of the long tail effects of platform work.
An interesting thing that happened at our company when we ended up having a platform team was that the "Can do" attitude of our previously homogenous group of mobile devs stopped over night - "That's a platform role" became a common refrain.
Only small companies can silo everything into verticals.
The platform teams I've seen at scale are more focused on providing APIs and services for a business domain. Such as, you can have a platform team for KYC/KYB that develops integrations to document verification providers, and then have stream aligned teams that sit on top of that platform and use it in a product to onboard users. Or in payments, a platform team can manage all of the underlying banking integrations, and then a product team can use these APIs to develop a product that lets users pay for things online. I once managed a platform team that managed the internal ledger for a virtual wallet/venmo type company. There weren't many product features there, but they had to deal with scaling our transaction processing capacity, ensuring idempotency of money transfers, and providing an easy to use API for product teams to integrate with. For more academic/research minded software engineers, it's an awesome team to be on.
> making frameworks, writing scripts, improving developer experience PLUS you are the backstop for the full backlog of every other team so need a lot of domain expertise
This has more or less been the case for my entire tenure at my current company. Sure, I want to do X, but we're crunched for time almost always. And there's another team that probably handles X. So it would be irresponsible/wrong of me to work on X when someone else can handle it faster and "owns" it. Except, who owns it? Whose team do I contact? That, I never know. It's a shifting, amorphous creature that lives around the app development team; I am required to communicate with it but I don't know how. Ultimately I end up with many micro-blockers where I don't know if a given task is something I should be learning myself or passing off to someone else.
See Project Managers becoming 'scrum masters' rather than neatly disappearing.
Platform teams are similar, they sound plausible, but as you say the reality is pretty miserable. 'Enabling' others to do work eventually looks a lot like doing the work.
What I've seen is platform being the "elite" place to work, or at least the one where you can do cool things. Otherwise you're working with "cookie cutters". Most specific content, in our case written for individual customers was not as important! There are many customers and projects, but theoretically only one platform. Projects come and go. However, platform being responsible for most of the code that determines basic functions, puts you at their mercy.
The infrastructure and base code was a huge deal. The other teams were fat... it does cut either way though.
I think the issue is a lot of people read his stuff and then blindly think it all applies to them and microservice themselves into a corner without actually thinking through if it actually applies to their situation. Same goes for various blogs from FAANG companies about scaling. Hardly anyone has scaling issues that they have, yet technologists like the bright and shiny new thing so they end up adopting over complicated solutions to their simple problems.
The team types he talks about in this post I see working well in some companies and situations but he's not saying "thou shall have a platform team and it solves all your woes". The first paragraph states the primary team is a "stream aligned team" which I take to mean a product team that is responsible for app(s) from top to bottom - UX, UI, backend, scaling, support, etc.
What your employees and customers observe and perceive is the reality, not what Google, Martin Fowler or Bill Gates prescribe.
Classic "my experience trumps yours".
Be careful around software evangelists
I'd would not call it "virtuous cycle" more of vicious cycle.
Well intentioned I doubt. Unless it means McKinsey style well intentioned: hammering about re-orgs and reforms while generating ton of consulting revenue with it.
Side point here…
I absolutely love refactoring sometimes. Like taking a messy chunk of code with deeply nested conditionals a d simplifying it, which makes it more readable and extendable. You also have very clear requirements as well (whatever the original code did). There are few things in software development that bring me more joy than that.
But its often not necessary. And furthermore, refactoring is often not of that type. Sometimes people rewrite things because they don’t understand how they work (and writing is easier than reading). Or because they completely misjudge the value of the refactor.
In my experience, it's worked out terribly when a company treats a platform team as a catch-all for any back-end service regardless the business domain. On the other hand, it's seemed to work reasonably well when the team has a narrow (and very clear definition) of which services they own and why.
That said, I've never worked directly within a platform team as an engineer, so maybe it just appears that way as an outsider.
I'm not sure I completely understand "platform" in this context. I've worked on teams that tried to write a common platform, then delegate to more specialized teams for specific implementations.
I have often hated working under these conditions. These problems are often true for software suppliers whether internal and external. There is a disconnect, and weirdly platform is not motivated to provide good quality code with whatever analysis / testing is needed. It can be even worse if the supplier is internal, and it's known that the company doesn't want to use someone external (where's your leverage!)... good chance platform has more political pull than you, too!
Often times they just ship it and say "your problem". Meanwhile, they also insist that we do not modify their code, or else take full responsibility. There's more motivation to finger point, or push responsibility on to your customer (including other internal teams).
Mind you that in my industry this all pushes the limits of ethics, and maybe our obligations dictated by regulations. Of course, we do everything we can to meet our obligations and do the right thing. However, you're left with the decision to leave in poor quality code (or missing work products), or modify / test code you probably will struggle to understand. It will also be difficult to understand the implications, eg. for other modules.
It's a very awkward situation.
Almost everything he hawks causes misery for software developers, like his whole multi-year spin for Microservices, he's turned refactoring into a fetish (honestly there are people at my dayjob who have been "refactoring" the entire 3 years i've been here) and now hes blogged multiple times about platform teams - which - having been on one - don't work. I see him as a very damaging character.
Well intentioned, i'm sure, but I don't think he has good ideas.