Big Ball of Mud (1999) | Hacker News Reader

Big Ball of Mud (1999)

laputan.org

90 pointssigna1123 comments

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

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.

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.

The product works and the usual line of thought is ”if it ain’t broke, don’t fix it or we’ll be broke”.

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.

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.

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

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.

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

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.

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

That’s what teachers typically say too. At least the one’s I respected most.

This also reads like social commentary :)

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.

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

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).

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.

My apologies then.

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

...it turns out he was right.

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.

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.

> repeated expedient repair

Haha damn I know about that

Reply on news.ycombinator.com