Hacker News Reader

Comment by AJRF | Hacker News Reader

I've found over the years that Martin Fowler blogs about things the C-Suite is already doing at their companies, and they use this as validation for their choices. This in turn has a virtuous cycle of keeping him popular.

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.

View on HN

Microservices was at its core a good idea. I think Fowler was just overawed with how well it worked for him in his organizational context and was unaware of how critical that context was to making it work.

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.

I disagree, microservices at their core were not a good idea, they were missing the forest from the trees.

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.

And his context is what? Selling books and conferences? What has he actually shipped with his ideas?

To me, it's the Clean Code of web services.

Working for 3 years and only refactoring, that's a whole new level of comedy. If you blame Fowler for this madness, then I see how you think his work is damaging.

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.

Funny you should mention health influencers, as they're also prone to blanket suggestions without taking their audiences needs into account.

Sometimes they can work, like "stop doing tik-tok challenges."

Yeah, but in the real world some of these policies are a slippery slope to having people refactor for years.

On the other hand I don't know that having people dedicated to refactoring is necessarily ridiculous. At least "in theory, given unlimited resources".

> 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)

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).

> and now hes blogged multiple times about platform teams - which - having been on one - don't work.

I’d love to hear more about your experience with a platform team and why you say they don’t work.

- Platform sounds like "everything that doesn't fit into a vertical slice of business" - that is a _hell_ of a lot of work for any team.

- 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.

> 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.

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.

The platform team you describe sounds more like DevOps ("upgrades, CI + CD, ....").

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.

You stopped just before the bit that made your comment pointless, the very next words;

> 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

That is the root problem with Martin Fowler and his ilk, always ignoring management, politics and existing reality.

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.

Interestingly, I've seen the exact opposite. Platform is the team that they see, and they do a tremendous amount of the total work. I guess maybe that's the difference; the teams you worked on didn't write much useful code.

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.

All of those are downsides, yes, but platforms still need to be built for organizations that are at scale so the focus needs to be on how to improve the process of building them, not on how to avoid them.

Only small companies can silo everything into verticals.

I'm really curious about the usual inter-team patterns .. (or even in-team). Politics is a morbid fascination.. cause I hate it but I have to walk around it so.. the more I know.

My 2c's are that platform teams are a silo for expertise on how anything is run at a company and can become a bottleneck for other teams when getting things done. In an ideal scenario the product team can consume resources via an API, but in my experience resources are only assigned via a ticketing system and the associated communication barriers this creates leads to friction.

Having worked at smaller companies (~ 500 people) in different stages (series-A, unicorn and post IPO) I very much like the idea of a lean platform team that defines the interfaces that are used to control interaction between different modules, and with external services.

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.

I led a large (50 people+) platform org - Organizations struggle with modern backend systems and cloud, and find themselves in a cyclical loop of hiring, reorganization and reprioritization. I just wrote about it here a few days ago: https://klo.dev/evolution-of-cloud-infrastructure-and-platfo...

If you have upper management reading a blog and doing a re-org to implement, that is the problem causing misery: management copy/pasting org structures/ideas and thinking it will work, much like technologists cramming some new tech into solutions where it doesn't belong.

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.

This is a general issue across all fields - blindly following other companies or people is never a good idea because you don't know all the internal and external variables that the person/organization was working with. In fact in business schools they often teach you to scrutinize established patterns and norms and apply various frameworks in conjunction with statistical analysis to draw conclusions.

What your employees and customers observe and perceive is the reality, not what Google, Martin Fowler or Bill Gates prescribe.

Your code has had people dedicated to refactoring it for the last three years?

Have any openings?

I don't know if I'd go that far; perhaps platform code could be done well, but you make it seem like it can't work.

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.

Could you elaborate on the part about platform teams?

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.

Agree with most of it.

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.

As always

Be careful around software evangelists

> 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

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.

It can also be really bipolar, depending on philosophy. People tend to be extreme in either direction. You get zealots or the code is terrible.

"having been on one" -- So n of 1.

Classic "my experience trumps yours".

Microservices are essential at any large company. Can you imagine if Facebook was still a PHP monolith? They'd need 5,000,000 instances to run the app.

> microservices are essential at any large company

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.

At a large company? Yes.

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.

so then you're saying it's an execution issue, not a flawed concept.

a lot of people are giving Martin flack that the idea sucks when the reality is they're implementing it poorly or inappropriately.

I'm tired of this cop-out. If your thing is extremely easy to implement poorly, to the point where good implementations are a small minority, your thing sucks and is bad.

Additionally if you don't call-out the gotchas/pitfalls, then you're misleading the large chunk of engineers/managers who find a blog post and then blindly follow the best practice.

That's... not how it works....

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.

It depends on the granularity. I see projects where 3 developers create 13 micro services. Basically they buy all the complexity without having any benefits.

I generally hate the term “micro services”. They are just “services” and nothing new.

People went full monoliths to full microservices.

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.

It should be: start with a well architected monolith, and then slice things into microservices when you need to. Fowler and many Microservice evangelists even say to start with a monolith first, because you don't know the correct slices at the beginning.

EDIT: I suck at writing coherent messages on my phone.

Meanwhile, the experienced/good/non-charlatan engineers endorse choosing the right architecture for the job. Building a CMS? You probably want a pretty large monolith. Also building an analytics platform? That should probably be a separate service aligned to a different team.

narrator: they aren't. Code modularity is important.

Reply on news.ycombinator.com