8 ms·

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 t

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