One of the most misunderstood areas by software organizations is how to properly manage developers. As a result, the common wisdom in many companies is that developers need to be managed for performance. And since performance in creative endeavors is really difficult to quantify, this is frequently measured using a meaningless metric, such as number of lines of code, number of function points, or even number of bugs fixed.

The big mistake is that, far from being a repetitive task at which one needs just to devote more time, software writing is a creative endeavor. Also, beyond the initial assumptions, software is an engineering artifact. That artifact is created by one developer but becomes the foundation that will be used by many others.

The main condition that a developer needs in order to create good software is the intellectual freedom to decide what is good or not. For example, it is imperative that at least one developer be entitled with making architectural decisions on a piece of software. The ideal would be to have everyone involved as soon as possible on architectural decisions.

On the other hand, one of the worst things that can happen to a team of developers is having somebody else deciding what should be technical issues based only on business goals.

For example, requiring that a group of developers use a specific technology based only on its cost may be a really bad decision, because it can have repercussions that will cost much more than the intended savings. In general, if a company has technical people and if they are any good, it should leave technical decisions to them.

Many companies shoot themselves on the foot by having smart people on board and not letting them making the technical decisions. When this happens, these company will lose twice. They will regret the decision made on purely non-technical basis (even though most managers won’t know what hit them). But they will also lose engineering talent — talented people don’t want to work in such an environment.

Without intellectual freedom, writing software is nothing more than fighting the programming environment. If a developers can’t make something better, he or she is basically required to keep doing the same mistakes over and over again.

Sometimes, worse is better. As strange as it may look, having something that is not perfect may be better than spending the time to make it perfect. This happens in many areas, and its the main reason perfectionists never get any work done. If the expectation is for perfection, then it is really hard to complete anything, because most of what we do is imperfect by necessity.

In software, however, there is an extra dimension to this problem. Because, the closer to perfection we get in a software application (in terms of features) the more code needs to be written and maintained. More code also means more bugs, which have the power to move us even further away from perfection.

Given the complexity of writing perfect software, it is just better to admit that we can’t write perfect programs. Instead, a more attainable goal is to write the minimum necessary to satisfy our requirements, while maintaining a good control of the overall design.

Writing as few code as possible has several advantages that contribute to the quality of the resulting programs:

It is easier to test: every extra line of code is a new place where errors may be hiding. Why increasing that chance? Just write as few lines as you can and avoid potential problems.

Avoid unnecessary repetitions: a guiding principle of programming is the DRY method: Don’t Repeat Yourself. While trying to write as few code as possible you will see more opportunities to avoid unnecessary repetitions.

Performance: usually, less code leads to better performance. This is particularly true for modern software, where one of the main limitations is processor cache size (as opposed to main memory size). Small programs that solve the problem without requiring huge class libraries may have a big advantage in the performance arena.

It is not always easy to write small programs though. Remember the old saying: “I wrote a large book because I didn’t have the time to make it small”… The same apply to programs. It is sometimes easier to copy and paste previous code, or code that was mindlessly taken from some other project or from the web. It is harder to think about the overall problem and adapt the code to your situation.

What about making it fast? Well, it turns out that making programs fast is more a matter of design than of good programming skills. It is futile to change a program to yield better performance if the structure of the program is not created with this in mind. And once you get the big picture of the software design, getting small improvements in speed is not that interesting. There are exceptions to this rule; for example, video games can use small speed gains to give much improved user experience.

So, you see that writing small programs has a lot of virtues. And, despite this, it is a difficult task, because it requires a lot of thinking in advance. Developers are most of the time pressed to think less and finish more lines of code. But it pays the time to look for good solutions before you enter code into your preferred IDE.

The sam editor is a text editor written by some of the same people that created UNIX, including Ken Thompson and Bob Pike. Many of them worked previously on the AT&T Labs (the lab has mostly been disbanded, but many of these guys still work for other companies).

The sam editor provides many of the same features found on a previous editor, called ed (also known as the standard UNIX editor).

If you know enough about UNIX to understand what ed is, you may be asking me: why are people still bothering with concepts related to a line oriented editor? This is a program that was superseded decades ago by vi, wasn’t it? (In fact, I know that the Emacs crowd will additionally say that Emacs superseded vi, to which I reply that vim superseded Emacs…)

But the truth is, for old fashioned as ed may be, it still has some ideas that are interesting exploring. First, ed was born at a time when there was no easy way to interact with a screen of text. Therefore, it had to create a mini-language that allowed people to efficiently enter text without a mouse or other form or cursor.

For example, using ed one can easily say: go to the next line (in a C source file) that has a declaration of an integer, and add a new variable at the end of the line.

For the ones among you that never tried this, here are the commands:

/int
s/;/, newVar;/

Here is what this means: “/int ” will search for a line that has the “int” keyword on it (notice that I added a blank after “int”). Then, substitute the character “;” by the sequence “, newVar;”.

Effectively, the previous commands use search and replace to edit text.

If you use vi, you will notice that several of these commands have resemblance on existing vi commands. That is because vi was designed as a full screen version of ed. For example, the file access operations are still the same. Also, virtually all commands supported by ed can be accessed in the so-called “ex” mode (ex is usually just another name for ed).

For users experienced in ed, one advantage of using it is that there is no need to use anything other than the keyboard. Also, movements are done by search patterns or direct line references, which are typically much faster than using a mouse (or arrow keys, for that matter).

Of course, there is something missing in ed, which is the possibility of seeing the whole file. You can always use an external program, such as more (or less), but this is somewhat awkward.

The sam editor takes the concept of ed one step further, but in a different direction than vi. It also provides a graphical UI, but instead of relying on two modes of operations as vi, sam provides an improved set of commands to ed, along with a way of entering and viewing the results of these commands.

The result is an editor that is refreshingly different, while providing the same power of the commands available in vi and ed. For advanced users, sam may be an additional tool that can be used whenever the strong features of the editor are required.

Of course, sam is the main editor for plan9, so people using it are already used to the conciseness of sam. There is just a small set of commands, which can be learned in a few hours. The combination of these commands is what provides the flexibility of its approach.

The UI is divided into a number of windows. One of them is the command window, where editing commands are typed. The interesting thing is that the command buffer has all the features of a normal window, like autoindent, for example. Thus, adding and editing text through the command window is as comfortable as using any other editor window.

Although sam provides a lot of nice features, it is not as widely used as Vim or Emacs. Therefore, it has some rough spots, specially in the UI (the most GUI (the most difficult part to get right). The fact that it was developed for plan9, instead of UNIX, also brings some difficulties. However, despite these issues I

However, despite these issues, I have found sam to be very easy to learn and use. It has already become one of my favorite text editors.

Further Reading

Inferno Programming with Limbo is an introduction to the main operating system based on plan9. It will give you some idea of what the environment is, and why it is radically different from other OSs.

Learning the UNIX OS talks about several original UNIX commands, including ed.