Using code is bad

MetaDreamy
4 min readFeb 15, 2019

--

As you begin to educate yourself about good code design, much of the information out there will directly or indirectly imply that dependencies and coupling are bad. Many techniques are promoted for removing dependencies or removing tight coupling between them. But I find it strange that almost nobody is questioning this as a belief. Are dependencies bad? The entire notion falls apart with a little contemplation about what dependencies actually are, why we naturally write code with lots of them, and what our code would be like without them.

Dependencies are everywhere in code. Often one class depends upon another. But when we say that class A “depends” on class B, what are we really saying? Aren’t we really saying that class A “uses” class B? So reuse, or even use, creates, or is, dependency. Code without dependencies can’t do anything at all. Even the simplest of code is using or depending upon some core data type or operation the language exposes.

But wait, if code reuse is dependency, and dependencies are bad, then isn’t that saying code reuse is bad? But isn’t the point of writing code to use it? And if you only use code in one place, and there is no reuse, then every concept has to be completely re-implemented everywhere it is used. Then you are not really taking advantage of the fact that computers are just that, automated computing machines, and we are the programmers that know how to take full advantage of that.

There is a related growing trend of people promoting the idea that we typically don’t want to make much of our code reusable because of the dangers of code reuse. Okay, so we should intelligently design our classes, functions, libraries, etc, in order to… not use them? It is even promoted that you don’t want code to have too many dependencies because that makes it hard to reuse your code! They are saying we should not reuse code in order for code to be reusable! That would mean that even if we managed to write some reusable code, we shouldn’t actually reuse it, because that would make the code that is reusing it not reusable.

Dependence is really just another word for use. If you are writing something down using a pencil, you are depending on it. If it breaks, stops being able to write, or gets lost, you will have to find a replacement or repair it. I used, or depended upon my computer to write this article. So I’m not going to use the word “dependency” in this article anymore. I’m going to say what we actually mean, “use”, and its’ different forms.

We have it all backwards. We don’t want to remove, weaken, or break code “use”, we want to embrace it. Don’t stop “using” your code! Find readable ways to remove bad types of duplication through code “reuse”. The tighter the coupling is where code gets “reused”, the more readable, lookupable, and easy to reason about it will be. The better designed and generally useful a class is, the more places you will want to “use” it. The more loose that coupling is (where you reuse it), the more bloated and convoluted that code will be.

Avoiding code “use” is evil, in the same sense that code comments are evil. Both code comments and avoiding “reuse” are at times the lesser of two evils that serves a practical purpose, but they do make the code worse than if you managed to achieve the same goals without them.

I’m not saying that all forms of code “use” are automatically good. Just like you wouldn’t want to have extra methods in a class that are never actually used, or extra properties that are not used, you also don’t want to have randomly “reused” code that is only making things more confusing. But you also should not actively avoid code “use”. Don’t add a layer of indirection before there is a “use” for it. To the extent that our tests, tools, languages, processes, and techniques are making natural code “reuse” have negative side effects, rather than pointing the finger at “use”, we should be looking at what is wrong with those tests, tools, languages, processes, and techniques that they turn something fundamentally good into a burden.

A big shout out to James Coplien for inspiring much of what I wrote here with his talks. He also talks about similar topics, saying things like, “coupling is what makes our systems systems, and it’s a good thing” (from his “The Straight Line is Ungodly” keynote at the Models 2016 conference). I have learned much more from watching his talks than trying to read what he has written. So far he is the only person I have found who can disagree with Uncle Bob (Robert C Martin) without sounding like those disagreements are the result of a shallow mind.

Write code so “use”ful that yourself, other programmers, and end “user”s, will be begging to “use” it.

--

--