As a closing thought, let's consider our jobs and how to protect them. There is a lot of instability in today's software industry, and the American sector is losing its competitive edge. The problem is that U.S. developers are overpaid with respect to what we produce, and people in other countries are willing to produce a similar product for significantly less money.

We can worry and complain about this, but that won't eliminate the threat. In just seconds our source code can be sent overseas, where it can be completed or fixed by other developers. If these overseas developers are smart - and they are - they will be able to read the code and start working on it immediately. There is no need for us any more. This is the sad truth.

So, what can we do? I don't think anyone wants to lower their standard of living, so taking a tremendous pay cut isn't an option. In that case, the only real solution is to determine how to become more competitive and improve our productivity. In other words, we need to find ways to increase our output.

There are many ways the software development process could be improved. To increase productivity as quickly as possible, I suggest we focus on a low-hanging fruit that can deliver large returns: we should shift the distribution of time spent building new code versus debugging. On average, we spend only 20% of our time writing new code and 80% of our time chasing and eliminating bugs. If we could only shift this balance so that we spent 40% of our time developing and 60% debugging, we would be 100% more productive, 50% less expensive, and significantly more competitive.

If we really want to achieve such gains, we need to introduce fewer bugs into our code so we don't waste so much time finding and fixing them. This general concept is called error prevention; when it's automated, it's called Automated Error Prevention.

The basic idea is that you should learn from your mistakes. Each time you identify an error, you want to determine why it occurred, create an error prevention practice to prevent similar types of errors from occurring, and then automate the error prevention practice that you've developed.

To fully implement Automated Error Prevention, you should perform this process for each error that you find. However, if you want immediate results, you need to take some shortcuts. The best shortcuts I know of are coding standards and unit testing, two practices that are easy to implement and that can be completely automated.

Coding standards and unit testing are valuable shortcuts because they can significantly reduce the error rate. In the case of coding standards, industry experts have already done the groundwork. They examined the most common and serious errors that developers tend to introduce, and then created rules we can follow to avoid these errors. The same is true for unit testing. Automated white-box unit testing can flush a lot of uncaught runtime exceptions, so we don't need to find them ourselves.

If we could also automate the process of fixing these problems, we could be very productive. In fact, you can already do this if you develop with Java. Tools exist that can automatically identify and correct Java code problems so that Automated Error Prevention can be implemented as rapidly and efficiently as possible.

Automating coding standards and unit testing is a good start to improving our productivity, but we will have to do much more to ensure our job security in these unstable times. For many years, we in the software industry have been very arrogant. Many of us now believe that the way we build things is the only possible way, and that our brains are irreplaceable. People in other industries believed this once - until their jobs were lost to competitors who could build the same product more efficiently.

Sadly, we too have been proven wrong, and now our jobs are on the line. In the good old days, our managers begged us to use tools to make us more productive, and we refused. Now we will have to beg them to provide us with tools that make us more productive - in the hope that they will save us from being replaced. Quite scary, isn't it?