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?
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:
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 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.
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. 🙂
14 thoughts on “The parable of the lightbulb”
Pingback:Gridshore » What did 800 visitors a day bring to our blog and why we are going to pass the 1000!
I’m going to say one more thing on this and then leave it.
First of all, I just had to replace another bulb on a similar lamp. Vinnie, you were wondering if the effort required in changing the bulb would ever factor into purchase: yes. I didn buy these lamps, but I’ll absolutely never buy this model myself. Especially with the experience I have now, I don want to have to fuss around in the dark with having to disassemble a lamp module. As far as I am concerned, the ease of a twist-free bulb is an absolute requirement.
That aside, I stand by the point of my original post. When designing software in any way, you should consider the use by the end-user — at least to the point of not irritating that end-user.
In a related point, and one I find quite interesting, sometimes the problem is that you make exactly what the end-user wants (or that they say/think they want).
Look at Detroit. Their consumers wanted big trucks. The car companies made big trucks. And now they are being criticized for making big trucks. And they are struggling.
Tyson, it is a good point about the 20%. And not only does each user require a different 20%, but no one actually knows in advance exactly which 20% anyone user will use. That would be some pretty amazing foresight.
Jamie, it is not always the best product that wins the race. Fashion, marketing, irrational decision-making, hype, luck, perception, corruption…
And what is winning the race with lightbulbs? A better design vs harder to change? Or easier to change vs less pretty? Those fluorescent tubes are often hard to change and are very popular…
What a discussion.
About this light bulb changing… the lightbulb that does exactly what it should and is easy to change will win the race. It’s just like cars that used to manual ignition (with a crank). As designs evolve we introduce levels of abstraction over our product versions. The crank becomes an ignition button, the dirty engine gets colour coded (ever seen a BMW engine?), etc. In software, we can evolve quicker by speaking to users and giving them what they. We can, with the right processes, tools, and skills, change software easily. That’s why I like to explore the solution space – but then again not everyone is the most brilliant software engineer in Holland… Sorry, couldn’t resist.
Good discussion. Keep them coming Ben, engaging the community and getting people thinking – I love it.
I enjoyed the essay, and agree with much of your summary. I think that the examples you use don’t really support your thesis, however.
It sounds like a real hassle to change the bulbs on that lighting. But so what? I doubt that very many people will include that factor in purchasing lighting. All else being exactly equal, they might prefer the easier to change bulbs (if they even remember that factor), but if changing that effects the appearance, cost, or lighting abilities of the device, forget it. Those other factors are so much more important that I doubt many people even consider the ease of changing bulbs when purchasing a light.
And as a dedicated crackberry user, I have to agree with Vinnie’s comment on email. You may not like it, but it very much fulfills user requirements for a lot of other people. When it doesn’t work well, the failure is not because mobile email is a fundamentally flawed concept, it’s because this has been bolted on to a lot of devices that don’t support it very well. When it’s done well (Blackberry, Treo, iPhone, etc.) it’s because the device was designed to include it. It’s not a coincidence that the most popular phones are all built around this. Not including email on a phone at this point would be a perfect example of what your post objects to: failing to address user needs.
And, regarding the 80/20 rule, I highly recommend that you read Joel Spolsky’s essay about this from a few years ago: http://www.joelonsoftware.com/articles/fog0000000020.html
(Quick summary: most users only use 20% or less of the functionality, but each user uses a different 20%. Anytime you drop a feature from a word processor you force people who need that feature to look elsewhere.) Again, that extra functionality you’re objecting to is there to solve the problem you’re describing.
Lightbulb: The ladder and the ‘in the dark’ would apply to any light.
How about a different example. Is a car badly designed because it takes a few minutes, and a lever+jack, to change a flat tire? How about in the snow, in the dark, whilst on the side of a very busy highway?
I am happy to disagree that the ease of changing a lightbulb is high on the list of priorities when changing a light.
Mail: Happy to disagree on the usefulness of this. Not every product has to be designed with every single person in mind. As an end-user you don’t approve of mobile mail, but others end users do.
Firewall: Happy to disagree again as I don’t know enough about what purpose/segment the product was designed for originally. It does appear that the purchasers definitely did not consider the end-users properly.
Windows: With the firewall you were complaining that about ignoring possible end-user segments. And now about MS Office that they are accommodating all possible end-user segments. In office, there are a lot of features that MANY people don’t need, but I am not sure that there is anything that nobody needs. It has an amazingly broad appeal to both power users and basic users. I feel the 80-20 or 95-5 is required and does not make it bloated. MS Office is a lot more popular with end-users than MS Works is for example, a very similar product without the high-end capabilities.
I think Vista would illustrate the point a lot better. It was bulkier, slower and more complex than the end-users they targeted were prepared to accept. I think Microsoft did miss the target market on this through an incomplete understanding of what people wanted.
Another interesting point is that designing a product to do exactly what end-users want is not necessarily the best strategy, as often the end-users themselves don’t really know what they want, or why they want it.
Apple would be a great example of seemingly knowing what end-users want better than they do themselves.
On the lightbulb: say that again when you’re standing on a ladder, in the dark, trying to undo two overhead screws at an angle.
Mail: we’ll have to agree to disagree.
The firewall: again, I consider this an example of ignoring an end user category. You can disagree on who did the ignoring.
MS Office: re-read what I said. I’m not complaining about the part that works but about the part that nobody needs (I’m sure you’ve heard of the 80-20 rule, which I think is more like a 95-5 rule in practice). How do you consider it designing for the end-user if you’re building something that is not needed?
Hold on… I never said don’t eliminate “blatantly wrong”. I am all for eliminating the stupid. And, if it’s possible, yes, form a good idea of you want. Do that with code, or with picture, or with market research. I was simply trying to say that I thought your clear view heuristic was too restrictive. It’s enough to open yourself up to moment-to-moment ‘chances’ – we agree on this; empower your team to change with technology and skills training; try to establish a goal, or explore for one. I.e. do some kind of requirements analysis.
Of course, people like Google burn millions because they are searching the solution space for, they don’t know what! They are looking for the next Black Swan. But, I agree, for what we do, business systems, etc, it is possible to know roughly what you are looking for. That made me laugh with the Chrysler project – they used an explorative methodology, XP, to “search” for a solution to… replacce the existing payroll system! Naughty. When you and I did that job a few years ago, we didn’t explore too much because we knew what we were building.
Highsmith’s exploration factor might help with this chat Ben.
All the best, Jim.
“To take this discussion a step further we can consider Jim Highsmith’s exploration factors. Highsmith plots requirements against newness of technology. Bleeding edge technology and erratic requirements have a very high exploration factor. Well known requirements and technology have a low exploration factor. If you have a low exploration factor you can afford to do some up-front requirements analysis and then some up-front design. This will help your product stabalise and allow more reliable performance tests.” Taken from http://www.jamiedobson.co.uk/?q=node/25
I agree with the central point that taking into account end users is often of critical importance in product design (not always, other motivations can be stronger, profit for example), but I think you have missed the point on several of your examples.
The lightbulb: If it required a few minutes, and a screwdriver, to turn the light on and off, I would agree with you, as that is what a light is essentially designed to do (give light, turn on and off). However I disagree that the trade-off between a good looking and stylish light, and taking a few minutes to change a bulb once a year is not worth it. The changing of the bulb is not the primary user requirement. That’s like complaining that a laptop is badly designed as it takes a few minutes, and a screwdriver, to replace a stick of RAM.
Mobile Mail: It may be not be for you, but I think Blackberry etc, and the many millions of crackberry addicts around the world might just disagree with you. I think they did consider the end user and make a good product which is very widely used and becoming a standard. They got quite a jump on other companies who clearly did not consider it feasible enough, which they are clearly regretting, and still playing catch up now. Even Jamie has an iPhone which I am sure he uses for email.
The firewall: I am not sure about this one, as clearly we do not have info from the article, but perhaps the firewall was designed well for what it was written to do. Maybe some clients only want a simple firewall that is either on/off. In which case the error was not with the design, it was with the purchasers at KLM who bought an inappropriate product that was unfit for task.
The data loading application: the way you described it sounds as though the error is due to bad communication between users and developers. If the complaint was that it took too long because they had to keep swapping screens, the solution was correct. However if the complaint was that it took too long as they had to process so many, and they were nearly all the same, as well as having to switch screens, then the developer missed the point.
MS Office: The world’s best and clearly dominant office suite of software, described by you as working perfectly for nearly everybody, is somehow not designed for the end-user?
With regards to the “clear view”, I admit I took a bit of a shortcut there. But I don’t agree that you can live entireley in the moment either. The explorative process is indeed a valuable one for finding an optimal solution to the problem of the day, but it suffers the weakness of all local search methodologies: start with the wrong initial configuration and even the best local search algorithm will not help you do better than a very localized optimum that is still a far cry from the global optimum.
Some of the best improvements possible to local search algorithms are those that either limit the size of the configuration set, find an initial configuration that is likely to be the starting point of a walk to a global optimum, or both. That implies that taking a broader view a priori and eliminating blatantly wrong options early on is a very valuable tactic.
One of the thoughts that I am mulling over is that it is a question of scale. At the start of a project (what RUP refers to as the inception phase) it is a necessity to consider the feasibility of the project as a whole (specifically by asking if the project idea is realistic and truly of value, which would have severly impacted the project that resulted in that bloody lamp). But it seems to me each new twist and turn in a project (be it inception, an iteration, a new design idea or a refactoring opportunity) can and should be a chance for such a moment and welcomed as one. Any moment a new notion enters the project, I think, is not just a chance for someone to explore possibilities but to embark upon guided exploration.
I have a feeling that there is something like a V-model analogy lurking in the shadows here, but I can’t put my finger on it yet.
I am not crying over you, but that you hold me in such regards. Now, why do you think I am doubting myself? I don’t doubt myself. I won’t come right out and say I am the best software engineer in Holland, that is just silly. But, I will say this: I’ll take the Pepsi-software challenge with any mother fucker. How’s that for doubt?
I have to look deep into my prejudices, deep into what I hold sacred. In doing this I strengthen my ideas, or I discard them. I am good at what I do not in spite of this, but because of it. Success and failure are imposters, let’s never forget that.
I look forward to your response. And I am glad I got you thinking.
First of all, don’t cry — I’m not really worth crying over. If you want to cry over anything, cry over the fact that you keep doubting yourself. You are a brilliant software engineer and you make better software engineers of all the developers who work with you; it’s as simple as that. As you say, sometimes it takes time for ideas to take hold once you’ve planted them — but they always do in the end.
Regarding the critical comment, you’ve set me thinking about some things. I want to mull them over before responding; and perhaps I will make my response a new post rather than just a response. Let me get back to you….
I was gearing up to give critical feedback, but you threw me off guard with that last section. Lots of people tell me, in regards to things I have explained earlier, that only years later do they start to ‘get it’. It’s not because I am bad teacher, but because it takes at least some time for the context to be right. Once the context it set, the penny is allowed to drop. So, for example, I can explain that there is a link between leadership and gossip, I can explain, and even set up retrospectives, but, there has to be a voila moment – or as you call it, a light-bulb moment – when people really ‘get it’. For different people, this takes a differing amount of time…. it’s a process (cliche, vomit sounds coming from my desk – but it’s true).
That you are still having voila moments, more than three years since we worked together, delights me. Often mine is a thankless, frustrating, task. Gratification is delayed for years, and I am suspecting, for decades. Days like today make it worth while – you made me cry BTW, bastard. And, you are a dedicated student, so there you go.
OK, here is the critical feedback:
“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 think this is right. Local optimisation, small-picture thinking, call it what you like. The people could have benefited from doing some scenario generation, forward thinking, or whatever. Instead, probably based on a sales pitch, someone makes a snap decision and commits your company to a hemorrhage of money – buy now, pay (lots) later. As Feynman said, “don’t you have time to think”? It’s this backward, retarded thinking that costs our companies dear. All your problems may have been avoided with a couple of days critical thinking and analysis (and a decision maker with balls).
You also said,
“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.”
You know I don’t agree on this… “The Clear View” is often developed as we go. I had this with my book. You need goals, milestones and a view on what you are trying to build now, in this time-frame (whatever this may be). But, the explorative process often provides customers with something they want, even though they didn’t know what they wanted. A customer is not aware of the limitations of technology, or of more efficient processes (which we may reveal via analysis). For me, it’s enough to be strong, effective, and not afraid of change. At the point you see that what you made is wrong, change it. You can’t do this with light-bulbs, but you should be able to do it with software. It’s important to separate development as solution implementation, RUP’s construction phase, and software development as a tool to explore the solution space. If you make a strong heuristic, like the one above, that software projects need a clear view of what end users expect, then you may be constraining yourself unnecessarily. And you may never move beyond analysis. Ah, and now we are back to the original point – customers need voila, and light-bulb, moments too. They will only have that when you put something under there noses and ask, “is this what you meant”?
As always, a good read, and an excellent way to develop your ideas. I’ll link back from jamiedobson.co.uk, maybe we can get a discussion going.
Speak soon old friend, Jamie.
Knocked my socks off with knlwoegde!
Comments are closed.