Covering the Bases

Something occurred the other day that got me thinking about complexity and the huge costs of covering your bases. It was just a little thing, but it caused a fair bit of trouble. We have an Eclipse project that builds remotely on an AIX box. The make target refers to a build variable that contains environment settings and other important information to pass to the server-side make. One of the experienced devs on the project was helping me debug the build and sent me some terms to add to the build variable. To get them to me he IM’d them. I copied the variables out of Kopete and into the build variable edit box in Eclipse.

Thereafter the build started failing repeatedly on the remote end. The dev looked at the build variable. I looked at the build variable. Everything was perfect… but it wouldn’t run. It took about half a day of trying various things to make it work before we realized that when I had copied the text from Kopete into the edit box in Eclipse it had included a carriage return. That was causing the issues with the make command on the AIX machine. To my mind this is a clear bug. A single-line edit should not invisibly accept carriage returns. I can understand a few rare cases where you might want to accept a CR/LF, but then you should display it as something other than whitespace, since by definition in a single line edit there is no other way to indicate the presence of a CR/LF.

But this is by no means a rant about that. This isn’t the first time I’ve lost a chunk of productivity to a silly error. Eclipse has hundreds of inputs and for whatever reason a bad decision was made on this one, or something was left unnoticed or undone. It happens. The occasion simply served to highlight for me something which has prompted me to climb up on the soapbox more than once over the last twenty years: inherent complexity. Everyone wants software to be simpler and more robust, but few recognize that the current complexity of software is inherent in the things we ask it to do. My Dad sometimes has reason to rant about the complexity of his computer when it doesn’t work right. He’s an engineer, and I occasionally remind him that a CNC drilling machine is difficult to learn to use correctly too, and the average personal computer is one hell of a lot more complex than that, because it is not tuned to a specific purpose.

The increases we are able to achieve in usability are subject to the same laws of diminishing returns that govern investment in any technology or method. We got a big jump when we went from punch cards and tape to terminals. We got another big jump when we went to GUI interfaces and pointing devices. Additional big gains will be hard to come by until, or unless, computers themselves are able to be much more autonomic, and be of much more assistance in guiding their users. That doesn’t mean we need animated paper clips that pop up and offer to fill in an email address for us. It does mean we need self-organizing interfaces that recognize the nature of repeated tasks on a per-user basis and internally proceduralize them so that they can be accessed and actuated at a higher level.

In the meantime, the average general purpose computer loaded with software will continue to appear dauntingly complex, because it is dauntingly complex. And in complex engineering environments it costs big bucks to cover your bases. Ask NASA. If it costs x dollars to shake out 95% of a given program’s inputs, controls, and environmental constraints then it costs 2x to smooth out the remaining 5%. What this says about the long-term viability of free software and the collaborative development model I am not sure, however I am sure that this whole concept is related to the general feeling that there is a lot of amazing FOSS software out there… and that most of it has more than a few rough edges remaining. Getting rid of those rough edges requires dedicated, and costly, testing and quality control, and to date only companies like Microsoft and IBM have had the economic punch to play that game. That’s why Visual Studio, for all its flaws, is a much more polished product than Eclipse is now, or perhaps ever will be. Money is still important.

Leave a Reply

Your email address will not be published. Required fields are marked *