I am writing this article from Japan, where I am spending the weekend with a former student who I taught 30 years ago. This student was a "late bloomer," as he is only 10 years younger than I am, and we have kept in touch over these many years.

My friend does not do much coding any more, and compared with some people, he has not written that much code in his life. For that matter, I never wrote as much code as some people in the Free Software arena. I tell people that my "C" looks a lot like Fortran, but what I write usually works, and works well.

Both of us have moved on to the job of empowering other people to get their work done on time and "under budget." The difference is that when I say "use Free Software and collaboration to help," most of the people I work with do not have to be convinced; in fact, they would look at me strangely if I said anything else. My friend is not so lucky.

So the first night that I was in his house, we broke out several beers, and the time was spent commiserating about how his company kept insisting on doing things "the same way," which typically meant buying technologies from other tech firms and then paying royalties on that software forever, even when the supplier was not adding any value to the solution.

"I do not mind paying for quick bug fixes to problems we have," my friend said, "but we are a relatively small customer to our supplier, and they react to all of their larger customers first, and we get the support last. In addition, there are some products, which we purchase, that we actually have created solutions in-house, which we could substitute and stop paying useless royalties, but our management does not let us do the work."

My friend accepted the agile method of developing code many years ago. In fact, before people became "agile," most Unix people had already developed the habit of creating a quick, throwaway prototype – with the intention of rewriting the code completely before creating the production copy – as something that the end user could work with and see if the basic premise of the code was being met.

What my friend's company was doing, however, was "waterfall" programming, with relatively short periods of requirements gathering, design, coding, and testing, with little or no time for feedback at any level. His fellow workers pointed out that according to the schedule, they would get the job done on time, but my friend pointed out that if they were missing key functionality, they would not find out until the project was due, and then it would be too late.

Many years ago it was very difficult to install the Berkeley Software Distribution (BSD) on a system like a VAX 11/780. You had to boot the media, configure the kernel using a text editor, and type in names of hardware controllers, such as the KMC-11, as well as input the controller's interrupt vector and address in the memory bus. After you saved the configuration file, you rebuilt the kernel, rebooted the system, and proceeded with the rest of the installation.

I noticed that the VMS system could configure itself, even on the same hardware, and I asked why Unix could not do this. "Cannot be done" was the reply I was given.

I went back to my cubicle and created a small prototype using a diagnostic program, some shell tools, etc., and I had a working copy in less than half a day. The engineer who said that it "cannot be done" then took my prototype and created production code in another day.

Another issue facing my friend was the caliber of employees that were sent to him. My friend takes the attitude (as do I) that good engineers can learn a new computer language or IDE in a very short time, but a great engineer will keep learning and improving over their lifetime. The person who says "I do not know that language, but I can learn it quickly" or "I have not heard of that technology, but I can find out about it" are the types of people that my friend and I want to hire.

My friend has a question he asks of potential employees: "What do you say to me if I tell you that we need something done quickly?" His favorite answer was the programmer who said "The first thing I will tell you is that I have to call my wife and tell her I will be home late tonight." That candidate was hired.

Sometimes the answer is not the code, but the way you approach the problem.