6 ms·

Big Ball of Mud (1999)

90 points by signa11 5y ago

gmfawcett 5y ago
A classic. It contains the best definition of system architecture that I've ever come across: > Architecture is a hypothesis about the future that holds that subsequent change will be confined to that part of the design space encompassed by that architecture.
osullivj 5y ago
A classic from the early days of the patterns movement. IIRC the authors originated the anti=patterns concept. Still seeing this in production environments today.
dgb23 5y ago
From a linked paper[0]: > In object-oriented programs, inheritance is a powerful and useful mechanism for sharing functionality among objects. Placing new code in subclasses can help maintain design integrity, because changes are isolated in these subclass, and the original code in the superclasses remains intact. > Objects can evolve more gracefully than can traditional functions or procedures because exploratory changes can be confined to subclasses. Such changes are less potentially disruptive to existing code that depends on a component. > What often results from the expansion phase is a class hierarchy that models a history of changes. > The resulting subclasses are not yet truly general. More desirable, from a software maintenance standpoint, would be an inheritance hierarchy that models a type hierarchy Well it turns out... [0] http://laputan.org/lifecycle/lifecycle.html http://laputan.org/lifecycle/lifecycle.html
- sovietmudkipz 5y ago
  When I’m in student mode, I do think to myself “how much of what I’m reading/hearing is from direct observation and thought, and how much is (conveniently) not as well considered?” I read authoritative stuff such as what is highlighted in parent comment all the time in my studies. It makes sense, since that’s the voice we expect educators in info sharing contexts to have. But like… We “know” today that inheritance leads to bad outcomes… But what would have to be true in a student to be able to “know” this back then? To ask differently, what am I learning today that will be seen as a mistake over time? I’ve learned over time to listen when being educated and be very critical when attempting to integrate knowledge.
  - aryehof 5y ago
    > We “know” today that inheritance leads to bad outcomes… Inheritance used inappropriately likely leads to bad outcomes. Knowing when that is the case makes one a good programmer, not popular opinion.
    - gmfawcett 5y ago
      You're missing the point. He's wondering how a student would assess this, not an experienced programmer. A student generally assumes that their instructor's opinion is informed.
      - voakbasda 5y ago
        > A student generally assumes that their instructor's opinion is informed. The first thing a student should learn is that teachers are not infallible. Question authority. Doubt everything.
        dgb23 5y ago
        That’s what teachers typically say too. At least the one’s I respected most.
    - raldi 5y ago
      This also reads like social commentary :)
  - Jtsummers 5y ago
    Hopefully a good student wouldn't stop listening at that point, because the rest of the linked paper describes how to clean things up precisely because an overdependence on inheritance can create bad outcomes. Quoting from the discussion at the end that GP apparently failed to read: > In our aggregation pattern we discuss how inheritance is overused and sometimes is incorrectly used. Our pattern addresses how to fix one common misuse of inheritance - but in proposing this pattern, are we (improperly) encouraging an undisciplined use of inheritance, with the idea that one can "fix things later"? We think not. As noted earlier, "is-a" relationships are not always clearly distinct from "has-a" relationships. Points of view change over time, which does not imply that the original use on inheritance was incorrect. In fact, they're addressing your concern in their own document! Does encouraging early use of inheritance with the intent to refactor later (when you actually know what you're building) cause problems? They don't think so, but that's an opinion born (presumably) from their own experience. Yours may be different, mine hasn't been. Their discussed model has you (somewhat) abuse inheritance early, while prototyping, and then lists several ways to change the structure of the program once you properly understand the model you're implementing.
- mpweiher 5y ago
  ...it turns out he was right.
jasonhansel 5y ago
> The SHEARING LAYERS that develop between them are like fault lines or facets that help foster the emergence of enduring abstractions. Very wise. All too often, people try to come up with abstractions at the start of a project, when the only real way to find the "right" abstractions is to discover the natural fault lines during the development process.
- codr7 5y ago
  Word! But very difficult to pull off in a team, because the less enlightened will always try to nail everything to the floor asap and judge you for not playing along.
  - jasonhansel 5y ago
    And then, when you go back to add the abstractions, they'll say you're "wasting time refactoring," ignoring the time saved at the start of the process.
    - eurasiantiger 5y ago
      The product works and the usual line of thought is ”if it ain’t broke, don’t fix it or we’ll be broke”.
      - codr7 5y ago
        Which I suspect is part of the reason for trying so hard to get it perfect on the first try despite plenty of proof that it just doesn't work. I had high hopes for XP, but it turned into Sc(r)um.
greenail 5y ago
Charlie Bell would describe Amazon's Obidos as a "big ball of mud". I had thought he came up with that description. It is a good way to describe the problem.
jcun4128 5y ago
> repeated expedient repair Haha damn I know about that

90 points by signa11 5y ago

A classic. It contains the best definition of system architecture that I've ever come across: > Architecture is a hypothesis about the future that holds that subsequent change will be confined to that part of the design space encompassed by that architecture.

osullivj 5y ago

A classic from the early days of the patterns movement. IIRC the authors originated the anti=patterns concept. Still seeing this in production environments today.

dgb23 5y ago

From a linked paper[0]: > In object-oriented programs, inheritance is a powerful and useful mechanism for sharing functionality among objects. Placing new code in subclasses can help maintain design integrity, because changes are isolated in these subclass, and the original code in the superclasses remains intact. > Objects can evolve more gracefully than can traditional functions or procedures because exploratory changes can be confined to subclasses. Such changes are less potentially disruptive to existing code that depends on a component. > What often results from the expansion phase is a class hierarchy that models a history of changes. > The resulting subclasses are not yet truly general. More desirable, from a software maintenance standpoint, would be an inheritance hierarchy that models a type hierarchy Well it turns out... [0] http://laputan.org/lifecycle/lifecycle.html http://laputan.org/lifecycle/lifecycle.html

sovietmudkipz 5y ago
When I’m in student mode, I do think to myself “how much of what I’m reading/hearing is from direct observation and thought, and how much is (conveniently) not as well considered?” I read authoritative stuff such as what is highlighted in parent comment all the time in my studies. It makes sense, since that’s the voice we expect educators in info sharing contexts to have. But like… We “know” today that inheritance leads to bad outcomes… But what would have to be true in a student to be able to “know” this back then? To ask differently, what am I learning today that will be seen as a mistake over time? I’ve learned over time to listen when being educated and be very critical when attempting to integrate knowledge.
- aryehof 5y ago
  > We “know” today that inheritance leads to bad outcomes… Inheritance used inappropriately likely leads to bad outcomes. Knowing when that is the case makes one a good programmer, not popular opinion.
  - gmfawcett 5y ago
    You're missing the point. He's wondering how a student would assess this, not an experienced programmer. A student generally assumes that their instructor's opinion is informed.
    - voakbasda 5y ago
      > A student generally assumes that their instructor's opinion is informed. The first thing a student should learn is that teachers are not infallible. Question authority. Doubt everything.
      - dgb23 5y ago
        That’s what teachers typically say too. At least the one’s I respected most.
  - raldi 5y ago
    This also reads like social commentary :)
- Jtsummers 5y ago
  Hopefully a good student wouldn't stop listening at that point, because the rest of the linked paper describes how to clean things up precisely because an overdependence on inheritance can create bad outcomes. Quoting from the discussion at the end that GP apparently failed to read: > In our aggregation pattern we discuss how inheritance is overused and sometimes is incorrectly used. Our pattern addresses how to fix one common misuse of inheritance - but in proposing this pattern, are we (improperly) encouraging an undisciplined use of inheritance, with the idea that one can "fix things later"? We think not. As noted earlier, "is-a" relationships are not always clearly distinct from "has-a" relationships. Points of view change over time, which does not imply that the original use on inheritance was incorrect. In fact, they're addressing your concern in their own document! Does encouraging early use of inheritance with the intent to refactor later (when you actually know what you're building) cause problems? They don't think so, but that's an opinion born (presumably) from their own experience. Yours may be different, mine hasn't been. Their discussed model has you (somewhat) abuse inheritance early, while prototyping, and then lists several ways to change the structure of the program once you properly understand the model you're implementing.
mpweiher 5y ago
...it turns out he was right.

jasonhansel 5y ago

> The SHEARING LAYERS that develop between them are like fault lines or facets that help foster the emergence of enduring abstractions. Very wise. All too often, people try to come up with abstractions at the start of a project, when the only real way to find the "right" abstractions is to discover the natural fault lines during the development process.

codr7 5y ago
Word! But very difficult to pull off in a team, because the less enlightened will always try to nail everything to the floor asap and judge you for not playing along.
- jasonhansel 5y ago
  And then, when you go back to add the abstractions, they'll say you're "wasting time refactoring," ignoring the time saved at the start of the process.
  - eurasiantiger 5y ago
    The product works and the usual line of thought is ”if it ain’t broke, don’t fix it or we’ll be broke”.
    - codr7 5y ago
      Which I suspect is part of the reason for trying so hard to get it perfect on the first try despite plenty of proof that it just doesn't work. I had high hopes for XP, but it turned into Sc(r)um.

greenail 5y ago

Charlie Bell would describe Amazon's Obidos as a "big ball of mud". I had thought he came up with that description. It is a good way to describe the problem.

jcun4128 5y ago

> repeated expedient repair Haha damn I know about that