6 ms·

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 choic

• disgruntledphd2 3y ago
  > 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).
• Lutger 3y ago
  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.
  • c-hendricks 3y ago
    Funny you should mention health influencers, as they're also prone to blanket suggestions without taking their audiences needs into account.
    • ourmandave 3y ago
      Sometimes they can work, like "stop doing tik-tok challenges."
  • P_I_Staker 3y ago
    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".
• jalapenos 3y ago
  Your code has had people dedicated to refactoring it for the last three years? Have any openings?
• pydry 3y ago
  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.
  • ecshafer 3y ago
    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.
  • thezilch 3y ago
    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.
• 0xy 3y ago
  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.
  • DerArzt 3y ago
    > 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.
  • LeBit 3y ago
    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.
    • lightbendover 3y ago
      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.
    • thewix 3y ago
      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.
  • x86x87 3y ago
    narrator: they aren't. Code modularity is important.
• rvanmil 3y ago
  > 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.
  • throwaway85858 3y ago
    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.
    • jitix 3y ago
      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.
  • AJRF 3y ago
    - 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.
• mattbrewsbytes 3y ago
  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.
  • jitix 3y ago
    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.
• flimzy 3y ago
  "having been on one" -- So n of 1. Classic "my experience trumps yours".
• hardware2win 3y ago
  As always Be careful around software evangelists
• geodel 3y ago
  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.
• nonethewiser 3y ago
  > 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.
  • P_I_Staker 3y ago
    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.
• doncarlockeone 3y ago
  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.
• P_I_Staker 3y ago
  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.