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.

So you've decided the agilists aren't completely crazy and maybe it's time to think about it. And, your waterfall project is in the dumps. You'd like to make some progress, and oh, maybe even find another job because you can't see how your company can live through this project disaster.

If you're considering how to integrate Agile into your work, here are four tips you can try to implement now:

Decrease the size of your tasks so you can get to done faster. One of the issues in non-agile lifecycles is that the tasks tend to be too big. It's common to see 1-week, 2, 3, 4, even 6-week tasks. The problem with tasks that large is that people get lost in the task. They lose sight of what done means. They wait until too late to start the task (also known as student syndrome). It's just too hard to do. So, instead of trying to manage big tasks, break every task down into smaller pieces. I like 1 or 2-day tasks max (also known as inch-pebbles).

Work in short timeboxes. Once you have smaller task sizes, make a todo list for just one week at a time. I have to admit, I have my big todo list, so I can track and see all the work I have to do. But my working todo list is just one week long. Because I work in short timeboxes of one week, I have a pretty good idea of what I can get done in a week. And, I know when I'm not making progress in a week, so I have some early warning signs.

This can be quite difficult to do if you have many partially finished tasks, or if your boss wants you to multitask, or if you are depending on other people for input into your work, or if you've never received feedback about your estimates. Don't worry if your estimates are wrong. Estimates are just guesses, so guess for now, and track your work. I don't track actual hours per task, I just look at my one-week list and see how much I have on it and where I am during the week, and where I am at the end of the week. I often have a task or two I did not finish. I don't beat myself about it and neither should you. Take that information and re-estimate what you can do for the next week.

Finish partially completed work. One of the biggest changes I found when I moved to agile is I had much less partially completed work. I still have several articles (and books!) in progress, but they are all at reasonable stopping points. When you have partially completed work that's not at a reasonable stopping point, you feel a pull to go back to it until you get it to a reasonable stopping point. That pull causes you to multitask, which prevents you from finishing more work. So the more work you can get to a reasonable stopping point, the better. That frees your mind to go do the next piece of work. Which means you can do small pieces of work and get to done faster.

One of the ways I do this is to use the SCM system to help me. I integrate continuously, no matter what I'm writing (code, tests, documentation, project plans). That way the latest version is checked in, and I know the state that it's in and I don't have to think about it.

Know what done means. Any given task may have a different definition of done, but a project's definition of done is "fit to release." Since the project has to be ready to release, I like my pieces to be ready to release also. Sometimes, as one individual contributor, that's not possible until other people have done their parts. But make your pieces as done as you can make them.

For me, this means working by feature more than working by architecture. If your project manager is still organizing the work by architecture, offer to work with others across the architecture so you finish a feature, even if you don't finish the architectural layer. Yes, this may seem counter-intuitive, but it's faster and leads to finished product earlier.

Why should you do this? Because if you're looking for a job, even if you don't have agile experience, these practices will help you add value to your organization now. And you can talk about them in interviews.

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.