The risks of redundant code (or - Less is More)

One of the preferred refactoring methods of my choice is deleting redundant code.

I separate between excessive code and redundant code:

1. Redundant code is code that never runs:

• Unreachable code
• Unused classes, interfaces and methods
• Commented-out code
• Code that looks wrong, then you understand that it is indeed wrong, but is being lucky enough not to be called
• Code that deals with cases that cannot happen
• Code that deals with cases that could happen in the past, but now cannot
• Code that is there for future cases, which are not occuring yet (and may be added sometime)

2. Excessive code is code that runs, but can be reorganized into less lines of code:

• Unnecessary abstractions, unneeded levels of delegations
• Copy-Paste that can be moved to methods, inheritance, templates

Both are bad and should be treated. But the first category, redundant code, is much riskier. The main risk of redundant code is that it looks innocent and useful, but it doesn't really work and it is never tested. In many cases you assume that there is some value in this code, so you keep it around, maybe it will become useful sometime. Well, most probably it will become useful by creating new bugs when you accidentally use it. Remember: this code was never really tested, just being there, so familiar, part of your code, does not make it something that works. And in many cases it confuses you, as you believe that a feature is already written, because the code is there, you only need to pass another value or take some code out of a comment. But this code was not maintained or tested for ages, if at all! How can you rely on it? Why keep it there in the first place?

My recommendation usually is to be very cautious with code that never ran and is just lying there, as it may be lying and not doing what it supposed to do.

Keeping unnecessary code requires you also to maintain these lines of code that you don't really need. Again, I say - get rid of it.

Generic Software Mission Statement

Following my previous post on the subject, I created the following generic mission statement:

Produce quality code, on time, for the success of the company.

Yes, I know, it's VERY GENERIC, but as a general mission statement for software groups it's quite good.

The problem with a more specific mission statement is that it may miss the responsibility of some of your employees. I had a few years ago a small group dealing with projects for customer applications. In one of our business group talks, the business group manager threw at the entire group that the goal for the team in the following quarter was to achieve sales target of 1M$.

The problem was that it was a group of programmers, not sales people, and achieving sales target was not part of our responsibility. The manager was just pumping down to us his own target (probably adding 25%, just to increase our motivation). The results of this talk was horrible, people were going around thinking how to bring 1M$, instead of doing their programming tasks. It scared some and it totally ruined the motivation of most, who usually do not relate their code to money. Code is art, relating it to money makes it dirty. Instead of speaking of money it was much better to speak about features, projects and deadlines. Even setting for a programming team a target of number of customer projects to achieve is wrong. Mission and targets shall be focused on the responsibility area of the team. It's the manager's responsibility to hide all the rest.

Vision, Mission, Goals, Objectives and Mesurements

Year start is a good oppotunity to think about vision, mission and goals. I know that there are those cynical of you, who treat vision and mission as a waste of time. I tend to agree. It's a waste of time if you invest in it too much, and it may become a farce when you invest 15 minutes or more in explaining your vision or mission statement to your organization. Vision and mission are a great tool for saying something short and not too meaningful, but there are still important as they do shed light on your VALUES -- what do you value and where you are going to put your efforts.

The much more important are the goals and objectives. This is your opportunity to list the strategic achievements you want to bring. Goals and objectives should be SMART. That is: Specific (not vauge or too general), Measurable (state the measurement as part of the goal), Attainable (be realistic), Relevant (related to your vision, even if you don't have one yet), and -- Time-bound (otherwise it's like an exam without a time limit). There are, by the way, other interpretations for the SMART abbreviation but the main idea stays the same -- be clear and make the goals something that can be checked at a certain point of time and marked as done/not done.

SMART is smart to say but difficult to do, especially when you plan the future, which is what you do with setting goals. Let's take some examples:

• For "Innovation", you may set the following goal: come up along the year with at least 5 new major (define major?) feature ideas, for which at least 3 would be judged as feasible and relevant to the market and at least one would be developed.
• "Quality" is tricky. You may want to give bonus to the programmer who creates the fewest bugs, you may want to read before what Joel thinks on that.
• "Investigating" new domain: what is the target goal to set? I usually set the goal as giving a lecture on the subject, at a certain agreed date. Usually it promises decent investigation of the subject. In some cases I add the requirement for documenting the material in our organizational wiki.

Setting strategic goals for the coming year/quarter/month is one of the most important tasks of a manager. Ask yourself, how you want your accomplishment powerpoint presentation to look like at the end of the period. Or maybe even better, prepare this powerpoint presentation ahead. Then set the goals and tasks that derived from it, aiming at minimum changes for your presentation.

Once you have the goals and objectives you can go back to the vision and mission, it would be much easier now to state them in 5 minutes. And if you don't find something strong enough go for "Bring qualitative value to the organization".