A growing number of types is a canary in the coalĀ mine

By Marcus Lager


When you find yourself in need of seven or eight more types just to implement a single feature, I’m sorry to be the bearer of such bad goods, but listen, your code base, it doesn’t support this story. Instead of implementing it you should refactor with one goal in mind: create a new infrastructure on which you can build your new feature, or any other of your existing features, by using less than seven or eight new types. Also, make it so that the infrastructure is composed of no more than seven or eight types. If you feel impossible about this, then first split up your infrastructure into two. Or four.

Now you’re in a much better place. If you manage to implement seven or eight new features without polluting your code base with an armada of new types, you’re still going to be in a very good place. But take care to notice that one feature and one alone, one day soon, will enter the pipeline and break your code base apart, because it will not be able to support it, because it’s going to be needing refactoring, because there are just too many types and most won’t work together.

A growing number of types is the canary in the coal mine, a signal that you have not built a system that supports the features you want to build. It may have supported you when you implemented all of your old features but what good does that do you now? The old features aren’t what sets you and the rest of the market apart. But the new ones might. Or if they are, then by God make them part of your infrastructure, man!

You should probably not write your code in a way that it takes you more than seven or eight weeks for you to rewrite it, because in order to stick to the plan of always having a code base that supports you, you will need to rewrite often, in fact, very often. But that’s OK, because you have not a single unit test that stands in the way between you and a total remake, a Systems two point O. And you know, locating bugs in a code base composed of seven or eight types if seldom a hard task, in fact it’s very easy. Very easy indeed. Indeed! Because the only code you have to read is your own. The other code base, the one with all the types, it has already been tested. Enjoy the luxury of not being so big of a player that you had to go and invent a new programming language, and leave the testing to them. Use the fact that you are not ahead to your advantage and ride in the back draft of the very biggest of players, the ones that test. Use their speed to gain on them.

Don’t test. Don’t write a single one. Instead, use just seven or eight types to express what it is that you want.

To drive the nail right in there, I’d like to end by paraphrasing the good Oren Eini and say:

If you have more than seven or eight types in your code base, it’s a damn crap fest. In fact, it’s probably totally shit. Stahp it!