13 ms·

What I'm Up to Now

192 points by BerislavLopac 5y ago

seibelj 5y ago
Martin Fowler has been a big advocate of micro services. I think micro services has been one of the biggest mistakes ever promulgated on software development and is responsible for developer misery, un-productivity, failed projects, and unintelligible rats nests that have set back a generation of engineers who have to now unlearn all of this nonsense. I can’t take him seriously and he is forever tainted in my mind. However it is a big boon for consultants like him and those that like to spend a lot of time gluing unmaintainable services together.
- orzig 5y ago
  Maybe it's the right pattern for some problems, and got overused when it was high on the hype curve? I don't have a horse in the race, but have seen many other technologies/patterns go that route
  - api 5y ago
    That statement describes basically every fad in development, every design pattern, and most if not all tools.
    - nitrogen 5y ago
      Indeed. It seems that it's useful to have descriptive patterns to understand what people are already doing. But then the hype cycle kicks in, and people treat them as prescriptive patterns. MVC, Agile, Design Patterns, monoliths, microservices, trunk-based, spaces vs tabs, Emacs vs Vim...
  - seibelj 5y ago
    I find it particularly stupid compared to most other hyped technologies, as the pattern pervades the entire engineering superstructure and has to be entirely burned down in order to fix the core rot. The foundation of any microservice-based system is inherently shoddy in a way other poorly designed systems aren’t.
    - nix23 5y ago
      The Problem With Microservices: https://www.youtube.com/watch?v=zzMLg3Ys5vI https://www.youtube.com/watch?v=zzMLg3Ys5vI
    - staticassertion 5y ago
      Your posts have no value. You've said nothing of substance, made no valid criticism. If you just want to vent go talk to a therapist, don't waste precious bytes.
      - nitrogen 5y ago
        If you just want to vent go talk to a therapist, don't waste precious bytes. Nobody holds comments they agree with to this high of a bar. You are being way too harsh, and this borders on personal attack. One of the ways modern society is breaking down is that nobody has a community they can vent to and relate to. Everything is somebody else's problem. If someone has something to say, let them say it. If they didn't say it clearly, maybe ask for more. Don't make it personal, and if it's irrelevant, just downvote and move on.
        staticassertion 5y ago
        All they're doing is repeatedly insulting this guy with absolutely no meaningful content across multiple posts. It's garbage, it's nothing but unsubstantiated attacks. I don't see how my post was a personal attack either, I said to vent elsewhere, in an appropriate venue.
      - seibelj 5y ago
        The value of my post is that a charlatan with very damaging views has somehow been promoted as great thinker when I find his entire engineering philosophy not only incorrect but totally moronic and damaging. I’m calling it out because it’s really stupid and we need more people to feel OK calling bullshit when some idiot carts out the “we need 50 services to power the authentication pipeline!” which I have seen multiple times during my career, as other enthusiastic engineers cheer them on. It’s a dead idea and it is pointless, at least at when operating at the scale of 99% of tech companies. I’m not going to keep pretending this is a good idea when it’s not.
- pbourke 5y ago
  Fowler also wrote about "cookie-cutter" scaling of monolithic applications. Seems to me that the fault lies with the people who cargo cult approaches rather than reflecting on them and adopting them if and when they make sense.
- javaunsafe2019 5y ago
  Maybe you and them just did not understand that it’s an pattern that, as all pattern, makes only sense for certain applications. Maybe you could also present some references that back up your claims? It’s always easy to judge on people that tried to solve problems of the past. Mistakes will always be made but this way we do learn and make progress. So what I try to say is maybe appreciate that he at least tried to solve problems. All this shitposts here at hn against ppl like him or uncle bob or so unreflected and immature… like really what the heck is going on with you people. Edit: grammar. Non nativ here…
  - conta_opin_99 5y ago
    If you build your whole life around didactic speaking gigs where you tell everyone how to do it despite apparently not writing any software yourself, you need to be prepared to be open to some criticism when it turns out your ideas are shit.
    - javaunsafe2019 5y ago
      True but then please try to back up your hard claims with some references. Fowler himself made the restrictions of the microservice pattern very clear in several posts… So don’t blame him for stupid architectural design decisions!
  - wtactual 5y ago
    Fowler and "Uncle Bob" are in different solar systems. Fowler may get things wrong, but he's not a total hack like Bob. "The Clean Coder" is one of the most disgusting things I've ever read. Flagged for accuracy.
    - CozyBearNotSoy 5y ago
      What specifically did you dislike about The Clean Coder? I don't consider myself sufficiently experienced to judge the advice given in that book.
- jnwatson 5y ago
  Microservices are the simplest solution to counteract Conway's law. If you have two organizations writing software, the least-overhead organizational approach that allows minimum communication overhead and release coordination is for both of those organizations to release a package and have well-defined APIs between those. There are certainly other approaches to achieve similar outcomes, but microservices are the lowest-tech mechanism.
  - Jare 5y ago
    > least-overhead > well-defined APIs That's where most shifts to microservices fail, right? Sometimes because they don't define their APIs well, sometimes because the breakdown into packages/services is broken (for example: defined by company structure instead of sane software architecture), sometimes because the evolution of each package's features and functionality is at odds with the stability of their API's semantics and guarantees (and documentation), sometimes because the development overhead of communicating between APIs is too high (debugging for example)...
  - majewsky 5y ago
    > Microservices are the simplest solution to counteract Conway's law. I don't think that "counteract" is a useful frame of mind. I interpret Conway's Law more as a lesson: Build your software to reflect your org chart, or else you're going to have a really bad time. If you have two loosely-coupled teams, their respective services better be loosely coupled as well. And vice versa for tightly-coupled teams: If you have some good cross-team communication going on, take advantage of it in your architecture.
- exceptione 5y ago
  Can you link to any resource? What I read from Fowler is that he has lots of reservations about it. To quote: Any architectural style has trade-offs: strengths and weaknesses that we must evaluate according to the context that it's used. This is certainly the case with microservices. While it's a useful architecture - many, indeed most, situations would do better with a monolith.[1] He even states that you never should start building your application as microservices, but instead as a monolith. So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.[2] __ 1. https://martinfowler.com/articles/microservice-trade-offs.html https://martinfowler.com/articles/microservice-trade-offs.ht... 2. https://martinfowler.com/bliki/MicroservicePremium.html https://martinfowler.com/bliki/MicroservicePremium.html
- eranation 5y ago
  I’m surprised by this comment given I use this post by him to convince people to start with a monolith and only break down to microservices when actually needed. Agree it can be a huge pain if you do it before you need it. https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html
dvaun 5y ago
Near the end of his post, he writes: > I’ve always been nagged by my conviction that I’m not working as diligently or effectively as I ought to be. Sadly I’m not getting any better at not letting that bug me. Maybe this has been discussed in depth elsewhere, but my question in response to this is: how does one/how do we end up feeling like this? And how can you work toward not feeling this way?
- peakaboo 5y ago
  You make different choices during the day and you do it against your own will at first. You won't feel like it, and your mind will tell you tomorrow, but since you expected that, you do it today.
- _spduchamp 5y ago
  Don't live by other people's expectations. Always live by your own, and always reassess your expectations. One day at a time. Do something, or don't, no biggie.
- ljm 5y ago
  I get there when I feel unsatisfied with the problems I'm solving. Maybe I ended up fighting fires for a day or two, say, and fighting fires doesn't bring me pleasure while my main body of work does. So, even though the fire fighting has immense value to those who benefit from the fires being put out, and I'm really good at doing what it takes to put them out quickly, I didn't start the fires myself and I didn't get my work done. I feel like a rescuer rather than an effective contributor and then I have to start trying to compensate for it. This is also touching on burnout. There's just a kind of programming work that is mentally draining and unfulfilling because the underlying problems or mistakes are entirely self-inflicted. Spending time fixing shit that didn't have to be broken.
- bumby 5y ago
  >how does one/how do we end up feeling like this? For me personally, this feeling arises when I become overly focused on an end-state. My mitigation is focusing more on the process and trusting that, over time, the end-goal becomes a natural outcome of an effective process.
diskzero 5y ago
Fowler states: I’ve long known that when you’re doing very creative work, such as writing or programming, the useful hours you can do in a day is rather less than the accepted industrial eight. I don't want to disagree with him as this is quite subjective, but when I am totally engrossed in solving a problem, I get into a flow and the time flies by. If the problem is both interesting and challenging, I can't wait to get back to working on it and I hate having to stop! I do agree if the work is joyless and the product is tedious, one hour spent on it can certainly seem like eight.
- tcldr 5y ago
  I can only speak for myself, but I find the quality of output decreases pretty steeply after around six hours of flow. Determination can keep me going but I’ve learnt that it’s probably more efficient to just rest and return to it after a good night's sleep.
  - diskzero 5y ago
    You have learned a good skill, which is knowing how and when to stop. That is something I have a very, very hard time with.
- HighlandSpring 5y ago
  In my experience if I'm in flow for 14 hours and time flies it's because I'm doing a high-value refactor at roughly the right time (not premature) If I'm doing a more open ended problem like modelling something from scratch (I have boxes and arrows on a piece of paper but the edge cases are still a mystery) then it's something I'll exhaust myself on much sooner
- webmaven 5y ago
  > [W]hen I am totally engrossed in solving a problem, I get into a flow and the time flies by. If the problem is both interesting and challenging, I can't wait to get back to working on it and I hate having to stop! I agree that it is possible to remain in a state of flow for "the standard industrial eight", but on occasions where I've remained in a state of flow for eight (or more) hours, the quality of the work suffers, and the following day is a total loss (as in "me no think good, think meat broken"), so it is better to keep to a more sustainable pace.
mack1001 5y ago
Probably not necessarily on topic - but I really want to give a shout out to Mr. Fowler. It’s really hard to find anyone in contemporary and practical software engineering who has been as impactful as he has been. A lot of modern concepts that improve software development has a seminal article authored or made visible by him.
recursivedoubts 5y ago
Martin, if you are reading this, here's something you could do: Revisit REST (and the Richardson Maturity Model[1]) and explain why REST has failed so spectacularly in the JSON API world. It's worth doing because REST-ful hypermedia systems are using an interesting and distinctive network model, and most younger web engineers don't know much about it and end up using the client-server approaches that have become so common for modern web applications. You are in a great (perhaps the best) position to respark interest in hypermedia and the REST-ful approach. I have some thoughts on the matter[2][3][4], and would be happy to discuss. -- [1] - https://www.martinfowler.com/articles/richardsonMaturityModel.html https://www.martinfowler.com/articles/richardsonMaturityMode... [2] - https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://intercoolerjs.org/2016/01/18/rescuing-rest.html [3] - https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... [4] - https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/
- vlunkr 5y ago
  > explain why REST has failed so spectacularly in the JSON API world Could you elaborate on this?
  - deleted 5y ago
    [deleted]
  - thehappypm 5y ago
    By failed, I think they mean “spectacularly wide usage, with some drawbacks”.
    - plorkyeran 5y ago
      REST as Fowler advocated for is used approximately nowhere. The widely used thing known as REST is very unlike it.
      - bradwood 5y ago
gighjifews 5y ago
Somewhat flippant, but also a serious question - do people like Martin Fowler and uncle bob actually do anything or do they just describe systems that do not (and probably will never) actually exist? Have they built real world software, or do they just describe some ideal state that has never actually occurred in reality - some kind of geek porn? I’d much rather listen to people who have actually done things than people who have theoretical done things (people who do both are best). I ask because I thought Rob Pike was one of those people until I found out what he does / has done.
- user3939382 5y ago
  https://en.wikipedia.org/wiki/Martin_Fowler_(software_engineer)#Biography https://en.wikipedia.org/wiki/Martin_Fowler_(software_engine...
  - m0zg 5y ago
    So I guess the answer is "no", then? :-)
- galkk 5y ago
  about half of "Patterns of Enterprise Applications" reads like introduction/documentation to Hibernate (java's object-relation mapper), also you can see traces of earlier ASP.Net there. I don't know what was first, but this certainly describes frameworks that actually exist.
- denvercoder904 5y ago
  Does he have a public github repo? I would love to see some of the code that he writes or projects that he has worked on.
- mdoms 5y ago
  Bob Martin has been promoting his iPad PDP-8 emulator which I guess is something. https://github.com/unclebob/PDP8EmulatorIpad https://github.com/unclebob/PDP8EmulatorIpad
  - 5y ago
itwy 5y ago
Fowler is the master of overcomplicating things.
- dang 5y ago
  No personal attacks on HN, please.
  - itwy 5y ago
    I don't see it that way. He chose to be the brand.
    - majewsky 5y ago
      Even so, you should provide some evidence to back up your claim. If you said "Fowler is the master of overcomplicating things, like in his work on A, or when he argued B", then people could engage with those instances or provide counterexamples. As it stands, your original comment is just flamebait.
    - dang 5y ago
      Look at this way: you may not owe marquee consultants better, but you owe this community better if you're posting to it. In other words, it's not only about the person you're attacking, it's about what it does to ourselves when we do it, and the others who are present. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
ChrisMarshallNY 5y ago
I like The Agile Manifesto. I feel that the jury is still out, on how effective it is, in practice; not because it's bad, but because I think it has problems in application, in the regular schlub world. Note that I like the Manifesto, but have been underwhelmed by what I've seen, in its expression. I feel that Mr. Fowler, and his compatriots came out with a great "vision statement," that may not be applied particularly well. Maybe work on "paving the bare spots"[0] on the Manifesto might be useful. I really want to see it work. I know that when I designed a fairly major infrastructure system, it took ten years, before it was really good enough for worldwide consumption (that might be a bit of an overstatement, but it took at least eight). The software, and the accompanying "vision," were ready by Version 2.0 (about 18 months in), but it took all that additional time to figure out how to get skeptical and stubborn people to accept it, win over friends, and make some embarrassing mistakes. One of the big issues with coming up with "A New Way™," is that it usually means that "the way we've always done it" is implied to be wrong, and that's a real hard sell. I know that it was the biggest issue that I faced, and dealing with that was tricky. In some cases, I needed to make adjustments, and walk back my rhetoric, to avoid causing people to get their hackles up. That kind of thing is very important, and often neglected. I've always wished the Manifesto folks had followed through with the shepherding process. If his experience is anything like mine, it will be a long, frustrating, but ultimately, incredibly rewarding endeavor. [0] https://littlegreenviper.com/miscellany/the-road-most-traveled-by/#paving https://littlegreenviper.com/miscellany/the-road-most-travel...
- dasil003 5y ago
  This resonates a lot, I like this idea of a "shepherding process" and digger deeper into what it takes to make big projects successful over time. That said, I think distilling down this hard-won experience tends to lead to cargo-culting. Just look at "Agile" itself and how it's been embraced and then twisted by consultants into the exact opposite of what was intended by The Agile Manifesto to begin with. This stuff sells because people want clarity of what to do on a daily basis, they don't want to confront the reality that is no guaranteed path to make large scale software successful. Certainly some process and structure are helpful as long as they are specific to the problem at hand, and focused on the needs of the people actually doing the solving and giving them whatever air cover and cross-pollination needed for them to get the reps on the actual software. Typically these types of projects happen in large orgs where there are incentives for middle management to avoid culpability for failure rather than to do what it takes to succeed (especially if it's a hard problem). In this kind of environment, process is often used as a cudgel for one group to protect itself by claiming "I did my job". So to your question: how effective is The Agile Manifesto in practice? I think of it sort of in the necessary-but-not-sufficient bucket. Basically if you have buy-in to give a team this flexibility and autonomy you have a crack at solving a hard problem. Now it depends on the team and the problem: is the problem ultimately solvable and does this team have the chops?
s1k3s 5y ago
Probably not necessarily on topic - but I really want to say that this guy has been the #1 source of pain in my developer career so far. There've been so many projects where I had to implement some solution some way because the "architect" said "that's how Fowler recommends it, so that's how we're doing it", even if the solution was so bad that everyone saw it coming back to bite us from miles away. I read his books and found nothing impressive. To me the guy is just a glorified salesman who I'd hire to sell BS to my agency's clients.
- tommica 5y ago
  Well, he is not your source of pain, it's your superiors that made the decisions - he did not tell them to do it
- ncann 5y ago
  I echo this sentiment. For some reason his writing is very popular among so-called "software architect", which is especially painful if they are in a position of power in the organization and start forcing it down everyone's throat.
- conradfr 5y ago
  Yes, I must say, him and Eric Evans. It's not their fault, but still ;) I remember it well, starting 2016 suddenly everyone wants to do DDD, CQRS etc. Let's shoehorn new paradigms in our framework of choice. Boilerplate, lots of boilerplate...
- The_Colonel 5y ago
  You suffer from bad architects. If there wasn't Fowler, they would just misinterpret somebody else. > that's how Fowler recommends it, so that's how we're doing it Fowler would be the first to point out that there are no hard & fast rules / recommendations and each case should be evaluated individually since there's just too many variables.
- thrower123 5y ago
  Everybody reads Fowler and does horrible things thereafter for a while. Hopefully, you come out of that phase and learn what is worth bothering with and what is not, without too many years and without too many scars and too many failed projects. Some never do though... The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most regrettable. I'm still dealing with bad decisions made in code bases from that period.
kybishop 5y ago
Lots of comments here opposed to Martin Fowler's advice. I'm curious if anyone who is anti-Fowler has software design books they _do_ recommend? (Asking because I'd love to read them)
- detaro 5y ago
  Since the problem usually isn't with the software design advice, but "people read software design books and then try to force whatever they read into their projects", I guess what would make a book "good" for that is "the author isn't popular enough to cause something to be trendy". IMHO Fowlers writing is just fine as "these are things people have done and you might consider" (and what I've read mostly seemed to be written that way, not overly pushy), but its so popular that if he writes about a new thing, too many people then jump onto it as the next big thing, if it matches their problems or not, and that gets painful to work with. Although for Fowler to write about something, I think it already has some trendiness going on and he's not usually on the forefront of new ideas?
- amw-zero 5y ago
  The people that don't like him don't enjoy any books. They just enjoy "getting stuff done." That's really what I find when talking to people about why they don't like concepts that he introduces. They have no alternative, they just don't like people who come across as dogmatic.
- blub 5y ago
  People like Martin Fowler or Robert Martin seem to be more famous for the books that they write about software instead of being famous for the software that they write. I don't think it should be possible for somebody to become an authority on software design without them showing their designs to the world. If they work exclusively on proprietary software, then they should provide some other kind of proof that the recommendations that they make are beneficial and demonstrate how helpful they are. E.g. anonymous metrics from their client pool, detailed analyses of various OSS projects, etc. When e.g. John Carmack talks about a technical topic there's a very long and very public record of the kind of experience that he has. It's reasonable to trust that they are correct, although one should still verify before betting their project/company/career on that piece of advice.
TedShiller 5y ago
Never heard if this guy
currywurst 5y ago
I have no idea which side of the bed HN woke up today, but the comments here disparaging Martin Fowler's body of work really trouble me. I really enjoy Martin's (and more recently his collaborators') blog posts on various trends. More often than not, they distill key concerns and references into a quickly readable summary. His books on software patterns collect a breadth of problem/solution pairs that have now been baked into so many frameworks that you probably don't even realise you are benefiting from them. If you are totally new to Martin Fowler's books and writing, I would urge you to not brush them aside because of some snide comments on HN. There's a wealth of material that can surely enrich your thinking.

192 points by BerislavLopac 5y ago

Martin Fowler has been a big advocate of micro services. I think micro services has been one of the biggest mistakes ever promulgated on software development and is responsible for developer misery, un-productivity, failed projects, and unintelligible rats nests that have set back a generation of engineers who have to now unlearn all of this nonsense. I can’t take him seriously and he is forever tainted in my mind. However it is a big boon for consultants like him and those that like to spend a lot of time gluing unmaintainable services together.

orzig 5y ago
Maybe it's the right pattern for some problems, and got overused when it was high on the hype curve? I don't have a horse in the race, but have seen many other technologies/patterns go that route
- api 5y ago
  That statement describes basically every fad in development, every design pattern, and most if not all tools.
  - nitrogen 5y ago
    Indeed. It seems that it's useful to have descriptive patterns to understand what people are already doing. But then the hype cycle kicks in, and people treat them as prescriptive patterns. MVC, Agile, Design Patterns, monoliths, microservices, trunk-based, spaces vs tabs, Emacs vs Vim...
- seibelj 5y ago
  I find it particularly stupid compared to most other hyped technologies, as the pattern pervades the entire engineering superstructure and has to be entirely burned down in order to fix the core rot. The foundation of any microservice-based system is inherently shoddy in a way other poorly designed systems aren’t.
  - nix23 5y ago
    The Problem With Microservices: https://www.youtube.com/watch?v=zzMLg3Ys5vI https://www.youtube.com/watch?v=zzMLg3Ys5vI
  - staticassertion 5y ago
    Your posts have no value. You've said nothing of substance, made no valid criticism. If you just want to vent go talk to a therapist, don't waste precious bytes.
    - nitrogen 5y ago
      If you just want to vent go talk to a therapist, don't waste precious bytes. Nobody holds comments they agree with to this high of a bar. You are being way too harsh, and this borders on personal attack. One of the ways modern society is breaking down is that nobody has a community they can vent to and relate to. Everything is somebody else's problem. If someone has something to say, let them say it. If they didn't say it clearly, maybe ask for more. Don't make it personal, and if it's irrelevant, just downvote and move on.
      - staticassertion 5y ago
        All they're doing is repeatedly insulting this guy with absolutely no meaningful content across multiple posts. It's garbage, it's nothing but unsubstantiated attacks. I don't see how my post was a personal attack either, I said to vent elsewhere, in an appropriate venue.
    - seibelj 5y ago
      The value of my post is that a charlatan with very damaging views has somehow been promoted as great thinker when I find his entire engineering philosophy not only incorrect but totally moronic and damaging. I’m calling it out because it’s really stupid and we need more people to feel OK calling bullshit when some idiot carts out the “we need 50 services to power the authentication pipeline!” which I have seen multiple times during my career, as other enthusiastic engineers cheer them on. It’s a dead idea and it is pointless, at least at when operating at the scale of 99% of tech companies. I’m not going to keep pretending this is a good idea when it’s not.
pbourke 5y ago
Fowler also wrote about "cookie-cutter" scaling of monolithic applications. Seems to me that the fault lies with the people who cargo cult approaches rather than reflecting on them and adopting them if and when they make sense.
javaunsafe2019 5y ago
Maybe you and them just did not understand that it’s an pattern that, as all pattern, makes only sense for certain applications. Maybe you could also present some references that back up your claims? It’s always easy to judge on people that tried to solve problems of the past. Mistakes will always be made but this way we do learn and make progress. So what I try to say is maybe appreciate that he at least tried to solve problems. All this shitposts here at hn against ppl like him or uncle bob or so unreflected and immature… like really what the heck is going on with you people. Edit: grammar. Non nativ here…
- conta_opin_99 5y ago
  If you build your whole life around didactic speaking gigs where you tell everyone how to do it despite apparently not writing any software yourself, you need to be prepared to be open to some criticism when it turns out your ideas are shit.
  - javaunsafe2019 5y ago
    True but then please try to back up your hard claims with some references. Fowler himself made the restrictions of the microservice pattern very clear in several posts… So don’t blame him for stupid architectural design decisions!
- wtactual 5y ago
  Fowler and "Uncle Bob" are in different solar systems. Fowler may get things wrong, but he's not a total hack like Bob. "The Clean Coder" is one of the most disgusting things I've ever read. Flagged for accuracy.
  - CozyBearNotSoy 5y ago
    What specifically did you dislike about The Clean Coder? I don't consider myself sufficiently experienced to judge the advice given in that book.
jnwatson 5y ago
Microservices are the simplest solution to counteract Conway's law. If you have two organizations writing software, the least-overhead organizational approach that allows minimum communication overhead and release coordination is for both of those organizations to release a package and have well-defined APIs between those. There are certainly other approaches to achieve similar outcomes, but microservices are the lowest-tech mechanism.
- Jare 5y ago
  > least-overhead > well-defined APIs That's where most shifts to microservices fail, right? Sometimes because they don't define their APIs well, sometimes because the breakdown into packages/services is broken (for example: defined by company structure instead of sane software architecture), sometimes because the evolution of each package's features and functionality is at odds with the stability of their API's semantics and guarantees (and documentation), sometimes because the development overhead of communicating between APIs is too high (debugging for example)...
- majewsky 5y ago
  > Microservices are the simplest solution to counteract Conway's law. I don't think that "counteract" is a useful frame of mind. I interpret Conway's Law more as a lesson: Build your software to reflect your org chart, or else you're going to have a really bad time. If you have two loosely-coupled teams, their respective services better be loosely coupled as well. And vice versa for tightly-coupled teams: If you have some good cross-team communication going on, take advantage of it in your architecture.
exceptione 5y ago
Can you link to any resource? What I read from Fowler is that he has lots of reservations about it. To quote: Any architectural style has trade-offs: strengths and weaknesses that we must evaluate according to the context that it's used. This is certainly the case with microservices. While it's a useful architecture - many, indeed most, situations would do better with a monolith.[1] He even states that you never should start building your application as microservices, but instead as a monolith. So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.[2] __ 1. https://martinfowler.com/articles/microservice-trade-offs.html https://martinfowler.com/articles/microservice-trade-offs.ht... 2. https://martinfowler.com/bliki/MicroservicePremium.html https://martinfowler.com/bliki/MicroservicePremium.html
eranation 5y ago
I’m surprised by this comment given I use this post by him to convince people to start with a monolith and only break down to microservices when actually needed. Agree it can be a huge pain if you do it before you need it. https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html

dvaun 5y ago

Near the end of his post, he writes: > I’ve always been nagged by my conviction that I’m not working as diligently or effectively as I ought to be. Sadly I’m not getting any better at not letting that bug me. Maybe this has been discussed in depth elsewhere, but my question in response to this is: how does one/how do we end up feeling like this? And how can you work toward not feeling this way?

peakaboo 5y ago
You make different choices during the day and you do it against your own will at first. You won't feel like it, and your mind will tell you tomorrow, but since you expected that, you do it today.
_spduchamp 5y ago
Don't live by other people's expectations. Always live by your own, and always reassess your expectations. One day at a time. Do something, or don't, no biggie.
ljm 5y ago
I get there when I feel unsatisfied with the problems I'm solving. Maybe I ended up fighting fires for a day or two, say, and fighting fires doesn't bring me pleasure while my main body of work does. So, even though the fire fighting has immense value to those who benefit from the fires being put out, and I'm really good at doing what it takes to put them out quickly, I didn't start the fires myself and I didn't get my work done. I feel like a rescuer rather than an effective contributor and then I have to start trying to compensate for it. This is also touching on burnout. There's just a kind of programming work that is mentally draining and unfulfilling because the underlying problems or mistakes are entirely self-inflicted. Spending time fixing shit that didn't have to be broken.
bumby 5y ago
>how does one/how do we end up feeling like this? For me personally, this feeling arises when I become overly focused on an end-state. My mitigation is focusing more on the process and trusting that, over time, the end-goal becomes a natural outcome of an effective process.

diskzero 5y ago

Fowler states: I’ve long known that when you’re doing very creative work, such as writing or programming, the useful hours you can do in a day is rather less than the accepted industrial eight. I don't want to disagree with him as this is quite subjective, but when I am totally engrossed in solving a problem, I get into a flow and the time flies by. If the problem is both interesting and challenging, I can't wait to get back to working on it and I hate having to stop! I do agree if the work is joyless and the product is tedious, one hour spent on it can certainly seem like eight.

tcldr 5y ago
I can only speak for myself, but I find the quality of output decreases pretty steeply after around six hours of flow. Determination can keep me going but I’ve learnt that it’s probably more efficient to just rest and return to it after a good night's sleep.
- diskzero 5y ago
  You have learned a good skill, which is knowing how and when to stop. That is something I have a very, very hard time with.
HighlandSpring 5y ago
In my experience if I'm in flow for 14 hours and time flies it's because I'm doing a high-value refactor at roughly the right time (not premature) If I'm doing a more open ended problem like modelling something from scratch (I have boxes and arrows on a piece of paper but the edge cases are still a mystery) then it's something I'll exhaust myself on much sooner
webmaven 5y ago
> [W]hen I am totally engrossed in solving a problem, I get into a flow and the time flies by. If the problem is both interesting and challenging, I can't wait to get back to working on it and I hate having to stop! I agree that it is possible to remain in a state of flow for "the standard industrial eight", but on occasions where I've remained in a state of flow for eight (or more) hours, the quality of the work suffers, and the following day is a total loss (as in "me no think good, think meat broken"), so it is better to keep to a more sustainable pace.

mack1001 5y ago

Probably not necessarily on topic - but I really want to give a shout out to Mr. Fowler. It’s really hard to find anyone in contemporary and practical software engineering who has been as impactful as he has been. A lot of modern concepts that improve software development has a seminal article authored or made visible by him.

recursivedoubts 5y ago

Martin, if you are reading this, here's something you could do: Revisit REST (and the Richardson Maturity Model[1]) and explain why REST has failed so spectacularly in the JSON API world. It's worth doing because REST-ful hypermedia systems are using an interesting and distinctive network model, and most younger web engineers don't know much about it and end up using the client-server approaches that have become so common for modern web applications. You are in a great (perhaps the best) position to respark interest in hypermedia and the REST-ful approach. I have some thoughts on the matter[2][3][4], and would be happy to discuss. -- [1] - https://www.martinfowler.com/articles/richardsonMaturityModel.html https://www.martinfowler.com/articles/richardsonMaturityMode... [2] - https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://intercoolerjs.org/2016/01/18/rescuing-rest.html [3] - https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... [4] - https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/

vlunkr 5y ago
> explain why REST has failed so spectacularly in the JSON API world Could you elaborate on this?
- deleted 5y ago
  [deleted]
- thehappypm 5y ago
  By failed, I think they mean “spectacularly wide usage, with some drawbacks”.
  - plorkyeran 5y ago
    REST as Fowler advocated for is used approximately nowhere. The widely used thing known as REST is very unlike it.
    - bradwood 5y ago

gighjifews 5y ago

Somewhat flippant, but also a serious question - do people like Martin Fowler and uncle bob actually do anything or do they just describe systems that do not (and probably will never) actually exist? Have they built real world software, or do they just describe some ideal state that has never actually occurred in reality - some kind of geek porn? I’d much rather listen to people who have actually done things than people who have theoretical done things (people who do both are best). I ask because I thought Rob Pike was one of those people until I found out what he does / has done.

user3939382 5y ago
https://en.wikipedia.org/wiki/Martin_Fowler_(software_engineer)#Biography https://en.wikipedia.org/wiki/Martin_Fowler_(software_engine...
- m0zg 5y ago
  So I guess the answer is "no", then? :-)
galkk 5y ago
about half of "Patterns of Enterprise Applications" reads like introduction/documentation to Hibernate (java's object-relation mapper), also you can see traces of earlier ASP.Net there. I don't know what was first, but this certainly describes frameworks that actually exist.
denvercoder904 5y ago
Does he have a public github repo? I would love to see some of the code that he writes or projects that he has worked on.
mdoms 5y ago
Bob Martin has been promoting his iPad PDP-8 emulator which I guess is something. https://github.com/unclebob/PDP8EmulatorIpad https://github.com/unclebob/PDP8EmulatorIpad
- 5y ago

itwy 5y ago

Fowler is the master of overcomplicating things.

dang 5y ago
No personal attacks on HN, please.
- itwy 5y ago
  I don't see it that way. He chose to be the brand.
  - majewsky 5y ago
    Even so, you should provide some evidence to back up your claim. If you said "Fowler is the master of overcomplicating things, like in his work on A, or when he argued B", then people could engage with those instances or provide counterexamples. As it stands, your original comment is just flamebait.
  - dang 5y ago
    Look at this way: you may not owe marquee consultants better, but you owe this community better if you're posting to it. In other words, it's not only about the person you're attacking, it's about what it does to ourselves when we do it, and the others who are present. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

ChrisMarshallNY 5y ago

I like The Agile Manifesto. I feel that the jury is still out, on how effective it is, in practice; not because it's bad, but because I think it has problems in application, in the regular schlub world. Note that I like the Manifesto, but have been underwhelmed by what I've seen, in its expression. I feel that Mr. Fowler, and his compatriots came out with a great "vision statement," that may not be applied particularly well. Maybe work on "paving the bare spots"[0] on the Manifesto might be useful. I really want to see it work. I know that when I designed a fairly major infrastructure system, it took ten years, before it was really good enough for worldwide consumption (that might be a bit of an overstatement, but it took at least eight). The software, and the accompanying "vision," were ready by Version 2.0 (about 18 months in), but it took all that additional time to figure out how to get skeptical and stubborn people to accept it, win over friends, and make some embarrassing mistakes. One of the big issues with coming up with "A New Way™," is that it usually means that "the way we've always done it" is implied to be wrong, and that's a real hard sell. I know that it was the biggest issue that I faced, and dealing with that was tricky. In some cases, I needed to make adjustments, and walk back my rhetoric, to avoid causing people to get their hackles up. That kind of thing is very important, and often neglected. I've always wished the Manifesto folks had followed through with the shepherding process. If his experience is anything like mine, it will be a long, frustrating, but ultimately, incredibly rewarding endeavor. [0] https://littlegreenviper.com/miscellany/the-road-most-traveled-by/#paving https://littlegreenviper.com/miscellany/the-road-most-travel...

dasil003 5y ago
This resonates a lot, I like this idea of a "shepherding process" and digger deeper into what it takes to make big projects successful over time. That said, I think distilling down this hard-won experience tends to lead to cargo-culting. Just look at "Agile" itself and how it's been embraced and then twisted by consultants into the exact opposite of what was intended by The Agile Manifesto to begin with. This stuff sells because people want clarity of what to do on a daily basis, they don't want to confront the reality that is no guaranteed path to make large scale software successful. Certainly some process and structure are helpful as long as they are specific to the problem at hand, and focused on the needs of the people actually doing the solving and giving them whatever air cover and cross-pollination needed for them to get the reps on the actual software. Typically these types of projects happen in large orgs where there are incentives for middle management to avoid culpability for failure rather than to do what it takes to succeed (especially if it's a hard problem). In this kind of environment, process is often used as a cudgel for one group to protect itself by claiming "I did my job". So to your question: how effective is The Agile Manifesto in practice? I think of it sort of in the necessary-but-not-sufficient bucket. Basically if you have buy-in to give a team this flexibility and autonomy you have a crack at solving a hard problem. Now it depends on the team and the problem: is the problem ultimately solvable and does this team have the chops?

s1k3s 5y ago

Probably not necessarily on topic - but I really want to say that this guy has been the #1 source of pain in my developer career so far. There've been so many projects where I had to implement some solution some way because the "architect" said "that's how Fowler recommends it, so that's how we're doing it", even if the solution was so bad that everyone saw it coming back to bite us from miles away. I read his books and found nothing impressive. To me the guy is just a glorified salesman who I'd hire to sell BS to my agency's clients.

tommica 5y ago
Well, he is not your source of pain, it's your superiors that made the decisions - he did not tell them to do it
ncann 5y ago
I echo this sentiment. For some reason his writing is very popular among so-called "software architect", which is especially painful if they are in a position of power in the organization and start forcing it down everyone's throat.
conradfr 5y ago
Yes, I must say, him and Eric Evans. It's not their fault, but still ;) I remember it well, starting 2016 suddenly everyone wants to do DDD, CQRS etc. Let's shoehorn new paradigms in our framework of choice. Boilerplate, lots of boilerplate...
The_Colonel 5y ago
You suffer from bad architects. If there wasn't Fowler, they would just misinterpret somebody else. > that's how Fowler recommends it, so that's how we're doing it Fowler would be the first to point out that there are no hard & fast rules / recommendations and each case should be evaluated individually since there's just too many variables.
thrower123 5y ago
Everybody reads Fowler and does horrible things thereafter for a while. Hopefully, you come out of that phase and learn what is worth bothering with and what is not, without too many years and without too many scars and too many failed projects. Some never do though... The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most regrettable. I'm still dealing with bad decisions made in code bases from that period.

kybishop 5y ago

Lots of comments here opposed to Martin Fowler's advice. I'm curious if anyone who is anti-Fowler has software design books they _do_ recommend? (Asking because I'd love to read them)

detaro 5y ago
Since the problem usually isn't with the software design advice, but "people read software design books and then try to force whatever they read into their projects", I guess what would make a book "good" for that is "the author isn't popular enough to cause something to be trendy". IMHO Fowlers writing is just fine as "these are things people have done and you might consider" (and what I've read mostly seemed to be written that way, not overly pushy), but its so popular that if he writes about a new thing, too many people then jump onto it as the next big thing, if it matches their problems or not, and that gets painful to work with. Although for Fowler to write about something, I think it already has some trendiness going on and he's not usually on the forefront of new ideas?
amw-zero 5y ago
The people that don't like him don't enjoy any books. They just enjoy "getting stuff done." That's really what I find when talking to people about why they don't like concepts that he introduces. They have no alternative, they just don't like people who come across as dogmatic.
blub 5y ago
People like Martin Fowler or Robert Martin seem to be more famous for the books that they write about software instead of being famous for the software that they write. I don't think it should be possible for somebody to become an authority on software design without them showing their designs to the world. If they work exclusively on proprietary software, then they should provide some other kind of proof that the recommendations that they make are beneficial and demonstrate how helpful they are. E.g. anonymous metrics from their client pool, detailed analyses of various OSS projects, etc. When e.g. John Carmack talks about a technical topic there's a very long and very public record of the kind of experience that he has. It's reasonable to trust that they are correct, although one should still verify before betting their project/company/career on that piece of advice.

TedShiller 5y ago

Never heard if this guy

currywurst 5y ago

I have no idea which side of the bed HN woke up today, but the comments here disparaging Martin Fowler's body of work really trouble me. I really enjoy Martin's (and more recently his collaborators') blog posts on various trends. More often than not, they distill key concerns and references into a quickly readable summary. His books on software patterns collect a breadth of problem/solution pairs that have now been baked into so many frameworks that you probably don't even realise you are benefiting from them. If you are totally new to Martin Fowler's books and writing, I would urge you to not brush them aside because of some snide comments on HN. There's a wealth of material that can surely enrich your thinking.