Fallow

Edsger Dijkstra famously argued that software should be finished in version 1.0. "You just cobble something together to sell. It need not be any good. As long as you fool people into buying it, you can always try to make better versions later. So you get these version numbers, even with decimals, versions 2.6 or 2.7. That nonsense. While version 1 should have been the finished product."

Dijkstra, bless his soul, was an ivory-tower academic idealist. He thought that software could be proven correct mathematically, and he worked long and hard to that end ... without even a version 1.0 to show for it.

Nevertheless, he had a point.

Over 40 years or so in the business I've spent time developing software for internal use in government, insurance, banking and others. I worked for 6 years at a company that sold, among other things, APL software, and software for logistics and materials management -- except for the APL, vertical markets all, high-priced, low-volume applications for big business.

Some of those 40 years, including these, my later years, I've been the customer rather than the vendor -- the victim, shall we say, rather than the perpetrator. I've seen very few perfect "version 1's". A few, but very few. (One, by the way, Titanium Schedule, for college and university counseling centers, is still actively developed and used, is nearly the best of its type that I have had the pleasure to deal with. SAS runs a close second, in another type of market.)

Not only are many of these packages not perfect in version 1.0: even in version 9.6.0.13 they come equipped with a readme that contains a long list of unresolved items, problems the vendor already knows about but hasn't yet fixed. What's wrong with this picture?

EWD didn't have to deal much with the real world, where we don't expect perfection out of (or in) the box. For a software company to survive, it has to sell something. Google can give away software (which thus does not have to be perfect, viz. the fact that most of it is perpetually labeled "beta") because it sells advertising. Version 1.0 (or, these days, often, version 0.something) usually derives from an idea that hasn't yet seen users and their depredations. Unless it's sold, there may never be a version 2.0, perfect or otherwise.

So we accept that we must wait for the next upgrade to fix many of the bugs we find in the current version; at a minimum we must pester the vendor for patches for the most egregious problems. And then we must warn the users that this next version that they clamor for will have new features, but will also trade in the old set of bugs for new ones.

And indeed, most new versions focus on the nifty new gizmos that have been added to the software. The vendor says s/he is responding to customer demands for new features. So what if existing customers don't need that new ajax-enabled form. Vendors are actually responding to the demands of prospects. After all, "customers" have already paid the buy-in price and maintain the vendor's revenue stream with annual maintenance fees (note that "maintenance" works both ways). If the software needs that spiffy new feature to close a quarter-million-dollar deal, then all of us paying customers get that, too.

For the same reason, my proposal will never happen.

I propose that software vendors periodically take a year off new-product/new-feature development, say, every 6-7 years. Take a year to fix all the known bugs, improve performance, smooth out production features, interfaces, all the little details that so annoy those of us who try to keep these monsters running month to month, year after year. Make the installers more streamlined, more flexible. How much happier customers will be, more willing to provide good references, if they can expect the software to work as advertised. Too many of these types of packages expect to be the only application on a machine, and to be installed on the C: drive. Take a year to talk to existing customers and incorporate those little suggestions that will make a real improvement for everyone.

I graze a lot of blogs about software development, many of them about startups, how to hire the best coders, which languages or platforms to use or support. And I know that developers usually prefer to "develop" new code, new applications. When we hire, shouldn't we also try to find those who insist on quality, and who demand the time to "do it right?" Can we find programmers who like maintenance (even if they don't really prefer it). I've always found it challenging to figure out what the programmer before me was thinking when he coded that spinlock and gave it the name of a Dutch pastry.

For most of us, a Dijkstra on the staff would be a luxury. I've worked with a few perfectionists, and I'll take someone a little less lofty every time. Computer scientists have a place at Google and Microsoft, at Oracle and a few other places. What most vendors need, however, are good programmers.

John Cook, in a slightly different context, speaks about the myth of progress: "Companies profiit from the myth of progress by selling new versions." Maybe we can come closer to Dijkstra's nirvana -- dispel the myth -- if we allow software to lie fallow once in a while, sprinkling it liberally with manure and tilling its rich soil.

Food groups in C

And I thought using Russian words (or Dutch) words was clever. How about this from Jacques Mattheij -- a program that used fruits and vegetables for variable and parameter names?

Programming in English

Scott Hanselman's post Do you have to know English to be a Programmer? made me recall some code I saw long ago in (I think) the Sharefile system of APL*PLUS for IBM mainframes. A spinlock had a curious name. When I asked someone about it, I was told that the programmer who coded it was Dutch, and the word was Dutch for something that no one by then could remember.

I occasionally use Russian words in my own code. For example, a date/time value representing the current time may be called сейчас (seychas). A date value representing the current date might be called сегодня (segodnya).

In fact, one of the comments to Hanselman's post noted the phenomenon: "Variables can be named significantly and easily understandable in any language, as long as all programmers that set their hand on that code speak that language."

-------------------------

Someone probably still owns the trademarks to APL*PLUS and Sharefile, but I haven't a clue who that might be. STSC morphed into Manugistics (which one wag said was proof that all the good company names had already been taken), which in turn seems to have disappeared into something called JDA.

My Bite of the Apple

So I got one of these ...

The new MacBook (aluminum), my first Mac. Stunning little bugger. If the price was competitive with Windows boxes, these things would take over the world. Slick -- the only word for it. Leopard (OS X 10.5.5) is rock solid and smooth as the glass display.

Macs, of course, have some of the same problems with software that Windows systems do: applications don't always work as advertised, some are faster than others. I've loaded OpenOffice 3.0 (the real Mac version), which also just came out. Debating about Adobe CS4. Firefox is okay on it, but Safari is faster.

I'm very impressed. Now, if I could find something that I really need it for ... Maybe I'll write a novel.

Becoming a Geek

Way back before I quit engineering school at Stevens Tech (in 1965, just before I would have flunked), we had to write a program in Fortran II for an IBM 1620 computer. This was a decimal machine whose operating system was a deck of cards. Our programs were small decks of a few cards tacked onto the end of the operating system and the compiler.

Computer time in those days was expensive; it was added to the cost of tuition. I don't remember the actual prices, but when a program went out of control, it mounted rapidly.

At the time I wasn't aware that dividing by zero was undefined/impossible/not a good idea. The computer didn't know it either, because if your program did it, the computer would compute endlessly. There were also the infamous "DO loops," loops that never exited. My program did both at successive times. The operator suggested I run a trace to help debug the thing. But what I got back as a trace was a full tray of cards that, when printed, produced page after page of hexadecimal gibberish. I wrote a letter to my girlfriend on the backs of some of those cards; the trace listing papered the walls of my dorm room.

It was almost 15 years before I came back to computers. I was working at the Federal Research Division of the Library of Congress. FRD was only nominally part of the Library, doing most of its work for the Defense Intelligence Agency using primarily open-source materials. The Library was a great place to work because we had access to the stacks and all of the resources of Capitol Hill and the Washington area. FRD, on the other hand, was a stifling environment run by narrow-minded bureaucrats who hired young college graduates in area studies (like me) doing largely useless work on the public dole. We were Robert Redford in Three Days of the Condor, but without the glamour (or the danger).


Being a government agency, however, we had to spend any leftover money at the end of a fiscal year or we risked not getting it next year. We had a small (two-person) engineering group which purchased an IBM 5100 table-top computer with some of these excess funds one year.

The engineers never used it; one of them soon quit and the other preferred a slide rule.

I was bored, however, and I had always liked gadgets, so I started playing with it. The machine weighed about 50 pounds and had a top cover with a handle, as if it was supposed to be portable; for those days, I suppose it was. Fully-equipped, it had 64K of RAM (we called it "core" back then), a high-quality tape drive, and two languages in ROM, BASIC and APL. Disk drives didn't come along until the 5110 model. It had a 5-inch black and white screen. We also had the accompanying dot-matrix printer.

I started out with BASIC and finally discovered arrays, and how to program a loop properly. This machine knew enough to teach me that dividing by zero was forbidden. But I soon became bored with BASIC and punched the button that switched to APL.

The Game of Life in one line of APL

This was a challenge, and great fun! After all, why iterate through an array when you can operate on it in one swell foop? IBM was heavily into APL at the time, and I worked with it a lot, off and on, for the next 10 years or so. At FRD I programmed an indexing system in APL on that computer. Sorting and storing, say, 2500 names in alphabetical order on a machine with only 64K of memory and a tape drive was an interesting exercise. I learned later that they replaced the 5100 with a DEC mini-computer.

By that time, however, I had become a programmer.