Could Encapsulation Be… Bad?

So I was browsing Reddit the other day and I read this post about programming with ‘modules’. This is the idea that you should code everything to be reusable. The OP realized that this caused more problems than it solved. And I echoed this sentiment. The same thing happened to me a long time ago. By putting everything in modules I ended up with clunky code that passed around way too much information for no reason.

So I commented. But then I read the other comments and someone posted a link to this video:

You know there are not many videos, let alone programming videos, that make me think. But this one did. So I decided to write my thoughts and…

So there’s only one option left: write my thoughts here.

What The Video Says

So if you don’t have time to watch the 53 minute long video (27 minutes if you watch at 2x speed) here’s a brief (or maybe not so brief) summary. The video asks if it’s possible to have an unbreakable law in software architecture. The video discusses various possible laws such as a basic law about how fast a program can go given n cores. Then there’s a law about how long a project will take given how many workers work on it. And finally there’s Conway’s law which appears to be the titular ‘unbreakable law’. You can actually read the original paper behind Conway’s law here.

I particularly found this paragraph interesting.

It is possible that a given design activity will not proceed straight through this list. It might conceivably reorganize upon discovery of a new, and obviously superior, design concept; but such an appearance of uncertainty is unflattering, and the very act of voluntarily abandoning a creation is painful and expensive. Of course, from the vantage point of the historian, the process is continually repeating. This point of view has produced the observation that there’s never enough time to do something right, but there’s always enough time to do it over.

*cough* Microsoft *cough*

As for Conway’s law itself it goes like this:

Speaking as a mathematician might, we would say that there is a homomorphism from the linear graph of a system to the linear graph of its design organization.

Or in other words, you can see the signs of how an organization is structured (the organization’s ‘org chart’) in its software’s structure.

Now Conway never says this is bad, only that

It is an article of faith among experienced, system designers that given any system design, someone someday will find a better one to do the same job.

meaning it can be outdated and will have to be updated eventually. Unless you’re Microsoft apparently.

Now back to the video. The video takes this one step further. It says ‘the best you can do is the org chart’ meaning at best the layout of your program will be a 1 to 1 mapping of your org chart. Now this is a point I don’t feel is justified properly. That is not what Conway said. He said that you’d have to update your org chart, not that org charts are bad.

But anyways, the video then talks about how Conway wasn’t thinking about time and when you add time, even if you change the org chart, the legacy stuff still sticks around.

And then the video makes perhaps its most controversial point of all. That programmers are making their own ‘org charts’ using encapsulation and this makes things less efficient. It’s like cargo cult programming. “Well, the big companies are doing it. It must be good.”

Is It Right?

So the video’s arguments can be summarized as the following:

• Org charts make copies of themselves in software
• This is because communication limits what organisations can do
• Programmers have been taught that this limiting is actually good when it isn’t

Which isn’t that bad of an argument. But if you just rearrange the ideas presented in the video you can make something stronger:

• If you accept that org charts are limited in what they can make
• And you accept that org charts must update themselves eventually
• And you accept that the limitations org charts make stay around long after the org chart change
• Then it logically follows that making too detailed of an org chart or using encapsulation too much in the beginning can come back to bite you later

Either way you reach the same idea: encapsulation is actually bad. Or encapsulation where encapsulation isn’t necessary is bad. Because eventually you will have to encapsulate things just so you can understand them. The video talks about this, although it’s talked about in the paper. You need an org chart. You need encapsulation. But encapsulation for the sake of encapsulation…

You know, this actually reminds me of something that’s been bugging me for a long time. The number of languages that want to kill C++. No, actually, that’s a post for another time. This tendency for people to want to encapsulate things before they even need to. It just happened again the other day.

Argh! It just makes me so mad. A modern IDE is basically magic. With only a few button presses it can find all the references, it can rename things, and it can delete and modify things. And yet we’re still in the dark ages of making sure our code works perfectly the first time.

Like, you’re going to rewrite your code eventually. Why do you care so much about not having to touch it in the future? It makes me so mad.

I think this is the idea that Conway originally proposed: that software should be flexible to change. I mean, he originally proposed that org charts should be flexible, but they’re sort of the same thing really. And I don’t think when Conway wrote his essay there were IDEs. Well, at least there weren’t good IDEs. Because IDEs definitely change the game. They make it so you can trivially refactor things.

Premature Encapsulation Is The Root Of All Evil

There’s a famous quote from Donald Knuth that says how premature optimization is the root of all evil. But you should really know the whole quote which I talked about here:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

So what Donald Knuth is saying is that optimization is good, but only if you optimize things that you know need to be optimized. Otherwise it’s a waste of time. Not sure why Knuth said it was the ‘root of all evil’ though. I think he said he was quoting someone else, I guess the bible.

But I think that premature encapsulation is much closer to the root of all evil. Partially because computers are so fast no one optimizes anything anymore. Well, maybe video games where they want to run at 60FPS all the time.

Just like Knuth I don’t think encapsulation is inherently bad. As long as you know you will get a net benefit from applying encapsulation. What is bad is encapsulating everything ‘just because’. Just because someone told you to do it or just because everyone else is doing it. Because doing this can result in hard to debug, clunky code.

If you liked this article be sure to give it a few claps. It helps out a lot with the algorithm.