Code style of old age programmers

It seems that I have the same age as Jeff Atwood, but somehow not, when I read his latest post. Somehow I feel "been there, done that", because I would almost have agreed with him 10 years ago, while still being a freelance programmer, helping out in various programming teams. However, today I'd definitely say that maintainability is much more important than most programmers want to acknowledge.

Most programmers spend most of their time maintaining code, not writing new code. They may spend time on maintaining their own code - but it's still about maintenance. And actually, they spend much more time per SLOC when doing maintenance, than when writing new code. In other words, in order to be really productive, it's the maintenance part that needs to be optimized, unless you're doing a quick and dirty application that nobody is going to use (yeah, right!). The perfect source code is when it works perfectly AND cannot be easier to maintain. This includes simplicity, of course, but it also includes comments, understandable variable names, well defined context and well defined invariants.

When to hide or disable menu items and buttons

I often disagree with Joel, also in his latest post about menu items. Hiding and disabling buttons and menu items is usually done in order to prevent, that the user triggers an event, and it's perfectly ok to do in some cases:

• Hide buttons that the user wouldn't search for. For instance, a non-administrative user doesn't need to see the Admin button.
  
  
• Disable buttons where it is obvious to the user why it isn't clickable. For instance, a well implemented undo functionality doesn't need to have it's menu item enabled before the user starts editing. That would actually confuse some users.
  
  
• In all other cases, make the button visible and enabled, but show a message that explains to the user, why this functionality is currently not available, and what the user can do to make it available.
  

Intentionally add development costs

It is a common misunderstanding, that you can optimize a process to become optimal by optimizing subprocesses.

A good analogy is to find the highest hill by walking around in an environment with 100 meter visibility. If you always try to walk upwards, you may find a local hill. If you go downwards a bit, you may find a bigger hill. There are many good mathematical books on this topic.

When dealing with programmers, it's a bit more complex. However, every time your organization reorganizes itself, you probably experience exactly this: Initially higher costs, but in the long run costs are significantly lower. One reason is, that information is distributed.

In programming, the environment constantly changes. Your organization changes, your customers change, the technology changes. It's like having the hills change height all the time. This is where it is important to pick a hill to stand on. Pick a hill that is one of the highest, but not too far from the other hills. You will find such one easily, if you change hill frequently.

This is what a continuous improvement process is all about. It adds extra costs, but it ensures long term competitiveness.

Using Delphi can be described as being on a hill in a "Delphi" group of hills. Using Java and .net can be described in the same way. Erlang is a very small group of hills. One of the good things about Delphi is, that every time Borland/CodeGear add a new hill, it's close to the previous hills, and not too far from the Microsoft hills. This keeps the costs of continuous improvement down.