Smaller source code

Let's assume that you have decided to reduce the size of your source code. (The code geeks have convinced you that smaller code has fewer defects and is therefore higher quality and less expensive to maintain.)

If you're a programmer, you have several choices. There are a number of strategies to reduce the size of your source code.

1) Write code that is more efficient, or re-write existing code to reduce its size. In C++ programs, I often see code that has multiple levels of content in a single function. I've seen code that performs high-level business logic and also allocates memory or checks that a string object (or CString object) holding a path name has a trailing backslash. Not only does shifting between high-level and low-level contexts cause more code, it requires much more attention from the programmer.

2) Combine similar or duplicate sections into a single function or class. I've seen many systems with duplicate or near-duplicate code. The big risk of duplicate code is that changes will be made in some sections but not all of the duplicate sections. Consolidating code reduces the code size and prevents future problems.

3) Use a different programming language. I can write a program more efficiently in C++ than in C, and more efficiently in Java than in C++. Languages that are more expressive result in smaller programs. (This works for programs over a certain size. The traditional "hello world" program is shorter in C than in Java, but Java scales better than C.)

If you're a manager, you can also reduce the size of your code. You must do it indirectly, since you're not working on the code but directing the people who do work on the code.

1) Ask (or exhort, or demand) that your team write less code. A risky proposition, since you are judging the performance of your programmers, and they are quite touchy about such things. At best they will ask you "which portion of the system would you like to remove?" and at worst they will quietly start goofing off.

2) Reduce the size of the programming team.

This last idea may seem a bit strange. If you use the common "man-hours" approach to planning, less staff means that you have less "capacity" -- less ability to produce functionality. The "man-hours" approach does not take into account the size of the code, or the communications load on the team.

A smaller team can operate more quickly. It is easier to come to consensus. There are fewer meetings. There are fewer disagreements. There are fewer chances for mis-communication.

A smaller team has more freedom to reduce the code base (without reducing functionality). They can combine functions and do the things listed above in the "programmer" options. There are fewer people to object, fewer people who will become confused when code modules change.

"Too many cooks spoil the broth", goes the old saying. It's true, for broth and for programs.

Don't spoil your broth.