Programmer Musings

LCDC: Business Logic

In The Myth of Code Anyone Can Read, I introduced the idea that least common denominator code (LCDC) is not a goal anyone should aim for. Despite my assertion, I've seen a number of places where I have seen this as a requirement.

Even if you don't believe any of the other reasons for code to not cater to the lowest common denominator, there is one reason that you can't really ignore.

Business-specific Knowledge

Your particular company or project embodies knowledge that is not universally known. If it didn't, your code would not be worth much, because anyone could reproduce it on demand. As such, a novice walking in off the street will never understand all of your code. They don't have the context to understand it. Often, the logic that makes up the business decisions that the code needs to make are written into your system. There are functions, objects, and algorithms that are particular to your business. There are particular ways of using these fundamental parts to do work that has value to your users.

Terminology

All of this means that there are idioms, terminology, and approaches in your code that novices or really junior people won't understand. Some of this terminology may qualify as jargon. This just means that there are terms that mean something particular in your business that people from another industry or possibly even company may not understand. One of these jargon terms may be a short-cut to an entire paragraph of context. Novices or people from outside your company are likely not to recognize any jargon used inside the code.

If you try to re-write the code so that they can, it will become a morass of low-level details that make any higher-level understanding impossible. Randall Munroe gave us a wonderful example of what happens when you don't use specialized terms in xkcd: Up Goer Five.

Summary

Obviously, you want any code written for your project to be specialized for your business. You expect over time, your developers will learn more about your business. Obviously, that knowledge should be reflected in the code. This insights into your business is what makes your developers able to write code specific to your business.

Next time, we'll explore a specific case why LCDC might be useful for parts of your project.

LCDC: Developer Specialization

In The Myth of Code Anyone Can Read, I introduced the idea that least common denominator code (LCDC) is not a good approach to writing software. Among other things, this approach ignores programmer specialization that happens in any team of more than two developers.

Mental Caching

As a project becomes larger than one person can comfortably keep in their head, maintenance becomes more difficult. A developer has to spend some time re-familiarizing themselves with part of the code before they can do any serious work on it.

Depending on how recently they looked at the code, the developer could take almost no time or several hours re-learning the important parts of the code. (If you think the latter is unreasonable, I've been in code bases where we worked on a bug in code that had not been touched in almost 10 years. It takes a while to get up to speed on that.)

Since most programmers don't want to waste time, they tend to specialize somewhat in the code that they work on. This means that anything in that part of the code they can work on without spending a lot of time remembering or re-learning the code. This happens naturally. After finishing working on a bug or feature in the foo subsystem, they look for another bug or feature in the same system. After all, they are already familiar with it.

As this continues, that developer becomes the fastest person to work on that subsystem, and so bugs and features in that area tend to go to them, naturally.

The Specialist

When you think of development specialists, you probably normally think of someone like a database or UI developer. But, other specializations tend to happen pretty naturally. Watch who works on bugs in which area. See who people ask when they need to work in an area they don't know. Does everyone defer to Nancy on network issues? Is Fred the expert on the logging system? Do we put off working on the reporting framework when Robert is on vacation?

These people have become specialists. They are normally most effective in their area of specialization. Some may still be pretty good in other areas.

Effects of Specialization

As someone becomes more and more familiar with one area of the code, they tend to develop short-cuts and patterns that reduce potential bugs and make the developer more efficient. They may develop a specific metaphor that only applies to this part of the code. They develop jargon terms that supply a lot of context when they see them in the code. These are part of what makes them effective.

Forcing the specialist to write code in a way that everyone can understand would severely limit their effectiveness. They would have no shortcuts to remind them of the patterns they have seen in code. Instead of the code becoming tighter and more focused, it would tend to be more unfocused.

You might think I'm being overly pessimistic here. But, I have actually seen this happen. When a new person takes over the code when a specialist leaves (or is promoted), they tend to undo all of the specializations that they don't understand. The code normally slows down and develops new bugs.

This points to one of the major problems with having specialists. They reduce the project's Bus factor. This problem is relatively easy to solve. Have at least one other developer work with your specialist some of the time in their code to learn the context before it is critical. The second developer does not need to become as much of an expert in that part of the code, but they should be able to understand the thinking that went into it.

Summary

If you have more than one developer on your team, specialization is pretty much inevitable. In general, that is a good thing. Deeper knowledge in a particular area is likely to produce serious benefits over the life of the project. Along with that deeper knowledge will come patterns and idioms that are very specific to the target code. Mandating these patterns and idioms away will destroy the benefits of having a specialist.

In the next post, I'll discuss a kind of specialization that is critical to your project and you can't mandate away.