[HN Gopher] Big Ball of Mud (1999)
___________________________________________________________________
Big Ball of Mud (1999)
Author : signa11
Score : 86 points
Date : 2021-10-19 08:02 UTC (15 hours ago)
(HTM) web link (laputan.org)
(TXT) w3m dump (laputan.org)
| jasonhansel wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| The product works and the usual line of thought is "if it
| ain't broke, don't fix it or we'll be broke".
| osullivj wrote:
| 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.
| gmfawcett wrote:
| 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.
| jcun4128 wrote:
| > repeated expedient repair
|
| Haha damn I know about that
| dgb23 wrote:
| 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
| sovietmudkipz wrote:
| 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.
| Jtsummers wrote:
| 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.
| dgb23 wrote:
| > Quoting from the discussion at the end that GP apparently
| failed to read
|
| What implies that? The quote I gave hints at exactly the
| stuff you are discussing here.
| Jtsummers wrote:
| Your "Well it turns out..." part is what threw off my
| reading of your comment. That turn of phrase is usually
| meant to imply that the preceding is, in some way, bogus.
| If that's not what you intended, I apologize. But it's
| how it reads to me.
|
| Under that reading, it really seems you stopped at that
| point in the text and didn't continue to where the
| authors talk about why stopping at that point in the
| program development is problematic and how to correct it
| (the later sections).
| dgb23 wrote:
| Oops, english is not my first language. I wanted to imply
| that they were onto something. Not quite radical enough
| in hindsight, so I wanted to emphasize that.
| Jtsummers wrote:
| My apologies then.
| dgb23 wrote:
| > But what would have to be true in a student to be able to
| "know" this back then?
|
| By studying! A hint is right there at the end of the quote I
| provided:
|
| > 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
|
| This implies that the common approach at the time in OO
| introduced too much unnecessary coupling. And at the time and
| before that, there were already approaches being explored
| that avoided this in some way or another.
|
| Another way is to just as basic questions: What does this try
| to achieve? What problem does it solve? Why do they think it
| is a problem? How is it implemented? Can this be
| achieved/solved with a different implementation? Can this be
| achieved by removing something, like an assumption/perceived
| requirement or dependency?
|
| Here is a simple example for illustration:
|
| JavaScript at some point introduced syntax for classes. A
| relatively common "compiles to JS" language was CoffeeScript
| at the time, which had classes.
|
| Ask some of the questions above and others about this change.
|
| For me the reasoning for this was never really compelling. In
| JS you can introduce objects on the fly, you have first class
| functions, real closures. The only reasons I can think of for
| this was familiarity or other cultural ones.
|
| Another one:
|
| I've been reading and learning more about SQL lately. Trying
| out different types of modelling, playing with advanced
| features and so on.
|
| Naturally I want to get some kind of overview and look up
| stuff on the web. I read "anti pattern"-this and "you should
| do"-that. First, I was confused and started to second guess
| myself. But in the end I got it: Most of this stuff is
| written by people who just happen to work with a certain
| mindset and with certain types of tooling. For them these
| guidelines make sense, for me? It depends...
|
| In the end it's very cultural. The tools people use, the
| environment they work in and the types of problems they have
| to solve all shape the way they think and communicate.
|
| And this is especially pronounced for the academic types, or
| the people who mostly write documents and little code.
| aryehof wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| That's what teachers typically say too. At least the
| one's I respected most.
| raldi wrote:
| This also reads like social commentary :)
| mpweiher wrote:
| ...it turns out he was right.
| greenail wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-19 23:02 UTC)