Kode Vicious - @kode_vicious
PDF
Human-KV Interaction
Welcome to another installment of Kode Vicious, the monthly forum for Queue’s resident kode maven and occasional rabble-rouser. KV likes to hear your tales from the coding trenches, preferably those ending with a focused question about programming. KV also has a tried-and-true arsenal of techniques for dealing with interpersonal relationships—the annoying co-worker, the micromanager, the spaghetti-coder—so feel free to enlist his help with those characters as well. We can’t guarantee you’ll agree with his advice, but it’ll probably be more effective than anything you’ve tried thus far.
Dear KV,
I’ve been reading your column occasionally and haven’t seen you address anything related to user interface design and how it can completely torque a piece of software. I happen to work as a programmer on a project for a company that sells point-of-sale software, which is a nice way of saying cash registers. The goals of the marketing people and user interface designers (we have several for our different product lines) always seem to twist the software into directions that only make it more fragile.
These people ask for features that, while to a naive user might make the user interface easier to customize or use, to any of the programmers on the project it’s obvious that the feature in question will have a negative impact on code size, clarity, or some other nasty side effect. Several times our releases have been delayed because midstream we were asked for a feature that proved to have such a horrible side effect that it had to be removed right at the end. Sometimes these “features” are really just visual changes, but our system is so easy to change visually that it seems to invite the marketing and design folks to make changes just for the fun of it, as if the color of the buttons ought to be red one day, then blue the next. Is there any way to make these pests go away?
Torqued
Dear Torqued,
What’s this about you reading me only “occasionally”!? Well, if you had been reading all the time, you would know that I haven’t actually addressed your issue, but I’ll let you in on a little secret. Long before my lucky escape from the presentation layer, I thought I, too, would like to work on user interfaces. After all, they’re the first thing you see when someone uses your software, and done right, they are the first thing that people praise. Very few people come up to you and say, “Hey, nice protocol. I really like the way you made use of that spare bit in the flags field.” It was actually quite a big kick the first time I could say to Mom (yes I have a mom; I was not hatched as so many people seem to claim), “Hey, see that, I did that,” and could explain in simple terms what the thing I did was doing.
Two things took me away from UI work: The first was a deep interest in the lower levels of operating systems such as device drivers and networking. The second was the same marketing and design people you mention. I remember one who seemed almost to delight in asking for changes, as if the accumulation of modifications was his personal contribution to the system we were building—which they weren’t; they were just a drain on resources. Alas, this particular person wasn’t fired out of a cannon, as I often asked management to do, nor even fired; he just took another job, I suspect in order to find someone else to torture, or because I kept slashing his tires. I still wonder if he ever figured out who did that.
Now, before I go on, let me say that there are some wonderful user interface designers who really get that it takes more than a few seconds to make pervasive changes in software and who, therefore, choose their requests carefully and work with the programmers to get things into a suitable state. There are five of them, and no I will not give out their e-mail addresses.
Over the years I have developed a few strategies for dealing with the more interfering types of designers, who aren’t really designers at all—they’re just quacks who can talk smoothly about the use of color and are fine for helping you decorate your house, but useless at software. Oh, and none of these strategies involves violence or will get you arrested, I think, so I feel that I can share them.
One of the most important things programmers or software architects can do in the early stages of building a system, to protect themselves from being yanked around, is to separate the way in which information is presented to the user interface from how it is stored and manipulated in the real system. I know that such a rule must seem obvious, but I have seen people do the exact opposite time and again. It is a fine idea to look at what data the system needs to store and manipulate as a set of inputs, but how it is stored and manipulated must be separate from how it is input, or you are already lost. Dante seems to have left out this particular region of hell in The Inferno, likely because such sins were less prevalent before computers and user interfaces became ubiquitous, but it is there nonetheless. I know, I’ve been. I’ve got the scars and the company t-shirt to cover them with.
OK, now that we’ve got the presentation and manipulation systems apart, the next thing to do is to design a presentation layer that is easy to change without breaking the rest of the system. If your designers want to change the color, text, font, font size, and character set used throughout the user interface on a weekly, daily, or hourly basis, let them! It gives you more time to code real features if they’re off playing with Pantone color wheels, fonts, and button borders. Make sure that changing the user interface doesn’t require any knowledge of building the software or using any complex tools such as text editors. The last thing you want to do is baby-sit, as I have, the designers as they complain that every time they build the code, it breaks. It should be completely unnecessary to compile anything to change the user interface.
Making sure that the user interface can be simulated in the absence of a real system is often a big win as well. You’ll be much happier if the designers can play with the UI while you’re building the rest of the system instead of dealing with constant maintenance of the unfinished system because the designers need some feature RIGHT NOW that you know you don’t need until much later.
With all this decoupling going on, the biggest internal danger to watch out for in your system is layer proliferation. A favorite quote of mine, attributed to Van Jacobsen, a networking researcher, is, “Layers are a good way to think about network protocols, but a poor way to implement them.” The same is true for most software. How many layers do you need? Enough to get the job done and not so many that they impact performance. Don’t like squishy answers like that? Tough, suck it up. It’s your system and you’ll have to deal with this on your own, but if you don’t think about it at all, you will really hate yourself later. Either you will wind up with too few layers, and therefore nasty tendrils of code violating the layers and causing problems, or you’ll wind up on the other end of the spectrum where you might as well move the data on paper because it will be faster than waiting for it to crawl its way up from the murky depths of secondary storage only to see the light of day minutes later. Neither is a system you want to work on, trust me.
So, there you have it: KV’s quick list of how to avoid getting your chain yanked by the color selection brigade: Separate the API from the UI, build a presentation layer that can be changed without any need to be a programmer, simulate the back end as soon as you can, and make sure you have the right number of layers.
KV
KODE VICIOUS, known to mere mortals as George V. Neville-Neil, works on networking and operating system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking, operating systems, and rewriting your bad code (OK, maybe not that last one). He earned his bachelor’s degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. He is an avid bicyclist and traveler who has made San Francisco his home since 1990.
Originally published in Queue vol. 4, no. 2—
Comment on this article in the ACM Digital Library
© ACM, Inc. All Rights Reserved.