I'm at the QCon conference in London, one that I particularly value for its vendor-neutrality and strong content. Yesterday we heard from Robert Martin, founder of Object Mentor, on the subject of software craftmanship, or how to avoid bad code. One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.

Software is vulnerable to poor craftsmanship because code is often well hidden from customers and end-users. Still, the programmer knows whether they are putting together something that just about works, or crafting something excellent that will be understandable and maintainable long into the future.

Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:

• Keep functions and methods short. How short? His principle is to use extract method refactoring until there is nothing more to extract. I got the feeling that he would consider anything over 20 lines suspect.
• Have functions with only a few arguments - preferably no more than two - and don't use boolean arguments because they cause confusion.
• Similarly, a class should be a small batch of code, with only a few variables, a couple of dozen methods.
• Eliminate duplication in your code; use abstraction.
• Give public methods short names, but use long descriptive names for private methods. The code is the documentation.
• Improve code slightly every time you touch it. Sometimes the opposite happens; code decays as fixes get added. If you improve it instead, your project improves over time.
• You need comprehensive tests, otherwise you do not dare to make changes in case something breaks. Test code should be of the same quality as production code; if your tests are slow and buggy, you will not use them or trust them.
• Have short iterations. A month may be too long. Two weeks is good. One week, he suggests, may be ideal; or even less in some cases.

You may not agree with all of these; but I like the underlying objective, which is to code to a high standard rather than just fixing bugs until it runs.

Agree? You can sign the Manifesto for Software Craftsmanship.

The most striking talk in last week's Future of Web Apps conference in London (FOWA) was from Sun's Director of Web Technologies Tim Bray, well-known as a co-inventor of XML. On a day when the world's stock markets were in sharp decline, he tore up his talk and spoke instead on how developers can survive the coming recession.

His recipe for survival is as follows:

• Go Agile. The Agile development methodology is flexible, delivers high-priority features quickly, and doesn't lock companies into long projects that only yield returns at the end.
• Use open source:

"It's got to be very cheap to deploy technology. In practical terms, that means open source software. I do not see much of a future for Enterprise software."

said Bray. I believe he overstates the case. Companies are not going to make major platform shifts because money is tight; they are more likely to play safe and stick with what they use now. Nevertheless, if you can choose between free and expensive, free is pretty attractive.

• Go to the cloud:

"The business benefits of going into the cloud, you only have to pay a little at the beginning, you don't pay anything serious until you see benefits, are going to look overwhelming."

The snag here is that like the rest of us, Bray hasn't figured out which cloud to go to, and is particularly wary of lock-in. Still, utility computing has obvious cost-cutting potential.

• Lose your programming prejudices. "Stop believing in programming religions," said Bray. I reckon this is his most important point, and relates directly to the others he made. In a downturn it pays to be pragmatic. Developers willing to get out of their comfort zone and try something different for the benefit of their customers will have more opportunities as firms cut back.

What if things get really bleak and a lot of us have time on our hands? Well, at least it is an opportunity for Java developers to learn PHP, or vice versa. Further, as Bray observed at FOWA, getting stuck into an open source project is a great way both to learn new skills and also to build your professional reputation. Never mind the CV; the first thing he does when evaluating a job application is a Google search.

Nobody knows how severe the downturn will be; Bray thinks it will be grim but admits he could be wrong. What is certain though is that the world will still need software development skills, and that the Internet will continue increasing in importance. If this is where your skills lie, that has to be a mitigating factor.

 

You can see highlights from Bray's talk here; and summarized on his blog.