The other day I noticed that a bulb had burned out in my room. Which meant that I had to get a new bulb and replace the one that had failed. The act of replacing the bulb, perhaps surprisingly, led to some aggravation. Let me tell you about it.
The lamp in question does not take old-fashioned lightbulbs. No, this is a relatively modern lamp: it takes halogen spots. Halogen bulbs, as you might know, are not screwed into place. They use pin connectors which you stick into a recepticle which clamps onto the pins to prevent the bulb from falling out. In the case of smaller halogen bulbs a spring clamp suffices. Halogen spots are a little heavier, which means that their recepticles use two screws to clamp down on the pins.
My lamp does not just use halogen spots: my lamp is a product of early industrial design, which means that it is something really special. My lamp, you see, is the modern version of track lighting. Track lighting was very popular in the 1970’s: it consisted of a track with electrical leads in it on the ceiling. The lamps themselves were movable modules which clamped onto the track and used either metal hooks to hook onto the electrical leads or metal plates pushed onto the exposed leads by a spring. Track lighting allowed you to create the lighting form of your desire (more or less).
The modern track consists of two metal cables encased in plastic (thick enough not to slack, adjustable for length and isolated against contact by hands). In order to make electrical contact, the lamp modules use screw clamps and screws with a pointy tip. One clamp grabs onto one cable and if you tighten the screw the pointy tip just pierces the plastic isolation and makes contact. The clamps connect to a cradle that houses a recepticle for a halogen spot. And some ornamental metal bits cover the cradle up, making it difficult to electrocute yourself accidentally.
There is a simple and straightforward procedure to replacing a lightbulb in this lamp:
- Undo the clamp screws on the correct cradle and take the cradle down from the cables for easy access.
- Undo the recepticle clamp screws and remove the dead bulb.
- Put in a new bulb and tighten the recepticle screws.
- Put the cradle back on the cables.
- Tighten the clamp screws until both pointy ends have punctured the plastic and are making electrical contact.
Simple, easy. Any idiot can do it. And yet, after a few minutes fumbling with overhead screws and dropping screws and so on, I am left with one aggravated question:
WHO THE HELL DESIGNS A CEILING LAMP THAT REQUIRES A SCREWDRIVER TO REPLACE A BULB?
Environment
I think everybody understands what I’m getting at: whoever designed my lamp put together a couple of very cool ideas about lamp design that look very nice on the drawing board — but spent no time whatsoever thinking about how the lamp would be used by people at home. In other words: they didn’t take the deployment environment into account.
I wish I could say that only lamp designers make this mistake. Unfortunately, completely ignoring things like end-user experience and interaction design are mistakes that are all too common in our neck of the woods as well. Examples abound of software (and hardware) concepts that look good on paper but that work so badly in practice that they are almost unworkable. Let me give you some examples:
XML firewall
This example is taken from experience at my project for a certain Dutch airline (think swans). Over the past few years that airline has been transforming its IT landscape to a SOA architecture and we have been helping them do so. As part of this transformation they have bought and installed an XML firewall from a third party. This XML firewall provides high levels of security for XML communication, validating messages against XSDs and other service details against WSDLs. It also ensures that hackers/crackers cannot glean information from errors: the firewall replaces detailed errors returned by service components with a very general, non-specific SOAP Fault.
This is all well and good and it’s a perfect idea for the production environment. Unfortunately the XML firewall in question is very inflexible with its security in that it cannot be adjusted or turned off. Which means that it is a total disaster for the development and test environments. During development you don’t want to hide errors — the development teams need those errors. However, to get those errors the development teams now need assistance from the XML firewall operators; the errors are now only in the XML firewall logs and not in the messages. And the logs are inaccessible except from the control application of the firewall.
So, as a result, the development teams must slow down the pace of working on the test environments to a crawl because every error means a trip to the firewall operator. And the firewall operators are harrassed because assisting the development team takes up time that they need for their other tasks. And all because the designers of the XML firewall didn’t think far enough ahead.
Mobile email
Mobile email is another example of not thinking hard enough about your end users’ environment. Mobile email is the result of the coming together of the cell phone, the PDA, regular email and the SMS.
Everybody knows about SMS. That’s mostly because it’s not just the earliest form of phone-based text communication, it’s also the one that is still used most. SMS stands for SHORT Message Service. It’s perfect for cell phones. It works on all but the most ancient phones, it’s relatively quick and its size limits fit with the limited typing capabilities of the vast majority of cell phones.
Email is another oldie-and-goodie. Quick, convenient, easy, straightforward protocol, fits with the computers it was designed for, common as muck so everybody can use it.
Mobile email is the result of some engineer (or business guy) saying “wouldn’t it be nice to integrate email with the mobile platform?” And the answer is “no”. Mobile email is very convenient for reading your mail on the go, if the mail is short. For larger emails or HTML mails or mails with attachments however, you need a mobile device that is more capable than your basic phone. Which means that the device is more complicated and therefore more expensive (which limits the applicability of mobile email since not everybody can afford it) and you get crappy battery capacity. Worse: have you ever tried to type an email on your mobile email-capable device? Reminiscent of a regular cell phone, isn’t it? Not very comfortable. I wonder why it is that all the mails I’ve ever received from a phone resemble SMS messages in length….
The data loading application
The final example I will mention is somewhat different than the others and serves to illustrate that not thinking enough about the end user is not a problem exclusive to prepackaged software. This example comes from another project I worked on some years ago.
We were working on a billing system which required setting up some complex, billable accounts. Many of these accounts were complex but similar in structure, which meant repetitive work in setting them up. The end users were complaining about the amount of work involved in setting up the pieces of each individual account, requiring moving back and forth between the screens of the management module supplied by the vendor of the base billing system. One of the functional analysts of our team (a rather new person) undertook the task of coming up with a solution.
What this analyst came up with was a design for a new management module that put all the functionality of creating an account on a single screen. It completely eliminated the need for going back and forth between screens. Setting up the individual elements of the account remained the same.
One look by a more experienced analyst (and a developer, independently) lead to the conclusion that this was not what the end users wanted. Sure, there was no more back-and-forth. But really it made no significant difference in the effort of setting up an account since the effort was in have to set up a lot of similar account elements ad infinitum. What the end users really wanted was the ability to set up standard accounts in batch.
Now, in this case there was no great disaster since the wrong solution was never built and never went live. But it was close — we could have ended up with a very disappointing result for the end users because a functional analyst didn’t really understand what the end users needed.
The domain expert
The lesson, I think, is clear: no software project, large or small, is going to be a success without a clear view of what end users expect and how they will be using the software being built.
Now, that seems so obvious you’d wonder why anybody would bother writing it down. And yet, somehow, we forget it often enough that there are all sorts of examples of projects that got it wrong. There’s the examples I gave above. But there are plenty of others, especially if you consider that the result of not considering the end user need not be complete failure of the product as a whole. Consider the Microsoft Office suite for instance: it works perfectly well for almost everybody, but it’s also huge and top-heavy with functionality that nobody needs or uses (and relatively expensive because of all the unnecessary effort that went into developing the functional overhead).
The need for expert understanding of the problem domain beyond purely the functional level is the reason that many agile methods (including XP) advocate something that many consider to be a very esoteric practice: the on-project domain expert. The end user representative who is part of the project and who is not just available by phone or mail all the time, but who is actually physically present in the project area and no more than a short walk away. Not only does he provide the functional domain knowledge the project needs, but he provides the non-functional insights that make the difference between software being functionally correct and being succesfully deployed and used.
As the example of the XML firewall shows, there’s more to considering end users than you would think at first. Sometimes, you see, your end user is not who you think it is (or not just who you think it is). In the case of the XML firewall a whole category of end users (the developers in the company IT department) were being ignored due to not being considered by the product designers. Even though live-like testing on a development environment is a valid usecase for an XML firewall. Something that any IT operations manager would have been able to report if asked to function as a domain expert.
In case you’re stil wondering about the value of having a domain expert, consider the adage of the open source community that most projects get started by the developer scratching an itch: the developer of the project serves as his own domain expert, creating the software that he wants because nothing else does what he wants it to. Of course, there’s a lesson there for software development teams as well: don’t forget to consider yourselves as domain experts when it comes to things like testability of the application.
Software engineering
Over the past few months I’ve been coaching an intern at our company. Doing so has allowed me to reflect for the first time on the journey from being a student to being a software engineer; the transition from apprentice to journeyman to master as some describe it. At this point I consider myself a journeyman, by the way.
When I started out on my own journey, I was lucky enough to be taken under the wing of James Dobson, a man I still regularly describe to others as the most brilliant software engineer in the Netherlands. Until now I’ve always appreciated what he taught me about software development, but it’s only now that I’m getting to the point that I can understand some of the other things he tried to teach me. About how software development is only a part of software engineering; about the software development process.
One of the things that I am beginning to appreciate, in seeing my intern, is that the difference between the software engineer and the programmer is that the latter thinks it’s all about programming — the latest framework, the newest tool — rather than the process of finding the best solution to the client’s problem. Which is how you end up with XML firewalls or modern track lighting.
Strange where thinking about lamps gets you. Guess that’s what you call a lightbulb moment. 🙂