Monthly Archives: December 2008

Why Racing Probably Will Slow You Down

Many programmers will have gone through the following cycle.

The project time line has been tight from the beginning. Finally the specification gels into a vaguely discernible form, though pretty late. No time any more for architecture, design, and generally engaging the brain before typing. The deadline must be made! Everybody rushes to the goal, best practices and common sense are trampled into the ground, and hackers feel finally freed from those bureaucrats that call themselves architects.

Inevitably the project is late anyways, and the code is a huge mess that will be cleaned up when there is time. That is: never. Time is money; where should the money come from?

The customer? “Hey, the stuff finally works, why would we pay for beautifying the code? And, by the way, don’t you guys advertise high coding standards?”

Your own company? “Well, the budget is blown, and the customer won’t pay for it! And, by the way, aren’t you guys using best practices?”

A good solution would have taken maybe 20 or 30% longer than the ordered estimate. In the end the project consumes the same amount of time. Additionally you get a much poorer result, angry customers, frustrated programmers, and the kind of code that makes you want to switch projects before the next release. Cutting corners when your experts beg for some time to think before coding will buy you nothing in the long run.

Fighting Software Entropy – Intermediate

Recently I read an IEEE article on software metrics that identify potential dangerous constructs in code, such as brittle base classes. One short example: “Foo” declares and uses a method “bar()” that may be overridden by an extending class, potentially breaking functionality in the base class.

Metrics like this can really help to improve software quality. Considering the state of code that I see every day as part of my consulting business metrics like the one described above would be the final touch on top of a long list of measures and rules I would recommend to employ first. As long as methods with more than 200 lines abound, copying code is a design pattern, and “verifyOrder()” changes the delivery address in the data base you’ve got bigger problems to tackle first.

When washing your car you don’t start polishing before you hosed away the mud – that would be spending a lot of effort in the wrong place. Getting rid of the mud takes 20% of the cleaning effort and gets 80% of the job done. When you optimize a program you first analyze where most of the CPU time gets spent and concentrate on these hot spots. Likewise, there is a rather small number of coding guidelines that go a long way to improve code quality.

Here is my hit list of the most important code improvements:

Nomen est Omen: The name should fit the meaning. Don’t call a method “verify()” – the name strongly implies read only access – when the method changes data or even creates and deletes whole records in the data base. You don’t like documentation? Well, choose good names; together with the next rules your code will be as easy to read as pseudo code. There is no excuse for bad names: refactoring has made renaming safe and painless.

One method, one purpose: If it is difficult to find a concise name you probably packed to much functionality into one method. Break the method in smaller methods that each do only one thing, and make that thing the name of the method. Again, refactoring makes this simple.

Break down long methods and expressions. Introducing more local variables will not slow down your program; modern compilers will optimize execution better than you can (at least in this regard). Break down methods into smaller methods, too. You might even find redundant code that you can eliminate, or that methods become usable for other than the original purposes.

[This article is going to be extended]

Fighting Software Entropy – The Basics

In many companies code formatting and checking tools such as the Eclipse code formatter (or better: the cleanup function), Checkstyle, PMD, and FindBugs are pretty much the only measure taken to improve code quality. To continually use these tools is a very good measure – as long as one realizes code formatting and checking are the very basics of code improvement, not the pinnacle.

Through 16 years of professional programming experience I am certain that not tools and rules will create software quality, but genuine insight. In example, I worked for a large telco as a software architect. But instead of designing a system that, just as an example, decouples business logic from specific XML parsing frameworks through the use of domain data classes and transformers I found myself having discussions with certain programmers about the number of characters per line.

Some programmers were using expressions that extended over 200 characters and longer, and considered it their personal right and freedom to do so, as long as the code works. I disagree, since not only the compiler has to understand the code, but humans. Such an attitude neglects the rights and freedom of others, in example the right to understand the code of coworkers in a reasonable amount of time and the freedom to concentrate on implementing functionality, not having to reverse engineer cryptic source code first.

Sticking with the overy long expression example I maintain that nobody can intuitively grasp the meaning of such a monster. This is not how the human mind (specifically short term memory) works. So: Break long expressions down. Use refactoring to introduce methods and local variables. “account.isNew()” contains more information than “account.getNumber() == null” and is way easier to read and understand (and what happens if in the future accounts can be new and already have a number?).

Let us assume you are in a role that is supposed to improve software quality. Now, how do you create insight? The term “insight” implies that it is something that a person develops for her- or himself. It is nothing that you can forcefully create; it has to come from inside the person. You can try to foster insight, by appealing to having an open mind, showing good and bad examples, and providing positive feedback (eventually enjoying the results of a better programming style).

What do you do if all that does not help, and a programmer expresses his or her low opinion of the suggested programming style verbally, or worse, in code?

Well – I personally expect that professionals try to improve their skills all the time. Backed by the insight and research of others and by my own professional experience I have an opinion on what good and bad programming style looks like. I know what programming style means to a project in the short and the long term. As a developer I have often enought felt the anger, frustration, desperation, and hopelessness that comes with having to understand, maintain, and extend steaming heaps of code that nobody dares touching any more.

The difference in programming style and attitude is so great (measured by criterions such as less stress, higher productivity, more deadlines kept, lower cost, less overtime, and – yes, more joy!) that if I have the choice I’d rather work with programmers who employ a good programming style, and let the others go to work on other projects.

Mantras

[This article is going to be extended every now and then]

All Redundancy Is Evil

Really, if you can avoid redundancy, do it. If it costs some unpleasant effort, bear it – you’ll get repaid later again and again.

Copy and paste is a surefire way to pain and suffering. It is very hard to see if different but similar code really does the same thing – you’ll have to compare the two spots down to the last character. And when there are differences, are they the result of deliberate modification or some accidentally incomplete update?

If it can be generated, don’t check in the product but polish the source (and, if necessary, the generator and/ or its configuration) and automatize the process. There are way too many projects where the results of some generator run have been checked in. After a few months nobody can tell for sure anymore whether the generated stuff has been modified by hand (and don’t do that).

Don’t “Unstructure” Information

Enterprise Architect, a very good UML modelling tool, allows you to attach RTF documents to an UML element (the tech term is “linked document”). I’ve seen projects where all information is in the RTF document, and none in the fields and links that Enterprise Architect generously provides (pre- and postconditions, scenarios, actors etc.).

Why in the world anybody would do something like that is beyond me – you loose all opportunities to generate reports (ensuring a standard look and feel), run crosschecks, enforce documentation standards, perform context-specific searches, visualize dependencies, trace relationships, access information via an API and much more.