31 ms·

Software Architecture Guide

803 points by rspivak 7y ago

blub 7y ago
Whenever I see yet another article by Martin Fowler, Kent Beck, Robert Martin & co I ask myself - where is the evidence for what they are preaching? What are the graphs based on? What is the evidence behind the proposed rules? These authors are clearly accomplished blog and book writers, but anyone whose software-related accomplishments are not open source or at least well known should have their statements scrutinized more closely. I don't see any studies cited, case studies presented or concrete examples. All I see is yet another reasonably sounding yet unsupported piece of folklore.
- millerm 7y ago
  I have had this thought for many years. Where is all the perfectly designed, bug free, maintenance-bliss, fully documented, fully tested, future-proofed code located so we can all marvel at its glory?
  - mirceal 7y ago
    > All code is bad. Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world. from: https://www.stilldrinking.org/programming-sucks https://www.stilldrinking.org/programming-sucks
  - michael_j_ward 7y ago
    I haven't gone through this yet- but my understanding is that there are some examples of this here "The Architecture of Open Source Applications" [1]. [1] http://aosabook.org/en/index.html http://aosabook.org/en/index.html
  - mobjack 7y ago
    You are comparing the perfect against the good while Fowler is likely comparing the good against the bad. Taking an extra week or two to clean up bad design decisions early in a project can pay dividends in the future. Spending months extra trying to do the perfect architecture is harder to justify.
- randomcarbloke 7y ago
  Thank you. If I want to design excellent architecture I will crack open SICP and transpose it to the fabric of modern computing. I also take issue with much of what Fowler et al say, but that's another conversation.
  - notus 7y ago
    SICP isn't going to teach you excellent architecture for large systems, it's going to teach you excellent architecture for small programs.
    - crimsonalucard 7y ago
      The design of small programs is isomorphic to the design of large programs at all levels. You're just referring to real world caveats and details, but the overall concepts taught in SICP apply to all layers of programming from assembly to the architectural level. Small programs: Q = A -> B W = B -> C R = C -> D T = D -> E Large Programs L = W . Q K = T . R Architecture M = L . K The above description works at every layer. SICP deals with abstraction and architecture at all layers of programming. It does not talk about real world idiosyncrasies of the system. For example it won't talk about whether the assembly instructions of the small program being executed is efficient and it won't talk about network latency.
      - dwaltrip 7y ago
        > The design of small programs is isomorphic to the design of large programs at all levels Good software design is not scale invariant. Significant scale deltas change things in fundamental ways. Designs that work and are maintainable, from a human perspective, at one scale often will fail at a larger scale. Some designs scale better than others, this is true. But no design scales infinitely, and the vast majority of designs would start performing poorly at scales that are still relevant to human concerns This shouldn't be surprising. Most things (nearly everything?) that we care about are not scale invariant.
        7y ago
- chrisseaton 7y ago
  For some of these speakers, I’ve literally never seen any evidence that they’ve written a single line of code. Why should we listen to Fowler? What large successful projects has he created using his ideas are there that I can look at? Where’s the data behind his slides? It’s all just talk talk talk. I’d listen to someone like Chris Lattner talk about how to design and write software because I can see whatever approach he uses must work well. I should listen to these full-time speakers because... I don’t really know and perhaps we should start challenging their talks by asking for the data behind them.
  - scarface74 7y ago
    Chris Lattner knows how to write system software and compilers which are completely separate beasts from the typical bespoke enterprise or software as a service apps that most developers write every day.
    - deleted 7y ago
      [deleted]
    - vfc1 7y ago
      Exactly, many times these famous authors advocate for practices that make sense for building compilers and frameworks or libraries, but that make little sense for building applications. Building applications is very different, because an application is the very end of the software tree dependency. Some practices make sense for both types of software, but many others don't and some of these authors don't seem to be able to make the difference.
      - scarface74 7y ago
        And sometimes it makes sense to take shortcuts that don’t make sense from a long term maintenance standpoint just to survive long enough to get product market fit. Get funding and survive. Twitter is a perfect example of this. Everyone agrees that Twitter made some bad architectural decisions that caused the frequent appearance of the “fail whale”. But eventually, they got enough funding via combination of the VC funding and later the public market to rearchitect their system.
- mirceal 7y ago
  all these people have some experience in the field and they did put some things out that gave names/spread practices in our industry. is that enough to take everything they spew as the truth? far from it. you should probably take a look and filter it through your experience.
- streetcat1 7y ago
  So first, you should read their books for concrete code. Martin books, for example "refactoring" or "Enterprise architecture" actually have good code examples. The same apply for kent beck early work on smalltalk (you can look at Junit) or his early work on the HotDraw editor (which was the source of many of the pattern in the Design Pattern book). Kent was one of the first adopter of smalltalk at the early 80 is techtronix, together with ward cunnighum (the inventor of wiki) and rebbeca swift brooks. Robert Martin work is mainly driven by his consulting practice and tend to change based on the on going trend. At the 2000's he was working with Grady Booch, preaching UML and design before coding. Later he dropped that in favour of agile and TDD. You do not see case studies since the industry simply does not really care. It is very trend prone. Most of the adopted advances were actually "hacks". For example C++ was invented out of necessity to create "C with objects" by a single person in AT&T labs. Unix was hacked in 3 weeks. Java was invented to program toasters, etc. Any attempt to develop tools and technique based on real research saw not adaptation - for example Ada at the 80s, UML at the 90's and early 2000, functional programming, TLA+ , etc.
  - geofft 7y ago
    The question was about "research" in the meaning of quantitative scientific evidence that these proposed techniques make software delivery better in real-world conditions, not "research" in the sense of new ideas from academics. As a professional, I don't want UML because I've seen no evidence it actually helps. Show me relevant studies that it does and I will absolutely change my mind. (And there are plenty of things that industry does respect that came from academic research in the sense of new ideas. Rust, stereotypically the language of the trend-prone, draws on everything from Ada to functional programming. But unlike those it actually and demonstrably meets the needs of general-purpose programming in industry.)
    - streetcat1 7y ago
      Sure. So UML is based on two main research areas - UML class diagram is based on rational algebra theory. A correct UML class diagram should follow the same normalization roles as defined by Codd seminal paper - "A Relational Model of Data for Large Shared Data Banks". You can ask, how does Prof Codd knows that this is is the correct way to describe and implement data. Well this follow directly from set theory. Again, how do we know that set theory works - well here we are the level of axioms of the set algebra. BTW, this Codd work was also "hacked" again by system R research which invented SQL. The other part of UML is based on finite state machine, which originated by Turning, and later refined by the work of David Harel on state charts. Again, those are theoretical CS tools. However, the work of Harel on state charts, was originated from the work on the Israel first aircarft (to be cancelled later), where he needed to define the the missile system. If you are interested on how those tool originated and later combined see the work of David Hay - "UML-Data-Modeling-Reconciliation" Those tools are useful in scale. For example, system with 3000 different use cases. Or for example you have 200 - 500 classes, each is a state machine. Again, since there is no software professional standard (not software engineering bar exam), you can or cannot use anything.
- hliyan 7y ago
  I agree. These theories should either be based on empirical evidence, simulations or built up from first principles in a rigorous manner. Otherwise they are about as concrete as philosophical treatises. Which is to say, not very concrete at all.
- jmartinpetersen 7y ago
  Robert Martin seems to cherry pick stats and trends and whatever that fits his world view. In Clean Architecture he cites a study with N=1 as proof TDD works. I have no hope for him.
  - billfruit 7y ago
    I generally dislike building arguments on top of statistics, rather than on theory which to my eye almost always looks more convincing. With statistics it is as if the burden is passed on to the reader to check the veracity and validity of the said numbers, where as if it is an argument constructed out of theory, the whole of it is present there for the reader to judge intrinsically on its own merits.
    - gunnihinn 7y ago
      That restricts you to mathematics, logic or philosophy. Engineering, or the rest of the world, operates _at best_ on statistics.
      - billfruit 7y ago
        Programming in general and Software correctness does not depend upon statistical arguments, so perhaps such a view could be taken for software engineering too. Also even considering aesthetics and elegance, I find use of statistics to power a reasoning, ungainly, compared with other means of arguing the same thing.
        crimsonalucard 7y ago
        You're right. Why are you voted down. Programming doesn't need to be based on statistics it's largely a deterministic system amenable to proof and logic. This application of "engineering" onto programming is largely the result of people not truly understanding the system they are dealing with. The system isn't some sub-sonic jet that will be subject to unknown turbulence, it's just axioms and rules.
    - 7y ago
- hacker_9 7y ago
  Agree. They talk the talk but don't walk the walk.
- deleted 7y ago
  [deleted]
- notus 7y ago
  They are speaking primarily from experience and I think they are pretty transparent about that. We're not in a field where many studies even exist on these types of processes. It is up to you as a developer to try them out and assess their merit.
- pjmorris 7y ago
  To take the other side of this coin, where is the evidence that evidence makes a difference? At least, where is the evidence that evidence is what convinces a software developer or manager to change something about their process? There are entire conferences [0,1] where hundreds of researchers present peer-reviewed studies, case studies, and concrete examples, evidence for various software engineering claims. Thousands of papers have been published at these conferences over time. Usually when those papers are linked here, they don't get much attention, e.g. [2], [3], [4]. As a rule, industry doesn't pay attention to them, except to hire the grad students out of academia. At these conferences, they spend a lot of time discussing how to get more industry participation. But the things they try haven't really worked so far. To go to all the trouble of generating peer-reviewed science only to have it ignored may not be the best trade available for how Fowler, Beck, et al spend their time. There are doubts about whether it's the best way for academics to spend their time. [0] http://www.icse-conferences.org/ http://www.icse-conferences.org/ [1] https://www.esec-fse.org/ https://www.esec-fse.org/ [2] https://news.ycombinator.com/item?id=20064211 https://news.ycombinator.com/item?id=20064211 [3] https://news.ycombinator.com/item?id=20575415 https://news.ycombinator.com/item?id=20575415 [4] https://news.ycombinator.com/item?id=19714085 https://news.ycombinator.com/item?id=19714085
- fogetti 7y ago
  I don't really understand your comment. Shows your ignorance to be honest: have you ever heard of active records? Or optimistic locking? Because these are VERY tangible software constructs and Martin Fowler for example wrote a whole book about them.
  - nafey 7y ago
    The GP was about software architecture styles proposed/endorsed by Fowler et al and not their general contribution to software. Keeping this in mind its fair to ask for data/studies backing their claims.
- manojlds 7y ago
  I used to work at ThoughtWorks and Martin Fowler's inputs are based on his interactions with many many ThoughtWorks' project teams. When he visited my team for one of those learnings discussions, I was amazed with the way he was able to absorb and present the same things we were learning in a much different and easier to understand manner.
- tootie 7y ago
  It's good point, but most of what I read on his blog feels like a distillation of best practices that I've seen mature in the industry. It all rings true and matches my experience of what works best. But can I prove it? No, not really.
- Chris_Newton 7y ago
  There’s nothing wrong with just suggesting reasonable ideas that might be useful. If everything needs to have a solid evidence base or rigorous supporting arguments before we talk about it, it becomes too easy to shut discussion down prematurely without ever discovering whether an idea does have value for someone, particularly in an industry like ours where much of what we do is hard to measure objectively. It’s helpful to be clear about whether an idea being presented is just someone’s personal thoughts or anecdotal experience or whether it does have a stronger foundation. If something is presented as a firm recommendation of good practice then it’s fair to expect the latter. But it’s also dangerous if we reflexively disregard any idea that doesn’t already have robust evidence behind it.
- afpx 7y ago
  The evidence is out there. If you look at successful libraries and applications, they almost always gave well-defined design and architecture guidelines. In fact, I can’t think of a good software library out there that doesn’t have a solid design and architecture. On the other hand, I often see big piles of mud that have to be re-written over (and over), because people believe architecture takes too long or they believe it’s unnecessarily complex.
- crimsonalucard 7y ago
  I agree with you. There's another angle to look at it though other then "evidence based" or scientific. In the field of engineering a large portion of it has to do testing to verify systems that are unpredictable or not modelled by theory. For example: building a plane involves testing it a wind tunnel. The thing with computer systems is that computers are deterministic math machines. You don't need to test a computer system because it's output is 100% consistent and bounded by theory (most of the time). Thus you can use axioms, theorems and proofs to build your systems. This is not an "evidence based" or scientific approach to architecture this is within the realm of math and logic. Unfortunately a large part of software is still an art and we still treat a huge portion of it as if it was a physical unpredictable system with unit testing. Theory is a bit underdeveloped in computer systems. Where it is underdeveloped is: any engineering problem that sports the term "design" is a problem space where no theoretical basis exists (or is known to exists by the user of the term). For example the "design" of "system architecture" Amazingly such a theory sort of actually exists in Computer Architecture but is relatively unknown. It's newish, not concrete and it's not fully fleshed out in the context of computer system design. It's called Category Theory and it's mind bending because it turns this vague concept of "design", "architecture", "abstraction", "composition" and "process" into a language that is formal and well understood. Though I don't think it's part of category theory yet, and I'm still a bit of beginner, but a formal language for system architecture at every layer allows for a different way of solving problems. Instead of "designing" solutions adhoc, we could be able to "derive" solutions. Given a problem you would be "deriving" a system architecture as a solution rather than designing one. This is what I see missing from every single one of Martin Fowlers lectures. He treats this stuff like it's 100% art, and while it largely is, the overall goal of architecture should be an application of Theory, Science and Art. Theory is priority, it says definitive things about a system, Science is secondary as it gives quantitative probabilities about things not described by theory, art is tertiary as whenever you employ art or your "design" chops you are admitting that you are operating in an area where no theory or science exists (yet). Martin Fowler treats architecture as if it was 100% in the domain of art, when the reality is it's actually the amalgamation of all three concepts.
  - sooheon 7y ago
    > He treats this stuff like it's 100% art Is this true? I'm just picturing in my mind juxtaposing Fowler's writings and I dunno, an art critic's. Category theory is cool and important, but to insinuate that all design problems can be "derived" by it sounds like a mathematician declaring that the work of all civil engineers as just "applied math".
alanfranz 7y ago
Martin always has good points. What I miss from him is proofs. The weeks vs months part crossover for internal quality... How is it measured? Is it just a thought, or a wish?
- moksly 7y ago
  In the public sector of Denmark we’ve been on a decade long journey toward better Enterprise Architecture. We have national guidelines for how we want public system/services to be build and how they should be able to transfer data through APIs. We don’t get completely technical, telling you what tools you need to use to build your software, only how your software needs to fit into the environment that is public sector digitalisation. The reason we do this is because we’ve seen what happens when we don’t. The municipality where I work operate a pretty common amount of IT systems. We don’t know exactly how many because there isn’t a centralised unit to handle them all, but our guess is 300 different IT systems. There is a lot of common things these systems need, like authentication. That used to be terrible. Before web-services and federated IDPs it was quite literally maintaining our organisational hierarchy in 300 different IT systems manually. And that’s just our place, in Denmark we have 98 municipalities that all have 300 IT systems run by different suppliers. With a common architecture we defined how organisational data needs to be interpreted by these systems, we also build a single co-owner database where each municipality could make these data available in the same defined format, through the same APIs. It’s already saving us millions, just from this tiny piece of the much bigger picture. It’s not been without backlash either, because as it turns out, private tech companies don’t actually want to build the smartest systems. They want to sell us silo systems, because then they can sell us access to our data 300 x, where 1x could be organisation data and another x could be statistics. Anyway, I think we have evidence that architectural choices matter a great deal. At least when you look at it from an enterprise sized point of view. With that said, I’m not sure I buy detailed application architecture, where you design everything in your favourite markup-language, either. We certainly have no evidence to support that this sort of architecture isn’t just a waste of time. But for the big picture, in enterprise sized organisations, you can’t live without IT-architecture if you want to be efficient. If you want to read more about it, you can at: http://info.rammearkitektur.dk/index.php/Forside http://info.rammearkitektur.dk/index.php/Forside but it’s in Danish.
z3t4 7y ago
I start with a raw stone, and carve away the crud ... then I bring the duct-tape ...
chewyshine 7y ago
Unusually useless post. An aggregator that says little. Too bad.
- omk 7y ago
  I would really like to read through a solid post that details Enterprise Software Architecture. As the author mentions, it certainly is hazy and I wonder if you can bring in 2 architects form different firms to talk the same language. Wonder if HN has a recommendation.
  - billfruit 7y ago
    I think many students will benefit from a detailed study and analysis of a large, real world software product/project, but unfortunately I think most of such knowledge/experience in the industry is never recorded anywhere and is simply lost when the people and teams, age and retire or move away. it is almost impossible to get access to internal software development docs from major developers, then if none outside can see them, how can they be studied, how can anyone find lacunae in them..
  - perlgeek 7y ago
    Not an article, but a book: "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solution" by Hohpe and Woolf (You don't need to read all the patterns in detail; reading the overview will be enough to get you a pretty good idea. You only need to read the details when you seriously consider implementing a pattern).
Spearchucker 7y ago
Oh man. Another diatribe from Martin Fowler™. Takes me back to the 90's when I was in awe of teh architectures and architects, understanding of which was always just beyond my grasp. 99% of software I've encountered has some kind of interface, a domain it operates in, and data it operates on. Call these three things layers. It also has some cross-cutting things that are universally available in the software - broadly, security, comms and exception management. You deploy these things on desktops, phones, and devices. Other parts of the things live on servers or on clusters, mabe. Call these places (hardware) tiers. There. Architecture done. From micro services to huge banking monoliths. Start there. Everything else is the usual let's think about what we're doing before we do it. But I guess keeping it simple and dealing with exceptions as they arise isn't as glamorous as using fancy new names, working for a hipster consultancy or generally saying X or Y is teh new futures. If you harbour doubt great, questions are good. I suggest obtaining a copy of Wicked Problems, Rightous Solutions (ISBN-10: 013590126X). It will show you that we had EXACTLY the same problems of today, back in 1990. We just call them new things.
- scarface74 7y ago
  I learned a lot from Domain Driven Design and some from Design Patterns by the GOF.
  - deleted 7y ago
    [deleted]
- tootie 7y ago
  As far as I understand Fowler's posts, it's mostly about distilling best practice and ways of thinking. I haven't seen anything advocating anything more complicated than what you're describing. I've seen a lot of enterprises that don't do any of this. Ball of Mud is still pretty prevalent.
- wpietri 7y ago
  You say this with a lot of bile, but I'm not sure where your opinions actually differ from Fowler's. He says right in the second paragraph that he's suspicious of the term "architecture" because it "often suggests a separation from programming and an unhealthy dose of pomposity." I think keeping it simple and dealing with exceptions is great. And so does Fowler, I'm sure. But I've been doing that a long time and I've learned some lessons about what "simple" means, and how some ways of dealing with exceptions work well in certain circumstances, while others can seem appealing but end up being a mess. Like you, I think high-church, prescriptive software is mainly a giant waste, a way for fast talkers to get big paychecks while performing oh-so-smartness. But that doesn't mean over decades of coding we can't learn anything about they ways we build systems.
gregdoesit 7y ago
I have been building large scale/distributed systems myself and reviewing designs of systems like these being built around me, for years now. I have never come across any of the type of ivory tower architecture that this post and other sofware architects write about. We're talking about real-world systems that are high-load and somewhat novel, with battle-scarred engineers building them. I find it ironic that that many of the people who write about architecture are consultants or writers. Consultants usually come into a project, make some decisions and write some code in a few months. Then they leave, without having to maintain the application. Of course they bring in fancy-named architecture patterns as one-size-fits-all solutions, leaving before the cracks on the approach show. Ever notice how little writing there is about iterative software design? For writers, it seems they build a simple proof-of-concept solution, that is never deployed in production, documenting this process and showing it off as an example. Yet, when it comes to writing about software architecture, this is 90% of the materials. Engineers who build this day in, day out, design systems from inception, iterate on them, code and deploy, then maintain and operate them for years - they barely share what approach they took. And it's none of this fancy-talk in articles like this one. It's not UML or other formal methods. It's simple documents, simple diagrams, lots of discussion about tradeoffs and tons of back-and-forth comments over Google Docs/O365 and in real life. I'm at the point where I'm serioulsly debating writing something more substantial on how actual software design works at tech companies, when you're not a consultant or a writer, but an engineer who does this full-time, end-to-end, living with all the consequences of decisions and fixing mistakes after. On the importance of prototyping, extensible MVPs, whiteboarding, documenting an initial design and getting feedback, iterating on it, architecture jams, design war rooms - and when starting again when the world/business changes substantially, keeping things running and migrating things over to the new system.
- hliyan 7y ago
  I've been doing exactly the same for the past 16 years, and my experience has been exactly the same as yours. Never seen any of these proposed models work in reality, and never seen these models come from industry or academic veterans.
- notus 7y ago
  I work at a fairly large company you've heard of and there is definitely a lot of application of the practices that he preaches. It never works perfectly because nothing ever does, but the effect of his teachings is noticeable. They are ideals to strive for. The failure at implementations tends to be more a people and process problem than a technical problem.
Merrill 7y ago
The Enterprise Architect's job is rather more like that of an Urban Renewal Planner than an architect. There are many pre-existing structures, many interested parties with varying degrees of control, and many economic and technical constraints to be satisfied within a larger political system.
EdwardDiego 7y ago
> All I see is yet another reasonably sounding yet unsupported piece of folklore. Another artefact of the fact that software developers are still craftspeople - as in "someone skilled at making things by hand". Software development output is something that no-one has yet successfully quantified. There's no easy metric to assess a non-productive software developer from a productive one. We can all tell the difference, but good luck measuring it. In my country, which (thankfully) lacks America's "at-will" employment contracts, it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use? Bug rate is a bad one, because very smart people working in a new problem domain may register an significant uptick in bugs - doesn't mean that they're incompetent, it's just the result of doing new stuff in an unfamiliar domain in a highly complex environment. Lines of code? The less said about that metric and how gameable it is, the better. Us still being craftspeople is also why we can command such high wages relative to the rest of the economy - what we do is not yet automated, so we can still draw a premium.
- noobiemcfoob 7y ago
  > it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use? I think your criticism of 'at-will' employment is unfounded in this scenario. Having lower guardrails on employment means it's not as pressing to figure out performance metrics. If the company narrative is that an employee is helpful to the mission, then there isn't much cause to fret for a more perfect metric. And at-will means you can test more employees before committing to a few for longer than a couple years.
  - CraigJPerry 7y ago
    > I think your criticism of 'at-will' employment There was no criticism of at-will employment in the parent post. That's a hair trigger you've got yourself there fella.
    - noobiemcfoob 7y ago
      > In my country, which (thankfully) lacks America's "at-will" employment contract I'm sorry, is that not obviously criticism? My parser must be busted again.
mrkeen 7y ago
Martin Fowler: "Architecture is hard to define, but I'll try. Good architecture allows the system to evolve. Bad architecture attracts cruft and makes change hard." HN: "Fuck this ivory tower bullshit! Where's the evidence?!?!"
- aklemm 7y ago
  Exactly. In fact, this thread looks like people cargo-culting what it means to be evidence-based (hint: life and work will always contain some reasoning and craft).
  - TeMPOraL 7y ago
    At this point it seems that there's more comments that start by saying "OMG HN is so negative about Fowler" than there are comments actually doing this. I have this working hypothesis that HN is a nexus where multiple alternative realities intersect, which is why I sometimes find threads with 5 comments complaining about HN negativity to one or zero comments that are actually negative...
    - aklemm 7y ago
      Well, the cavalry comes in and soon outweighs the misguided negativity...at least in this thread. The negative comments were definitely outstanding.
- mjburgess 7y ago
  My objection is the "ivory-tower bullshit" is wrong. He goes to pains to fail to define architecture and rejects a reasonable definition for a confused genetic fallacy about social construction. "Architecture" isn't understanding. Understanding is of Architecture. If architecture were merely "the common understanding of what's important" there could be no disagreement or understanding of the software. Disagreement would be hopelessly social: you could never say "this is too complex", but only, "your understanding is wrong". > "My view is that applications are a social construction" Deeply confuses many issues. Applications are made by people, as are tables, but neither are "social constructs" -- which mean they are irreducibly subjective group phenomenon. Software runs on machines. The running machine isn't a subjective group phenomenon. "1 + 2" is code, mathematics isn't a "social construct". "Architecture" refers to the structural elements of a domain (ie., how the domain objects are related to each other, and how these relations are related to each other, etc.). It is a relative term, but not a subjective one. eg., The "architecture" of a animal is how its parts fit together. The "architecture" of a leg is its pieces fit together. And so on.
Ozzie_osman 7y ago
Lots of hate in this thread.. People asking for proof: what sort of evidence would convince you? I take these blog posts, apply it to my experience, and take what I think makes sense. Sometimes, an idea will solve an obvious pain I've had. Sometimes, an idea will show me a pain I didn't know I have. Sometimes I disagree with the idea because it won't work for me. That's fine. I'm still much better off thanks to this literature, and I would be worse off if it all had to be evidence-based. If you think you can write better based on your experience, please go for it. I'd love to have more literature to read, analyze, and learn from. If you can't (pressed for time, etc), and only have time to post in HN comment threads, then at least discuss concretely which parts you disagree with so we can learn from that too (I'm serious, not being facetious). If you can't even do THAT, then sorry, all your valuable experience is way less useful than someone like Martin Fowler, because I'm not learning anything from you. Having a good understanding of how to architect code is hard. Being able to write about that in a way that's useful for others is even harder, and is a skill of its own. So personally, I thank Martin & Co for all their writing.
- deleted 7y ago
  [deleted]
- vikingcaffiene 7y ago
  Thanks for this. The initial wave of hate on this post had me worrying that we are collectively forgetting the lessons of the past. This industry continually re-invents the same concepts over and over again and just re-brands them. Once you recognize that, the writings of Fowler & Co become highly applicable to many scenarios.
  - sidlls 7y ago
    Is this because what they've written truly works or is it because they've simply managed the same thing as the loudest engineer in the office, at larger scale?
    - vikingcaffiene 7y ago
      Well HN knows a thing or two about the latter ;) It’s because I write better software in a team setting when I apply the techniques and philosophies of Fowler & Co. The biggest complexity in software is people. Coordinating them, navigating egos, and leveraging their experience levels. It’s a hard problem and the place where I see the most consistent system problems. IMO Fowler is just providing accessible common sense strategies for dealing with that complexity.
karmakaze 7y ago
Let's talk about any good parts. The architecture of systems varies enough that there isn't a good concrete definition. An aspect that's important for one system isn't for another so it's hard to say which aspects are part of an architecture. Unless you're always architecting the same types of systems, this will carry some weight. The other idea that architecture is present but not visible is a great one. It's the important bits that are underlying or overarching or otherwise permeates the system without necessarily being separately visible. I've had so many difficult chats talking past one another about different levels of concern. When one side only sees what's named or in the diffs, it's hard to convey why something else is more important when there's a lack of 'shared understanding'. I did have this experience when I was making a relay service which handled a headless browser and audio streams. Each of these ended up using a state machine so I separated the state machine mechanics and implemented each using it. The result ended up having many state machine visible parts than the interesting (for the use-case) non-state-machine parts. I undid all that and made each back to primarily do its job as a state-machine but it was far less visible. This isn't the best of examples but it's one where I learned that sometimes you want things to be less invisible even when it's important.
vikingcaffiene 7y ago
I gotta say I am surprised and a little disheartened by all the negativity around this post and Fowler in general. Fowler's writing has been a huge inspiration to me in my career. I'm about to gift a copy of his book "Refactoring" to one of the junior engineers I work with for instance. I think the idea of an architecture as a social construct is very fitting. Software is hard when multiple people are working on it with differing backgrounds and experience. Having a rough outline (emphasis on rough here) of "what lives where" and "what is allowed to talk to what" is absolutely critical IMO. It's how your team can effectively reason about a system and add new features to it. It should also be a living thing in that it's something that is continually refined, discussed, and changed as the needs of the business change. Done right, its an organic process that really helps deliver more robust software that everyone involved has a high level understanding of. Contrast that with an Architecture (capital A) done in Enterprise which delivers a static artifact that does not allow for any creativity and micromanages every aspect of it. It's split off into chunks and no one without an expert level of knowledge can easily understand it. That kind of design will almost certainly fall over the first time there needs to be a change to it. It's important to point out the difference because that is NOT what Fowler is recommending in his writings.
- wpietri 7y ago
  Totally. In a side room at Java One in 1999 or 2000 I saw Fowler talking about Refactoring, and he happened to bring Kent Beck up on stage to talk a bit. If I hadn't been exposed to their ideas, I surely would have left software by now. Over and over, my experience was building something that slowly got less tractable over time, where eventually we'd just want to do a big rewrite. It sucked! I had tried the big-design-up-front approach, where I thought real hard for a long time before building. That might push out the rewrite date some, but definitely not forever. It was dispiriting, a slow, sticky death. That combined with crunches and burnout was slowly making me hate something I had loved doing. But their main point was that code bases didn't have to end in an entropic snarl. That with decent tests and a little elbow grease, code could get better organized every time we touched it. That instead of death by papercut, we could make things a little better every day. Better for the users, better for the business, better for the developers. They weren't promoting silver architecture bullets. They were saying that we should trust and empower teams to figure it out. That if we gave them room and tools to figure it out, everybody would end up happier. It made a huge difference in my life, so it's weird to see people here aggressively putting words in Fowler's mouth, words that seem entirely at odds with my experience of him and his work.
Kortaggio 7y ago
The author's statement that "My view is that applications are a social construction" I think hints at a deeper truth, that while _code_ is run by machines, managing a _codebase_ is more like raising a plant in a garden and not like changing the oil in a machine. Reminds me of "A Codebase is An Organism"[1]. [1] https://meltingasphalt.com/a-codebase-is-an-organism/ https://meltingasphalt.com/a-codebase-is-an-organism/
- dredmorbius 7y ago
  See also: Conway's Law. http://melconway.com/Home/Conways_Law.html http://melconway.com/Home/Conways_Law.html
eddieh 7y ago
Would it help if instead of software "architecture," we called in software "organization?" It seems like nobody would demand "proof" if Martin was arguing that it is faster and easier to find a book in a library than it is to find a book at the dump.
jeffdavis 7y ago
Architecture is your chance to decide which problems will be easy and which problems will be hard. In a microservice architecture, failure handling is easy. State management is hard. In a centralized database architecture, failure handling is hard. State management is easy.
- ris 7y ago
  > In a microservice architecture, failure handling is easy I'm not sure I would agree with this - it's still incredibly hard to be able to make the rest of your architecture do something useful when a significant part of it goes away. Multiply the possibility of one of your important services going down by the number of important services you have...
neya 7y ago
People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my company. I follow Martin Fowlers' articles on using DDD (Domain Driven Design) and Microservices to architect applications. What should have been a month long project took us 8 months! I'm not including the time I took to read about, understand and practice DDD and the surrounding concepts. Every DDD book is atleast 500 pages or more. And none of them are clear on the concepts, and are mostly full of fluff. To give you more details, our stack was based on Phoenix, but it used a concept called Umbrella applications (basically Micro services pattern). Along the way, I hit so many snags and I thought I must be doing it wrong. Because, that's what these authors kept saying all the time to people who had failed to implement their preachings. So, I met a couple of people who had actually done this DDD on a much larger scale than I had and even they shared the same experience and stories of failure and struggling. Still, I shrugged them off thinking it must be something we were doing wrong instead of DDD/Fowler's teachings itself. In the meantime, we were struggling to launch features for our E-Commerce software because our microservices architecture based on DDD was just a house of cards at this point. And then, I finally called up someone I knew who had done DDD successfully and asked him how he did it. He said one of the authors of a popular DDD related website, had offered to consult for his company. And they had no choice but to employ him because they were pretty invested at this point. After a while, I started meeting a bunch of such companies who got their DDD setup done by either authors or by some vendor these authors had a stake in. And then BINGO, it all made sense - most of these patterns/shortcuts/discoveries/secret sauces by these authors are hardly tested by them. It's just a way to sell you more consulting and training. A couple of weeks later, we hosted a casual meetup for tech talks in our area and we got to meet more folks who had followed the same path and failed. We finally decided to do a small hackathon over a weekend and get our projects done. In the end, in about 3 days from Fri-Sun, we had got done so much more with a monolithic architecture than we had ever gotten done with DDD and microservices. Today, my platform is in production and is a proud monolithic app and still going strong. It was perhaps the most expensive lesson I've ever learnt, but one that I will remember for a long time.
- MiyamotoAkira 7y ago
  2015: https://www.martinfowler.com/bliki/MonolithFirst.html https://www.martinfowler.com/bliki/MonolithFirst.html
jeswin 7y ago
I looked at this thread a while back and closed the window, hoping that those early comments don't influence the younger practitioners who are on HN. As someone nearing 40 (mainly doing consulting work around boring business apps for a long time), my view is that Martin Folwer's biggest contribution is indeed the documentation, and defining the vocabulary to enable discussion around frequently encountered (but perhaps mundane) problems in Enterprise Application development. He isn't trying to break new ground, but I'm glad his writings exist. To pick a very random example, here's CQRS defined in an approachable manner[1]. It's a great link to send to a team of 50, out of which quite a few will be fresh out of college. And I am pretty sure Martin Folwer has seen plenty of real world code while he was working at Thoughtworks. The ideas in his writings aren't conceived in some vaccuum. Some of his early writing isn't perhaps as relevant today. For instance, he talks about the flaws of Anemic Domain Model here [2]. Back in the day, many of us tried to enrich the domain model with particular emphasis on reusability. But those things are less relevant in today's heterogeous environments where logic lives across in multiple services (many outside your team's control). So just reading through his site will surface a lot of outdated ideas; but that's helped a lot of companies along the way when we didn't have to aim for web-scale tps. Actually, it might still work for 99% of apps even today. HN tilts towards the experiences of Startups and young founders, but one good lesson to learn early is that we should be more open minded. 1: https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html 2: https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html
- Ozzie_osman 7y ago
  Your point on vocab is so spot on. Simply identifying something as a pattern and naming it is tremendously valuable. Doing it in a way that's packageable and shareable with others is not easy at all.
  - camgunz 7y ago
    Agree, but people tend to stop at Fowler and live it as gospel. There is a profound richness in the different ways to think and talk about computers, engineering, and information science, far more wonderous than any one person can catalog. Read SICP, Knuth, Code Complete, Codd. Hell, just YouTube around. If your vocabulary is prescribed by literally one guy in a fedora, you gotta get out there. Might I suggest Joe Armstrong [1] :) [1] https://youtu.be/lKXe3HUG2l4 https://youtu.be/lKXe3HUG2l4
cliffcrosland 7y ago
Reading an enumeration of architecture options can be helpful, but I've probably found more value in works like Ousterhout's "A Philosophy of Software Design" that cover fundamental design principles. Such principles seem to be applicable no matter the project. I appreciate that Ousterhout tries to support these principles with some data from his own experience (building Tcl, RamCloud where Raft consensus was discovered, etc) and from code reviews of student projects in his design course, but he admits that there is a lack of data about things like design. Sample principles from Ousterhout: * When developing an interface, favor exposing a small number of functions each with deep functionality over exposing a large number of functions each with shallow functionality. For example, favor Unix file I/O interface (open, close, read, write, unlink) over Java file I/O interface (File, FileReader, BufferedReader, FileWriter, BufferedWriter, FileNotFoundException, ... etc.) * When choosing between keeping your code specific and keeping your code general, favor "somewhat" general. For example, instead of exposing "deleteNextCharacter(text, pos), deleteNextWord(text, pos), deleteNextSentence(text, pos)", just expose "delete(text, pos, length)" and let the caller use it how they will.
- blub 7y ago
  Yes, "A Philosophy of Software Design" is brilliant, precisely because the author supports their statements through the many experiments they performed with students and The fact that they're the author of a well-known piece of software helps, although we should not use this as the main criteria to evaluate a text. Offering at least evidence based on experimentation is essential if we want to move past personality cults and having entire teams work based on what someone wrote on a blog somewhere.
  - sriku 7y ago
    I'm wondering whether another factor that might be at play is that as consultants they may not be at liberty to discuss that kind of detail. Barring that, it would be interesting to have Fowler sit in Ousterhout's class, take on an advanced problem and see what they come up with.
goatinaboat 7y ago
The key to understanding Fowler and similar, and Thoughtworks, that the methodology is their product. They sell consulting and training and seminars and conferences and books. If any useful, working software is produced that is at best by sheer coincidence and more likely despite their involvement.
kevindeasis 7y ago
The only thing missing is Martin Fowler having his own vlog
dvlsg 7y ago
His biggest contribution may be the documentation and defining the vocabulary, but when he defines a pattern with a word that has an obvious negative connotation ("anemic"), it feels manipulative. A while ago I was told by members of a separate team that I was writing the core of my javascript application incorrectly. I was following "functional core, imperative shell"[1] and intentionally separating my data from my functions[2]. Specifically, the code was considered to be wrong because it was "anemic", and I was sent a link straight to that 16 year old page about anemic domain models[3]. The suggestion to fix was to add a bunch of mutable state. Don't get me wrong - I still almost always appreciate Martin Fowler's writing, as it's often quite good, including the original post. But I also understand some of the skepticism here. --- 1: https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct... 2: https://softwareengineering.stackexchange.com/q/203077 https://softwareengineering.stackexchange.com/q/203077 3: https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html
- charlieflowers 7y ago
  I think that's a case of misguided developers with tunnel vision misusing Fowler's material. I have never met Fowler and I'm completely speculating here, but I would bet money he is both well-versed in, and a big fan of, the "functional core, imperative shell" concept when it is a good fit. Devs often get overly dogmatic, and when they do, they often reach for Fowler quotes to back themselves up. But don't blame Fowler for that.
- UK-Al05 7y ago
  Did you explain that you were following a functional model in your particular app? Traditional OO (Tatical)DDD does involve creating aggregates with mutating state
- lonelappde 7y ago
  OO vs Functional is a religious debate that will never be solved. It's like Catholics and Protestants. Fowler is from the Church of OO (Smalltalk).
contingencies 7y ago
Head closer to the rocks of chaos rather than suffocating control. But being on that side of the channel still means we have to avoid the rocks, and a way to maximize local decision making in a way that minimizes the real costs involved. - Martin Fowler ... added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
akayoshi1 7y ago
Lovers gonna love, haters gonna hate.
JBSay 7y ago
I started reading his sample chapter on refactoring and I'm constantly put off by some really rookie mistakes and bad code practices like naming a function after nouns instead of action verbs (e.g. "amountFor" instead of "computeAmount").
tsarquitech 7y ago
We see that Martin Fowler is influenced by Ralph Johnson in deriving for himself a definition of architecture. In particular, there was no objective way to define what was fundamental, or high level And goes on to lean heavily on the idea that ‘application architecture' is a social construct. But I am then left with a thought that if application architecture is a social construct, that means there should be identifiable social characteristics that make-up the application architecture, characteristics that can be further quantified to an acceptable degree, such that they can be defined as fundamental. Taking a step back from Martin’s influence & conclusion, and ask ourselves, “couldn’t software architecture, or architecture in general, be defined by a set of heuristics that lead to objectively defining what is fundamental to a particular context?“ Suppose we create three rules that need to be defined before reaching our conclusion: - context: what scale does the architecture in question reference? - collection of computing elements: what are the computing elements (this can range from machines to software) - connectedness: how are the computing elements connected? For example, in order to determine the architecture of my web scraping local machine setup I would go through the rules: - context: a single script file with code written to accomplish the task - collection: functions that are used to perform the task of scraping the webpage - connectedness: functions pass data to other functions to perform specific tasks of scraping In this example we have a guide to achieve objectively what is fundamental to our architecture.

803 points by rspivak 7y ago

blub 7y ago

Whenever I see yet another article by Martin Fowler, Kent Beck, Robert Martin & co I ask myself - where is the evidence for what they are preaching? What are the graphs based on? What is the evidence behind the proposed rules? These authors are clearly accomplished blog and book writers, but anyone whose software-related accomplishments are not open source or at least well known should have their statements scrutinized more closely. I don't see any studies cited, case studies presented or concrete examples. All I see is yet another reasonably sounding yet unsupported piece of folklore.

millerm 7y ago
I have had this thought for many years. Where is all the perfectly designed, bug free, maintenance-bliss, fully documented, fully tested, future-proofed code located so we can all marvel at its glory?
- mirceal 7y ago
  > All code is bad. Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world. from: https://www.stilldrinking.org/programming-sucks https://www.stilldrinking.org/programming-sucks
- michael_j_ward 7y ago
  I haven't gone through this yet- but my understanding is that there are some examples of this here "The Architecture of Open Source Applications" [1]. [1] http://aosabook.org/en/index.html http://aosabook.org/en/index.html
- mobjack 7y ago
  You are comparing the perfect against the good while Fowler is likely comparing the good against the bad. Taking an extra week or two to clean up bad design decisions early in a project can pay dividends in the future. Spending months extra trying to do the perfect architecture is harder to justify.
randomcarbloke 7y ago
Thank you. If I want to design excellent architecture I will crack open SICP and transpose it to the fabric of modern computing. I also take issue with much of what Fowler et al say, but that's another conversation.
- notus 7y ago
  SICP isn't going to teach you excellent architecture for large systems, it's going to teach you excellent architecture for small programs.
  - crimsonalucard 7y ago
    The design of small programs is isomorphic to the design of large programs at all levels. You're just referring to real world caveats and details, but the overall concepts taught in SICP apply to all layers of programming from assembly to the architectural level. Small programs: Q = A -> B W = B -> C R = C -> D T = D -> E Large Programs L = W . Q K = T . R Architecture M = L . K The above description works at every layer. SICP deals with abstraction and architecture at all layers of programming. It does not talk about real world idiosyncrasies of the system. For example it won't talk about whether the assembly instructions of the small program being executed is efficient and it won't talk about network latency.
    - dwaltrip 7y ago
      > The design of small programs is isomorphic to the design of large programs at all levels Good software design is not scale invariant. Significant scale deltas change things in fundamental ways. Designs that work and are maintainable, from a human perspective, at one scale often will fail at a larger scale. Some designs scale better than others, this is true. But no design scales infinitely, and the vast majority of designs would start performing poorly at scales that are still relevant to human concerns This shouldn't be surprising. Most things (nearly everything?) that we care about are not scale invariant.
      - 7y ago
chrisseaton 7y ago
For some of these speakers, I’ve literally never seen any evidence that they’ve written a single line of code. Why should we listen to Fowler? What large successful projects has he created using his ideas are there that I can look at? Where’s the data behind his slides? It’s all just talk talk talk. I’d listen to someone like Chris Lattner talk about how to design and write software because I can see whatever approach he uses must work well. I should listen to these full-time speakers because... I don’t really know and perhaps we should start challenging their talks by asking for the data behind them.
- scarface74 7y ago
  Chris Lattner knows how to write system software and compilers which are completely separate beasts from the typical bespoke enterprise or software as a service apps that most developers write every day.
  - deleted 7y ago
    [deleted]
  - vfc1 7y ago
    Exactly, many times these famous authors advocate for practices that make sense for building compilers and frameworks or libraries, but that make little sense for building applications. Building applications is very different, because an application is the very end of the software tree dependency. Some practices make sense for both types of software, but many others don't and some of these authors don't seem to be able to make the difference.
    - scarface74 7y ago
      And sometimes it makes sense to take shortcuts that don’t make sense from a long term maintenance standpoint just to survive long enough to get product market fit. Get funding and survive. Twitter is a perfect example of this. Everyone agrees that Twitter made some bad architectural decisions that caused the frequent appearance of the “fail whale”. But eventually, they got enough funding via combination of the VC funding and later the public market to rearchitect their system.
mirceal 7y ago
all these people have some experience in the field and they did put some things out that gave names/spread practices in our industry. is that enough to take everything they spew as the truth? far from it. you should probably take a look and filter it through your experience.
streetcat1 7y ago
So first, you should read their books for concrete code. Martin books, for example "refactoring" or "Enterprise architecture" actually have good code examples. The same apply for kent beck early work on smalltalk (you can look at Junit) or his early work on the HotDraw editor (which was the source of many of the pattern in the Design Pattern book). Kent was one of the first adopter of smalltalk at the early 80 is techtronix, together with ward cunnighum (the inventor of wiki) and rebbeca swift brooks. Robert Martin work is mainly driven by his consulting practice and tend to change based on the on going trend. At the 2000's he was working with Grady Booch, preaching UML and design before coding. Later he dropped that in favour of agile and TDD. You do not see case studies since the industry simply does not really care. It is very trend prone. Most of the adopted advances were actually "hacks". For example C++ was invented out of necessity to create "C with objects" by a single person in AT&T labs. Unix was hacked in 3 weeks. Java was invented to program toasters, etc. Any attempt to develop tools and technique based on real research saw not adaptation - for example Ada at the 80s, UML at the 90's and early 2000, functional programming, TLA+ , etc.
- geofft 7y ago
  The question was about "research" in the meaning of quantitative scientific evidence that these proposed techniques make software delivery better in real-world conditions, not "research" in the sense of new ideas from academics. As a professional, I don't want UML because I've seen no evidence it actually helps. Show me relevant studies that it does and I will absolutely change my mind. (And there are plenty of things that industry does respect that came from academic research in the sense of new ideas. Rust, stereotypically the language of the trend-prone, draws on everything from Ada to functional programming. But unlike those it actually and demonstrably meets the needs of general-purpose programming in industry.)
  - streetcat1 7y ago
    Sure. So UML is based on two main research areas - UML class diagram is based on rational algebra theory. A correct UML class diagram should follow the same normalization roles as defined by Codd seminal paper - "A Relational Model of Data for Large Shared Data Banks". You can ask, how does Prof Codd knows that this is is the correct way to describe and implement data. Well this follow directly from set theory. Again, how do we know that set theory works - well here we are the level of axioms of the set algebra. BTW, this Codd work was also "hacked" again by system R research which invented SQL. The other part of UML is based on finite state machine, which originated by Turning, and later refined by the work of David Harel on state charts. Again, those are theoretical CS tools. However, the work of Harel on state charts, was originated from the work on the Israel first aircarft (to be cancelled later), where he needed to define the the missile system. If you are interested on how those tool originated and later combined see the work of David Hay - "UML-Data-Modeling-Reconciliation" Those tools are useful in scale. For example, system with 3000 different use cases. Or for example you have 200 - 500 classes, each is a state machine. Again, since there is no software professional standard (not software engineering bar exam), you can or cannot use anything.
hliyan 7y ago
I agree. These theories should either be based on empirical evidence, simulations or built up from first principles in a rigorous manner. Otherwise they are about as concrete as philosophical treatises. Which is to say, not very concrete at all.
jmartinpetersen 7y ago
Robert Martin seems to cherry pick stats and trends and whatever that fits his world view. In Clean Architecture he cites a study with N=1 as proof TDD works. I have no hope for him.
- billfruit 7y ago
  I generally dislike building arguments on top of statistics, rather than on theory which to my eye almost always looks more convincing. With statistics it is as if the burden is passed on to the reader to check the veracity and validity of the said numbers, where as if it is an argument constructed out of theory, the whole of it is present there for the reader to judge intrinsically on its own merits.
  - gunnihinn 7y ago
    That restricts you to mathematics, logic or philosophy. Engineering, or the rest of the world, operates _at best_ on statistics.
    - billfruit 7y ago
      Programming in general and Software correctness does not depend upon statistical arguments, so perhaps such a view could be taken for software engineering too. Also even considering aesthetics and elegance, I find use of statistics to power a reasoning, ungainly, compared with other means of arguing the same thing.
      - crimsonalucard 7y ago
        You're right. Why are you voted down. Programming doesn't need to be based on statistics it's largely a deterministic system amenable to proof and logic. This application of "engineering" onto programming is largely the result of people not truly understanding the system they are dealing with. The system isn't some sub-sonic jet that will be subject to unknown turbulence, it's just axioms and rules.
  - 7y ago
hacker_9 7y ago
Agree. They talk the talk but don't walk the walk.
deleted 7y ago
[deleted]
notus 7y ago
They are speaking primarily from experience and I think they are pretty transparent about that. We're not in a field where many studies even exist on these types of processes. It is up to you as a developer to try them out and assess their merit.
pjmorris 7y ago
To take the other side of this coin, where is the evidence that evidence makes a difference? At least, where is the evidence that evidence is what convinces a software developer or manager to change something about their process? There are entire conferences [0,1] where hundreds of researchers present peer-reviewed studies, case studies, and concrete examples, evidence for various software engineering claims. Thousands of papers have been published at these conferences over time. Usually when those papers are linked here, they don't get much attention, e.g. [2], [3], [4]. As a rule, industry doesn't pay attention to them, except to hire the grad students out of academia. At these conferences, they spend a lot of time discussing how to get more industry participation. But the things they try haven't really worked so far. To go to all the trouble of generating peer-reviewed science only to have it ignored may not be the best trade available for how Fowler, Beck, et al spend their time. There are doubts about whether it's the best way for academics to spend their time. [0] http://www.icse-conferences.org/ http://www.icse-conferences.org/ [1] https://www.esec-fse.org/ https://www.esec-fse.org/ [2] https://news.ycombinator.com/item?id=20064211 https://news.ycombinator.com/item?id=20064211 [3] https://news.ycombinator.com/item?id=20575415 https://news.ycombinator.com/item?id=20575415 [4] https://news.ycombinator.com/item?id=19714085 https://news.ycombinator.com/item?id=19714085
fogetti 7y ago
I don't really understand your comment. Shows your ignorance to be honest: have you ever heard of active records? Or optimistic locking? Because these are VERY tangible software constructs and Martin Fowler for example wrote a whole book about them.
- nafey 7y ago
  The GP was about software architecture styles proposed/endorsed by Fowler et al and not their general contribution to software. Keeping this in mind its fair to ask for data/studies backing their claims.
manojlds 7y ago
I used to work at ThoughtWorks and Martin Fowler's inputs are based on his interactions with many many ThoughtWorks' project teams. When he visited my team for one of those learnings discussions, I was amazed with the way he was able to absorb and present the same things we were learning in a much different and easier to understand manner.
tootie 7y ago
It's good point, but most of what I read on his blog feels like a distillation of best practices that I've seen mature in the industry. It all rings true and matches my experience of what works best. But can I prove it? No, not really.
Chris_Newton 7y ago
There’s nothing wrong with just suggesting reasonable ideas that might be useful. If everything needs to have a solid evidence base or rigorous supporting arguments before we talk about it, it becomes too easy to shut discussion down prematurely without ever discovering whether an idea does have value for someone, particularly in an industry like ours where much of what we do is hard to measure objectively. It’s helpful to be clear about whether an idea being presented is just someone’s personal thoughts or anecdotal experience or whether it does have a stronger foundation. If something is presented as a firm recommendation of good practice then it’s fair to expect the latter. But it’s also dangerous if we reflexively disregard any idea that doesn’t already have robust evidence behind it.
afpx 7y ago
The evidence is out there. If you look at successful libraries and applications, they almost always gave well-defined design and architecture guidelines. In fact, I can’t think of a good software library out there that doesn’t have a solid design and architecture. On the other hand, I often see big piles of mud that have to be re-written over (and over), because people believe architecture takes too long or they believe it’s unnecessarily complex.
crimsonalucard 7y ago
I agree with you. There's another angle to look at it though other then "evidence based" or scientific. In the field of engineering a large portion of it has to do testing to verify systems that are unpredictable or not modelled by theory. For example: building a plane involves testing it a wind tunnel. The thing with computer systems is that computers are deterministic math machines. You don't need to test a computer system because it's output is 100% consistent and bounded by theory (most of the time). Thus you can use axioms, theorems and proofs to build your systems. This is not an "evidence based" or scientific approach to architecture this is within the realm of math and logic. Unfortunately a large part of software is still an art and we still treat a huge portion of it as if it was a physical unpredictable system with unit testing. Theory is a bit underdeveloped in computer systems. Where it is underdeveloped is: any engineering problem that sports the term "design" is a problem space where no theoretical basis exists (or is known to exists by the user of the term). For example the "design" of "system architecture" Amazingly such a theory sort of actually exists in Computer Architecture but is relatively unknown. It's newish, not concrete and it's not fully fleshed out in the context of computer system design. It's called Category Theory and it's mind bending because it turns this vague concept of "design", "architecture", "abstraction", "composition" and "process" into a language that is formal and well understood. Though I don't think it's part of category theory yet, and I'm still a bit of beginner, but a formal language for system architecture at every layer allows for a different way of solving problems. Instead of "designing" solutions adhoc, we could be able to "derive" solutions. Given a problem you would be "deriving" a system architecture as a solution rather than designing one. This is what I see missing from every single one of Martin Fowlers lectures. He treats this stuff like it's 100% art, and while it largely is, the overall goal of architecture should be an application of Theory, Science and Art. Theory is priority, it says definitive things about a system, Science is secondary as it gives quantitative probabilities about things not described by theory, art is tertiary as whenever you employ art or your "design" chops you are admitting that you are operating in an area where no theory or science exists (yet). Martin Fowler treats architecture as if it was 100% in the domain of art, when the reality is it's actually the amalgamation of all three concepts.
- sooheon 7y ago
  > He treats this stuff like it's 100% art Is this true? I'm just picturing in my mind juxtaposing Fowler's writings and I dunno, an art critic's. Category theory is cool and important, but to insinuate that all design problems can be "derived" by it sounds like a mathematician declaring that the work of all civil engineers as just "applied math".

alanfranz 7y ago

Martin always has good points. What I miss from him is proofs. The weeks vs months part crossover for internal quality... How is it measured? Is it just a thought, or a wish?

moksly 7y ago
In the public sector of Denmark we’ve been on a decade long journey toward better Enterprise Architecture. We have national guidelines for how we want public system/services to be build and how they should be able to transfer data through APIs. We don’t get completely technical, telling you what tools you need to use to build your software, only how your software needs to fit into the environment that is public sector digitalisation. The reason we do this is because we’ve seen what happens when we don’t. The municipality where I work operate a pretty common amount of IT systems. We don’t know exactly how many because there isn’t a centralised unit to handle them all, but our guess is 300 different IT systems. There is a lot of common things these systems need, like authentication. That used to be terrible. Before web-services and federated IDPs it was quite literally maintaining our organisational hierarchy in 300 different IT systems manually. And that’s just our place, in Denmark we have 98 municipalities that all have 300 IT systems run by different suppliers. With a common architecture we defined how organisational data needs to be interpreted by these systems, we also build a single co-owner database where each municipality could make these data available in the same defined format, through the same APIs. It’s already saving us millions, just from this tiny piece of the much bigger picture. It’s not been without backlash either, because as it turns out, private tech companies don’t actually want to build the smartest systems. They want to sell us silo systems, because then they can sell us access to our data 300 x, where 1x could be organisation data and another x could be statistics. Anyway, I think we have evidence that architectural choices matter a great deal. At least when you look at it from an enterprise sized point of view. With that said, I’m not sure I buy detailed application architecture, where you design everything in your favourite markup-language, either. We certainly have no evidence to support that this sort of architecture isn’t just a waste of time. But for the big picture, in enterprise sized organisations, you can’t live without IT-architecture if you want to be efficient. If you want to read more about it, you can at: http://info.rammearkitektur.dk/index.php/Forside http://info.rammearkitektur.dk/index.php/Forside but it’s in Danish.

z3t4 7y ago

I start with a raw stone, and carve away the crud ... then I bring the duct-tape ...

chewyshine 7y ago

Unusually useless post. An aggregator that says little. Too bad.

omk 7y ago
I would really like to read through a solid post that details Enterprise Software Architecture. As the author mentions, it certainly is hazy and I wonder if you can bring in 2 architects form different firms to talk the same language. Wonder if HN has a recommendation.
- billfruit 7y ago
  I think many students will benefit from a detailed study and analysis of a large, real world software product/project, but unfortunately I think most of such knowledge/experience in the industry is never recorded anywhere and is simply lost when the people and teams, age and retire or move away. it is almost impossible to get access to internal software development docs from major developers, then if none outside can see them, how can they be studied, how can anyone find lacunae in them..
- perlgeek 7y ago
  Not an article, but a book: "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solution" by Hohpe and Woolf (You don't need to read all the patterns in detail; reading the overview will be enough to get you a pretty good idea. You only need to read the details when you seriously consider implementing a pattern).

Spearchucker 7y ago

Oh man. Another diatribe from Martin Fowler™. Takes me back to the 90's when I was in awe of teh architectures and architects, understanding of which was always just beyond my grasp. 99% of software I've encountered has some kind of interface, a domain it operates in, and data it operates on. Call these three things layers. It also has some cross-cutting things that are universally available in the software - broadly, security, comms and exception management. You deploy these things on desktops, phones, and devices. Other parts of the things live on servers or on clusters, mabe. Call these places (hardware) tiers. There. Architecture done. From micro services to huge banking monoliths. Start there. Everything else is the usual let's think about what we're doing before we do it. But I guess keeping it simple and dealing with exceptions as they arise isn't as glamorous as using fancy new names, working for a hipster consultancy or generally saying X or Y is teh new futures. If you harbour doubt great, questions are good. I suggest obtaining a copy of Wicked Problems, Rightous Solutions (ISBN-10: 013590126X). It will show you that we had EXACTLY the same problems of today, back in 1990. We just call them new things.

scarface74 7y ago
I learned a lot from Domain Driven Design and some from Design Patterns by the GOF.
- deleted 7y ago
  [deleted]
tootie 7y ago
As far as I understand Fowler's posts, it's mostly about distilling best practice and ways of thinking. I haven't seen anything advocating anything more complicated than what you're describing. I've seen a lot of enterprises that don't do any of this. Ball of Mud is still pretty prevalent.
wpietri 7y ago
You say this with a lot of bile, but I'm not sure where your opinions actually differ from Fowler's. He says right in the second paragraph that he's suspicious of the term "architecture" because it "often suggests a separation from programming and an unhealthy dose of pomposity." I think keeping it simple and dealing with exceptions is great. And so does Fowler, I'm sure. But I've been doing that a long time and I've learned some lessons about what "simple" means, and how some ways of dealing with exceptions work well in certain circumstances, while others can seem appealing but end up being a mess. Like you, I think high-church, prescriptive software is mainly a giant waste, a way for fast talkers to get big paychecks while performing oh-so-smartness. But that doesn't mean over decades of coding we can't learn anything about they ways we build systems.

gregdoesit 7y ago

I have been building large scale/distributed systems myself and reviewing designs of systems like these being built around me, for years now. I have never come across any of the type of ivory tower architecture that this post and other sofware architects write about. We're talking about real-world systems that are high-load and somewhat novel, with battle-scarred engineers building them. I find it ironic that that many of the people who write about architecture are consultants or writers. Consultants usually come into a project, make some decisions and write some code in a few months. Then they leave, without having to maintain the application. Of course they bring in fancy-named architecture patterns as one-size-fits-all solutions, leaving before the cracks on the approach show. Ever notice how little writing there is about iterative software design? For writers, it seems they build a simple proof-of-concept solution, that is never deployed in production, documenting this process and showing it off as an example. Yet, when it comes to writing about software architecture, this is 90% of the materials. Engineers who build this day in, day out, design systems from inception, iterate on them, code and deploy, then maintain and operate them for years - they barely share what approach they took. And it's none of this fancy-talk in articles like this one. It's not UML or other formal methods. It's simple documents, simple diagrams, lots of discussion about tradeoffs and tons of back-and-forth comments over Google Docs/O365 and in real life. I'm at the point where I'm serioulsly debating writing something more substantial on how actual software design works at tech companies, when you're not a consultant or a writer, but an engineer who does this full-time, end-to-end, living with all the consequences of decisions and fixing mistakes after. On the importance of prototyping, extensible MVPs, whiteboarding, documenting an initial design and getting feedback, iterating on it, architecture jams, design war rooms - and when starting again when the world/business changes substantially, keeping things running and migrating things over to the new system.

hliyan 7y ago
I've been doing exactly the same for the past 16 years, and my experience has been exactly the same as yours. Never seen any of these proposed models work in reality, and never seen these models come from industry or academic veterans.
notus 7y ago
I work at a fairly large company you've heard of and there is definitely a lot of application of the practices that he preaches. It never works perfectly because nothing ever does, but the effect of his teachings is noticeable. They are ideals to strive for. The failure at implementations tends to be more a people and process problem than a technical problem.

Merrill 7y ago

The Enterprise Architect's job is rather more like that of an Urban Renewal Planner than an architect. There are many pre-existing structures, many interested parties with varying degrees of control, and many economic and technical constraints to be satisfied within a larger political system.

EdwardDiego 7y ago

> All I see is yet another reasonably sounding yet unsupported piece of folklore. Another artefact of the fact that software developers are still craftspeople - as in "someone skilled at making things by hand". Software development output is something that no-one has yet successfully quantified. There's no easy metric to assess a non-productive software developer from a productive one. We can all tell the difference, but good luck measuring it. In my country, which (thankfully) lacks America's "at-will" employment contracts, it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use? Bug rate is a bad one, because very smart people working in a new problem domain may register an significant uptick in bugs - doesn't mean that they're incompetent, it's just the result of doing new stuff in an unfamiliar domain in a highly complex environment. Lines of code? The less said about that metric and how gameable it is, the better. Us still being craftspeople is also why we can command such high wages relative to the rest of the economy - what we do is not yet automated, so we can still draw a premium.

noobiemcfoob 7y ago
> it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use? I think your criticism of 'at-will' employment is unfounded in this scenario. Having lower guardrails on employment means it's not as pressing to figure out performance metrics. If the company narrative is that an employee is helpful to the mission, then there isn't much cause to fret for a more perfect metric. And at-will means you can test more employees before committing to a few for longer than a couple years.
- CraigJPerry 7y ago
  > I think your criticism of 'at-will' employment There was no criticism of at-will employment in the parent post. That's a hair trigger you've got yourself there fella.
  - noobiemcfoob 7y ago
    > In my country, which (thankfully) lacks America's "at-will" employment contract I'm sorry, is that not obviously criticism? My parser must be busted again.

mrkeen 7y ago

Martin Fowler: "Architecture is hard to define, but I'll try. Good architecture allows the system to evolve. Bad architecture attracts cruft and makes change hard." HN: "Fuck this ivory tower bullshit! Where's the evidence?!?!"

aklemm 7y ago
Exactly. In fact, this thread looks like people cargo-culting what it means to be evidence-based (hint: life and work will always contain some reasoning and craft).
- TeMPOraL 7y ago
  At this point it seems that there's more comments that start by saying "OMG HN is so negative about Fowler" than there are comments actually doing this. I have this working hypothesis that HN is a nexus where multiple alternative realities intersect, which is why I sometimes find threads with 5 comments complaining about HN negativity to one or zero comments that are actually negative...
  - aklemm 7y ago
    Well, the cavalry comes in and soon outweighs the misguided negativity...at least in this thread. The negative comments were definitely outstanding.
mjburgess 7y ago
My objection is the "ivory-tower bullshit" is wrong. He goes to pains to fail to define architecture and rejects a reasonable definition for a confused genetic fallacy about social construction. "Architecture" isn't understanding. Understanding is of Architecture. If architecture were merely "the common understanding of what's important" there could be no disagreement or understanding of the software. Disagreement would be hopelessly social: you could never say "this is too complex", but only, "your understanding is wrong". > "My view is that applications are a social construction" Deeply confuses many issues. Applications are made by people, as are tables, but neither are "social constructs" -- which mean they are irreducibly subjective group phenomenon. Software runs on machines. The running machine isn't a subjective group phenomenon. "1 + 2" is code, mathematics isn't a "social construct". "Architecture" refers to the structural elements of a domain (ie., how the domain objects are related to each other, and how these relations are related to each other, etc.). It is a relative term, but not a subjective one. eg., The "architecture" of a animal is how its parts fit together. The "architecture" of a leg is its pieces fit together. And so on.

Ozzie_osman 7y ago

Lots of hate in this thread.. People asking for proof: what sort of evidence would convince you? I take these blog posts, apply it to my experience, and take what I think makes sense. Sometimes, an idea will solve an obvious pain I've had. Sometimes, an idea will show me a pain I didn't know I have. Sometimes I disagree with the idea because it won't work for me. That's fine. I'm still much better off thanks to this literature, and I would be worse off if it all had to be evidence-based. If you think you can write better based on your experience, please go for it. I'd love to have more literature to read, analyze, and learn from. If you can't (pressed for time, etc), and only have time to post in HN comment threads, then at least discuss concretely which parts you disagree with so we can learn from that too (I'm serious, not being facetious). If you can't even do THAT, then sorry, all your valuable experience is way less useful than someone like Martin Fowler, because I'm not learning anything from you. Having a good understanding of how to architect code is hard. Being able to write about that in a way that's useful for others is even harder, and is a skill of its own. So personally, I thank Martin & Co for all their writing.

deleted 7y ago
[deleted]
vikingcaffiene 7y ago
Thanks for this. The initial wave of hate on this post had me worrying that we are collectively forgetting the lessons of the past. This industry continually re-invents the same concepts over and over again and just re-brands them. Once you recognize that, the writings of Fowler & Co become highly applicable to many scenarios.
- sidlls 7y ago
  Is this because what they've written truly works or is it because they've simply managed the same thing as the loudest engineer in the office, at larger scale?
  - vikingcaffiene 7y ago
    Well HN knows a thing or two about the latter ;) It’s because I write better software in a team setting when I apply the techniques and philosophies of Fowler & Co. The biggest complexity in software is people. Coordinating them, navigating egos, and leveraging their experience levels. It’s a hard problem and the place where I see the most consistent system problems. IMO Fowler is just providing accessible common sense strategies for dealing with that complexity.

karmakaze 7y ago

Let's talk about any good parts. The architecture of systems varies enough that there isn't a good concrete definition. An aspect that's important for one system isn't for another so it's hard to say which aspects are part of an architecture. Unless you're always architecting the same types of systems, this will carry some weight. The other idea that architecture is present but not visible is a great one. It's the important bits that are underlying or overarching or otherwise permeates the system without necessarily being separately visible. I've had so many difficult chats talking past one another about different levels of concern. When one side only sees what's named or in the diffs, it's hard to convey why something else is more important when there's a lack of 'shared understanding'. I did have this experience when I was making a relay service which handled a headless browser and audio streams. Each of these ended up using a state machine so I separated the state machine mechanics and implemented each using it. The result ended up having many state machine visible parts than the interesting (for the use-case) non-state-machine parts. I undid all that and made each back to primarily do its job as a state-machine but it was far less visible. This isn't the best of examples but it's one where I learned that sometimes you want things to be less invisible even when it's important.

vikingcaffiene 7y ago

I gotta say I am surprised and a little disheartened by all the negativity around this post and Fowler in general. Fowler's writing has been a huge inspiration to me in my career. I'm about to gift a copy of his book "Refactoring" to one of the junior engineers I work with for instance. I think the idea of an architecture as a social construct is very fitting. Software is hard when multiple people are working on it with differing backgrounds and experience. Having a rough outline (emphasis on rough here) of "what lives where" and "what is allowed to talk to what" is absolutely critical IMO. It's how your team can effectively reason about a system and add new features to it. It should also be a living thing in that it's something that is continually refined, discussed, and changed as the needs of the business change. Done right, its an organic process that really helps deliver more robust software that everyone involved has a high level understanding of. Contrast that with an Architecture (capital A) done in Enterprise which delivers a static artifact that does not allow for any creativity and micromanages every aspect of it. It's split off into chunks and no one without an expert level of knowledge can easily understand it. That kind of design will almost certainly fall over the first time there needs to be a change to it. It's important to point out the difference because that is NOT what Fowler is recommending in his writings.

wpietri 7y ago
Totally. In a side room at Java One in 1999 or 2000 I saw Fowler talking about Refactoring, and he happened to bring Kent Beck up on stage to talk a bit. If I hadn't been exposed to their ideas, I surely would have left software by now. Over and over, my experience was building something that slowly got less tractable over time, where eventually we'd just want to do a big rewrite. It sucked! I had tried the big-design-up-front approach, where I thought real hard for a long time before building. That might push out the rewrite date some, but definitely not forever. It was dispiriting, a slow, sticky death. That combined with crunches and burnout was slowly making me hate something I had loved doing. But their main point was that code bases didn't have to end in an entropic snarl. That with decent tests and a little elbow grease, code could get better organized every time we touched it. That instead of death by papercut, we could make things a little better every day. Better for the users, better for the business, better for the developers. They weren't promoting silver architecture bullets. They were saying that we should trust and empower teams to figure it out. That if we gave them room and tools to figure it out, everybody would end up happier. It made a huge difference in my life, so it's weird to see people here aggressively putting words in Fowler's mouth, words that seem entirely at odds with my experience of him and his work.

Kortaggio 7y ago

The author's statement that "My view is that applications are a social construction" I think hints at a deeper truth, that while _code_ is run by machines, managing a _codebase_ is more like raising a plant in a garden and not like changing the oil in a machine. Reminds me of "A Codebase is An Organism"[1]. [1] https://meltingasphalt.com/a-codebase-is-an-organism/ https://meltingasphalt.com/a-codebase-is-an-organism/

dredmorbius 7y ago
See also: Conway's Law. http://melconway.com/Home/Conways_Law.html http://melconway.com/Home/Conways_Law.html

eddieh 7y ago

Would it help if instead of software "architecture," we called in software "organization?" It seems like nobody would demand "proof" if Martin was arguing that it is faster and easier to find a book in a library than it is to find a book at the dump.

jeffdavis 7y ago

Architecture is your chance to decide which problems will be easy and which problems will be hard. In a microservice architecture, failure handling is easy. State management is hard. In a centralized database architecture, failure handling is hard. State management is easy.

ris 7y ago
> In a microservice architecture, failure handling is easy I'm not sure I would agree with this - it's still incredibly hard to be able to make the rest of your architecture do something useful when a significant part of it goes away. Multiply the possibility of one of your important services going down by the number of important services you have...

neya 7y ago

People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my company. I follow Martin Fowlers' articles on using DDD (Domain Driven Design) and Microservices to architect applications. What should have been a month long project took us 8 months! I'm not including the time I took to read about, understand and practice DDD and the surrounding concepts. Every DDD book is atleast 500 pages or more. And none of them are clear on the concepts, and are mostly full of fluff. To give you more details, our stack was based on Phoenix, but it used a concept called Umbrella applications (basically Micro services pattern). Along the way, I hit so many snags and I thought I must be doing it wrong. Because, that's what these authors kept saying all the time to people who had failed to implement their preachings. So, I met a couple of people who had actually done this DDD on a much larger scale than I had and even they shared the same experience and stories of failure and struggling. Still, I shrugged them off thinking it must be something we were doing wrong instead of DDD/Fowler's teachings itself. In the meantime, we were struggling to launch features for our E-Commerce software because our microservices architecture based on DDD was just a house of cards at this point. And then, I finally called up someone I knew who had done DDD successfully and asked him how he did it. He said one of the authors of a popular DDD related website, had offered to consult for his company. And they had no choice but to employ him because they were pretty invested at this point. After a while, I started meeting a bunch of such companies who got their DDD setup done by either authors or by some vendor these authors had a stake in. And then BINGO, it all made sense - most of these patterns/shortcuts/discoveries/secret sauces by these authors are hardly tested by them. It's just a way to sell you more consulting and training. A couple of weeks later, we hosted a casual meetup for tech talks in our area and we got to meet more folks who had followed the same path and failed. We finally decided to do a small hackathon over a weekend and get our projects done. In the end, in about 3 days from Fri-Sun, we had got done so much more with a monolithic architecture than we had ever gotten done with DDD and microservices. Today, my platform is in production and is a proud monolithic app and still going strong. It was perhaps the most expensive lesson I've ever learnt, but one that I will remember for a long time.

MiyamotoAkira 7y ago
2015: https://www.martinfowler.com/bliki/MonolithFirst.html https://www.martinfowler.com/bliki/MonolithFirst.html

jeswin 7y ago

I looked at this thread a while back and closed the window, hoping that those early comments don't influence the younger practitioners who are on HN. As someone nearing 40 (mainly doing consulting work around boring business apps for a long time), my view is that Martin Folwer's biggest contribution is indeed the documentation, and defining the vocabulary to enable discussion around frequently encountered (but perhaps mundane) problems in Enterprise Application development. He isn't trying to break new ground, but I'm glad his writings exist. To pick a very random example, here's CQRS defined in an approachable manner[1]. It's a great link to send to a team of 50, out of which quite a few will be fresh out of college. And I am pretty sure Martin Folwer has seen plenty of real world code while he was working at Thoughtworks. The ideas in his writings aren't conceived in some vaccuum. Some of his early writing isn't perhaps as relevant today. For instance, he talks about the flaws of Anemic Domain Model here [2]. Back in the day, many of us tried to enrich the domain model with particular emphasis on reusability. But those things are less relevant in today's heterogeous environments where logic lives across in multiple services (many outside your team's control). So just reading through his site will surface a lot of outdated ideas; but that's helped a lot of companies along the way when we didn't have to aim for web-scale tps. Actually, it might still work for 99% of apps even today. HN tilts towards the experiences of Startups and young founders, but one good lesson to learn early is that we should be more open minded. 1: https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html 2: https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html

Ozzie_osman 7y ago
Your point on vocab is so spot on. Simply identifying something as a pattern and naming it is tremendously valuable. Doing it in a way that's packageable and shareable with others is not easy at all.
- camgunz 7y ago
  Agree, but people tend to stop at Fowler and live it as gospel. There is a profound richness in the different ways to think and talk about computers, engineering, and information science, far more wonderous than any one person can catalog. Read SICP, Knuth, Code Complete, Codd. Hell, just YouTube around. If your vocabulary is prescribed by literally one guy in a fedora, you gotta get out there. Might I suggest Joe Armstrong [1] :) [1] https://youtu.be/lKXe3HUG2l4 https://youtu.be/lKXe3HUG2l4

cliffcrosland 7y ago

Reading an enumeration of architecture options can be helpful, but I've probably found more value in works like Ousterhout's "A Philosophy of Software Design" that cover fundamental design principles. Such principles seem to be applicable no matter the project. I appreciate that Ousterhout tries to support these principles with some data from his own experience (building Tcl, RamCloud where Raft consensus was discovered, etc) and from code reviews of student projects in his design course, but he admits that there is a lack of data about things like design. Sample principles from Ousterhout: * When developing an interface, favor exposing a small number of functions each with deep functionality over exposing a large number of functions each with shallow functionality. For example, favor Unix file I/O interface (open, close, read, write, unlink) over Java file I/O interface (File, FileReader, BufferedReader, FileWriter, BufferedWriter, FileNotFoundException, ... etc.) * When choosing between keeping your code specific and keeping your code general, favor "somewhat" general. For example, instead of exposing "deleteNextCharacter(text, pos), deleteNextWord(text, pos), deleteNextSentence(text, pos)", just expose "delete(text, pos, length)" and let the caller use it how they will.

blub 7y ago
Yes, "A Philosophy of Software Design" is brilliant, precisely because the author supports their statements through the many experiments they performed with students and The fact that they're the author of a well-known piece of software helps, although we should not use this as the main criteria to evaluate a text. Offering at least evidence based on experimentation is essential if we want to move past personality cults and having entire teams work based on what someone wrote on a blog somewhere.
- sriku 7y ago
  I'm wondering whether another factor that might be at play is that as consultants they may not be at liberty to discuss that kind of detail. Barring that, it would be interesting to have Fowler sit in Ousterhout's class, take on an advanced problem and see what they come up with.

goatinaboat 7y ago

The key to understanding Fowler and similar, and Thoughtworks, that the methodology is their product. They sell consulting and training and seminars and conferences and books. If any useful, working software is produced that is at best by sheer coincidence and more likely despite their involvement.

kevindeasis 7y ago

The only thing missing is Martin Fowler having his own vlog

dvlsg 7y ago

His biggest contribution may be the documentation and defining the vocabulary, but when he defines a pattern with a word that has an obvious negative connotation ("anemic"), it feels manipulative. A while ago I was told by members of a separate team that I was writing the core of my javascript application incorrectly. I was following "functional core, imperative shell"[1] and intentionally separating my data from my functions[2]. Specifically, the code was considered to be wrong because it was "anemic", and I was sent a link straight to that 16 year old page about anemic domain models[3]. The suggestion to fix was to add a bunch of mutable state. Don't get me wrong - I still almost always appreciate Martin Fowler's writing, as it's often quite good, including the original post. But I also understand some of the skepticism here. --- 1: https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct... 2: https://softwareengineering.stackexchange.com/q/203077 https://softwareengineering.stackexchange.com/q/203077 3: https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html

charlieflowers 7y ago
I think that's a case of misguided developers with tunnel vision misusing Fowler's material. I have never met Fowler and I'm completely speculating here, but I would bet money he is both well-versed in, and a big fan of, the "functional core, imperative shell" concept when it is a good fit. Devs often get overly dogmatic, and when they do, they often reach for Fowler quotes to back themselves up. But don't blame Fowler for that.
UK-Al05 7y ago
Did you explain that you were following a functional model in your particular app? Traditional OO (Tatical)DDD does involve creating aggregates with mutating state
lonelappde 7y ago
OO vs Functional is a religious debate that will never be solved. It's like Catholics and Protestants. Fowler is from the Church of OO (Smalltalk).

contingencies 7y ago

Head closer to the rocks of chaos rather than suffocating control. But being on that side of the channel still means we have to avoid the rocks, and a way to maximize local decision making in a way that minimizes the real costs involved. - Martin Fowler ... added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup

akayoshi1 7y ago

Lovers gonna love, haters gonna hate.

JBSay 7y ago

I started reading his sample chapter on refactoring and I'm constantly put off by some really rookie mistakes and bad code practices like naming a function after nouns instead of action verbs (e.g. "amountFor" instead of "computeAmount").

tsarquitech 7y ago

We see that Martin Fowler is influenced by Ralph Johnson in deriving for himself a definition of architecture. In particular, there was no objective way to define what was fundamental, or high level And goes on to lean heavily on the idea that ‘application architecture' is a social construct. But I am then left with a thought that if application architecture is a social construct, that means there should be identifiable social characteristics that make-up the application architecture, characteristics that can be further quantified to an acceptable degree, such that they can be defined as fundamental. Taking a step back from Martin’s influence & conclusion, and ask ourselves, “couldn’t software architecture, or architecture in general, be defined by a set of heuristics that lead to objectively defining what is fundamental to a particular context?“ Suppose we create three rules that need to be defined before reaching our conclusion: - context: what scale does the architecture in question reference? - collection of computing elements: what are the computing elements (this can range from machines to software) - connectedness: how are the computing elements connected? For example, in order to determine the architecture of my web scraping local machine setup I would go through the rules: - context: a single script file with code written to accomplish the task - collection: functions that are used to perform the task of scraping the webpage - connectedness: functions pass data to other functions to perform specific tasks of scraping In this example we have a guide to achieve objectively what is fundamental to our architecture.