Solving problems using software is the ultimate goal of software engineers. However, few people completely realize that just writing code is not the solution for all problems we will encounter. In many cases, the solution for code organization is to write less code, instead of more.

A common mistake that software developers do is to think that the solution for each new problem in a system can be found by writing another method and/or class. While this works most of the time, it usually renders the system even more complicated to understand and modify. Therefore, adding new features by means of more code hinders additional progress in the application, instead of helping.

The best solution to this situation is to take a step back, instead of adding more code. Think: how can the architecture of this system be improved so that adding this feature would be easier? When doing this, it is a frequent result that some code will be rendered useless, while more generic code will be added to hande a large number of cases. Thus, even when some software previously written needs to be removed, we are in fact making progress because the system will be able to handle more cases than before.

Although this approach is more painful in the short run, it is nonetheless the best way to develop a system in the long run.

Some Reasons to Avoid Code Inflation

I frequently try to think of ways of solving a problem using less code. When this happens, it is like finding a beautiful solution for a complicated problem — the same feeling that we have when creating beautiful mathematics. Here is a list of reasons why you should strive to write less code:

• Software accumulates features as it grows. Although these are useful when created, most side features become useless as time passes.
• The more features a piece of code has, the less apt it is to change. Thus, it becomes harder to react to new environments.
• Adding features is sometimes inevitable. Specially in a commercial application, adding features is a by-product of accommodating new users. In a big commercial application such as MS Office, it is just necessary. However, having a huge code-base is also a liability. You have to pay to maintain all this software that is not essential to the functionality of the application.
• When a new programming paradigm arrives, it is usually the smaller code base that has the advantage. That  is why software is such a good material for start ups: a new product needs only  a handful of core features to become usable.
• A corollary of this is that you shouldn’t try to compete with established players by just replicating their features. Try to move your application to a new paradigm that was not initially foreseen by  the established player — and that would make it very hard for your competitors to adapt. For example, that is what is happening in the area of web-based software vs. Microsoft.
• Usually, the smaller code base that can handle the core of a problem is the best — simply because it is the easiest to extend.

Do you have other reasons why a large code base is a liability? Let me know what you think.

I am one of the poor souls that need to use Lotus Notes as its corporate email solution. Although I learned to appreciate the integration capabilities that the IBM product has developed throughout the years, it still looks for me as one of the most over-engineered pieces of software that was ever written.

I was positively surprised, however, with the update of the Notes client to version 8.0. After years of using the tried-and-failed client interface that they insisted in maintaining, IBM decided to move to a new client based on Eclipse.

Eclipse to the rescue

Eclipse, if you are a developer working in Java, is already your old friend. Not perfect, but has lots of good extensibility features. For example, there are thousands of plug-ins available for Eclipse, ranging from productivity tools to programming widgets.

With the support for plug-ins provided by the Eclipse core, Lotus Notes can now add a lot of cool features practically for free. For example, the new Notes client can easily embed most (but not all) Google gadgets.

Look-and-feel

The look and feel of the application was also streamlined. The email window received a long-overdue overhaul. It looks now much more like a modern email app (such as Microsoft Outlook, if that is what you’re looking for).

To me, it looks like the Lotus team spend a lot of time replicating features from the old client. To my knowledge, the toolkit used in Lotus Notes 7 was written in multi-platform C++ (probably with a lot of biddings to Java code). Now, everything is in Java, using the Eclipse toolkit, which is definitely very different from the original C++. It must have taken IBM *years* to replicate the same functionality. It is not a surprise that Lotus Notes 8 appeared only now…

Even though the transition was mostly positive, on the negative side I noticed that the application size increased. Well, in fact the new program required 1GB to install! It is crazy to imagine an application (that is not a compiler, I have to say) that may need 1GB to be installed. Of course, these days where a 1TB hard disk is not a surprise anymore, things have certainly changed. I hope I am not the only person that still remembers applications being distributed on 1.2MB disks :-)

Svn server was recently updated to version 1.5. The life-changing feature of svn 1.5 merge-tracking, which means that the server will help tracking files that need to be merged between branches, so this will be less of a pain. Also, the server will be able to show exactly from where a branch was branched or merged.

The Google code blog published a very good article on how to do this, since they are also upgrading the version of svn used by their code hosting service. Here a small sample of how a merge should be properly done (sorry, this is just for CLI users, but you can replicate everything on subversion).


Make a branch for your experimental work:
$ cd trunk-working-copy
$ svn cp trunkURL branchURL
$ svn switch branchURL

Merge your branch back into the trunk:
$ svn switch trunkURL
$ svn merge --reintegrate branchURL
--- Merging differences between repository URLs into '.':
U button.c
U integer.c
...
$ svn commit