Can Your Team Pass The Elevator Test?

Software developers do love to code. But very few of them, in my experience, can explain why they're coding. Try this exercise on one of your teammates if you don't believe me. Ask them what they're doing. Then ask them why they're doing it, and keep asking until you get to a reason your customers would understand.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/09/can-your-team-pass-the-elevator-test.html

You can activate Microsoft Bob from Vista. just google search. Its kinda cool

When I first started my job, I was confused why we, the programmers, would be the ones talking to the business area and writing documentation for our projects. Afterall, I just graduated college which consisted of a teacher handing us an assignment, completing it, and making sure the end product was correct, never fully understanding why we were doing it in the first place (other than to become better programmers). After a few years at my job, I’ve understood that it’s much easier to work on a project when you and the business area are on the same page. I find that I run into far less unforeseen problems in the future because all of the requirements were established from the very start. I’m glad our company has the programmers work this way.

I am 75%+ in agreement with you.

Unfortunately, there are times when it comes down to “The business said so”. Particularly when it comes to UI design, sooner or later you have to let go of the wheel and just do what the designer says.

I don’t see the problem with your first example conversation with the developer. He knows exactly what he’s doing, and all the responses are correct, and the final answer is what you’re looking for (what matters to the user). Whether someone comes up with that right away or after a few questions is irrelevant, either way they still pass your 60 second test. The problem doesn’t arise until the developer can’t tell you at all why a change request is being made.

By the way, will someone please tell Microsoft to fix THEIR sort order in Windows Explorer? Drives me absolutely nuts when outputting lots of log files.

One of your more relevant posts for coders.

Part of this comes from the need for a coder to stop worrying because they are coming up with a technical solution for a requirement which means they are closer to being done.

And, many developers are told “just write code to meet the requirements” – it’s the team lead or business analyst’s job to know why the requirements are thus – but in the meantime get that coder coding!!

Nevertheless, too many people are too anxious to start typing and get something done quickly.

@adrian you mean this
It turns out that there’s an entire functional copy of the 1995 Microsoft BOB operating system hidden inside of Windows Vista. BOB was supposed to be an …
http://technabob.com/blog/2007/04/01/windows-vista-easter-egg-discovered/
HA HA

BTW great blog Jeff !

The addicts talk mentions 50% of software developers as addicts. Well there is another issue, it may go side by side with addiction and sometimes is the cause for that addiction, sometimes it is the sole reason why one became a coder. Just like some doctors (i.e. surgeons) are natural born butchers and killers, that transformed their “need for blood” to something good, beneficial for society, like treating people, and bringing them back to life. Same way some software developers deep inside are just natural dictators with extreme need to control and achieve absolute obedience/submission from somebody or something. And writing software is one of the socially accepted activities that such needs can be satisfied with, when coder has total control over and strict obedience of the machine. It may sound ridiculous, but that’s true for some coders.

I think the point Jeff is making is that if you can’t easily/quickly (with a little prompting) summarize what your working on means to the customer and how it benefits them then you are likely not working to the benefit of the customer, which in reality tends to be the whole reason you are coding anyway (in the broad scope of things).

I’m getting plenty of practice with pitching what I’m doing to different levels. My mum often asks what I’m doing, and I have to explain in quite low level terms. My girlfriend asks, and I get to elaborate a bit more (only because she has more patience) but still have to be careful.

Jeff: I wonder if you can fix this blog annoyance? When I read Coding Horror, I tend to hit the first page, and then read through the entries. When I get to the bottom, I click on the “Read older entries” link at the bottom.

Unfortunately, that link doesn’t take me to a page of your older entries, instead it takes me to a specific entry. I can’t easily navigate through your posts in reverse chronological order, as much as I would like to.

Would you please fix this?

My job is most certainly not to solve customer’s problems. Why? Because customers are idiots. One step removed from a customer is a tester, who knows just enough of what they’re talking about to be a tremendous pain in the ass on top of being an idiot.

My job is to take a problem and solve it. It’s up to product/project/program management to define that problem if it originates from an outside source (and I’m including testers in ‘outside’).

It’s bad enough that upper management will make promises to people that are not easily kept by the people that have to implement them. It’s worse then when you think that it’s my responsibility to have anything to do with the customer.

Jeff - I like your writing style, and tend to agree with your ideas most of the time. This is not one of those times.

What happens when you work in a large corporate structure and your project is not a customer facing one. Rather, your project involves building/maintaining a data repository, managing requests of some sort or another, providing web service access to some piece of data or another, etc. Now, your customers are other products within your company. You, as the developer, will know that you need to build a new method that will take in x and y, and then using those build a custom formatted return of v and w, sending an audit/billing record to z. You have no knowledge of what v and w are going to be used for or why they are needed, where x and y came from, or what z plans to charge if anything. Not only that, but you have no reason to know either.

Developers in my group can and will give you such answers to your why questions as “it was on my list of requirements for group X”. If they didn’t, nothing would ever get done.

I think you are confusing a developer in a small shop to a developer anywhere when you make your assumptions about what someone should and should not know.

What are you working on?
I’m fixing the sort order on this datagrid. (ok go away now, i am using the subtle body language cue of staring at an ide and typing, to indicate that i am concentrating)

Why are you working on that?
Because it’s on the bug list. (oh no, here we go… did your boss ask you to write him a status report? i’m working on it because it was assigned to me by you, our bug tracking system has been taking care of this stuff efficiently for months)

Why is it on the bug list?
Because one of the testers reported it as a bug. (wtf management by walking around? someone kicked you out of your office to use as a meeting room again? we showed you the button to click to get status reports from the bug reporting system, go play with your powerpoint, then i can close this one and make both of our stats look better)

Why was it reported as a bug?
The tester thinks this field should sort in numeric order instead of alphanumeric order. (that’s what it says here in the bug reporting system)

Why does the tester think that?
Evidently the users are having trouble finding things when item 2 is sorted under item 19. (it’s 3pm on friday and i want to finish up, it is worrying that you don’t understand enough about this project to know why sorting data in the wrong order on this screen would be bad. i am trying to stay polite but my adrenal system is worn out from taking it from all sides. if you are implying that i screwed up, please just say so instead of putting me through the wringer, because I’ll admit it straight off. or was that a trick question?)

@Rob

Sorry, but I agree with Jeff - even though I work on data processing apps deep in the heart of very large companies, the most sucessful projects are those where we have a clear connection and regular contact with the end user. The hardest ones are where the developers are insulated by layers of architects, designers and business people who will not actaully use the data we produce.

let go of the wheel and just do what the designer says

Wouldn’t you also want to understand why the designer says to do something?

The addicts talk mentions 50% of software developers as addicts.

What he’s referring to is the 15 minute video linked at the bottom of the post. All the good stuff is in the first 10 minutes:
http://video.google.com/videoplay?docid=-317659265568822821

many–probably most–developers have no need to explain their work to a layperson

Really? So the auto mechanic doesn’t need to explain to the driver what’s wrong with their vehicle, and why it will cost $1000? And the doctor doesn’t need to explain to the patient why they need surgery, or medicine, or lifestyle changes?

There is nothing strange about the conversation you quote

The last answer should have been the first answer-- eg, I’m fixing the datagrid sort order, because it’s confusing our users. Get your mind right. Frame your work in terms of benefit to the customer/user. You build a house intending for people to live in it; similarly, you build software intending for people to use it.

limited to the very narrow world of consumer product design.

Everyone has users. Everyone has customers. The difference between successful and unsuccessful software is that the teams who are successful frame all their work in the context of service to their audience. Without an audience, what’s the point?

However the best of teams also have people devoted to the technology

The best technologists tend to be the best communicators, people in tune with the overall product vision – they don’t just quietly squirrel away on technology in a lab, they’ll happily tell you why that technology they’re working on will let the users kick ass. That’s part of the vision statement-- and it’s something every developer should be able to do.

Excellent post, Jeff! I recently got a new job and will be inheriting some young coders. I have printed off several copies of this and intend to hand it out when I start working.

good post

I remember once complaining about co-workers not focusing on the software product our company was depending on. But then a friend of mine said; "do you put yourself in their place? Do you look at what the sales, economic or hr guy is doing? "

It is so easy to just sit on your chair, writing your silly code and complain about everyone not understanding what you are doing. I remember working at places where people would not put new paper in the printer because it was not their job, administrators would not help with the server because it was not their responsibility, and so on…

Communication is very important.
http://www.linuxkungfu.org/images/fun/geek/project.jpg
(old, but very good and so very true)

Almost everybody wants to show how great they are, maybe they want to show that greatness in their code or in the salary, but why not show their greatness in being the one that makes the solution a success. Be the one that connect the dots and makes coming to work a joy.

Maybe someday when we are all “professional software engineers” we can live up to one tenet of the Code of Ethics for professional engineers that states:

“8) present clearly to employers and clients the possible consequences if professional decisions or judgments are overruled or disregarded”

http://softwareindustrialization.com/PreparingTheWorldForSoftwareEngineeringPart2.aspx

Saying that a programmer’s job is not to write code is disingenuous. It’s like saying that a construction worker’s job is not to build a house, but to make sure that the customer has a warm place to sleep. This is wrong. The decision has already been made. The worker WAS hired to build a house.

As usual, Jeff, your opinions reflect the environment you work in, and the type of software you make. I refer you to Joel’s “Five Kinds of Software”.
Not all software has users in the normal sense of the word. Many programs are not desktop or web applications. Who is the user of a router’s software? A car’s computer? An automatic fruit sorting machine’s software? Who are the users of a bank’s HUGE software base? The customers? The tellers? Maybe OTHER pieces of software are the users?
Much of the software in the world does not interact with people at all. And when it does, those people have almost no control over it, no more than they can control the airplane they are traveling on (and even the pilots only have SOME control over an aircraft’s software).

It is quite common for many programmers to be unable to easily explain what they are doing, since their job is the guts of software, and they work with abstract ideas. This is especially true if you work in the kind of software place where the software is extremely complicated, requiring dozens of programmers and many layers of abstraction.
It is also common in places where the person buying the product doesn’t really know or care there’s software inside (like a router).

“Customer: What are you working on?
Programmer: I’m building a lock-free linked list implementation”.
“Customer: Huh!? what does that even mean? I’m paying you to build me a request processing server”
…10 to 20 minutes of explanations later (assuming the programmer is REALLY REALLY good at explaining complex, abstract ideas to laypeople):
“Customer: So how will that even help me?”
“Programmer: Your server will be able to function well enough when the expected 1000 people will work on it”.

This is of course an imaginary conversation. Not one customer in 50 will agree to be subjected to such a complex explanation. Nor should they.
I don’t care WHY my auto mechanic needs to replace the flux capacitor coils. Tell me what was wrong with the car, and if it’s complicated, it doesn’t matter. Just make it work, and tell me how much it costs (this assumes I trust my auto mechanic, but in the world of software, we generally do trust the programmers).
This is also why customers and programmers are sometimes separated, and communicate through special channels (like analysts, requirements, a customer’s representative, etc…).

I do agree that it’s very important for developers to know WHAT they are working on, and why, and all that jazz. I just don’t think it’s that important for those reasons.

Finally, the BEST technologies are sometimes excellent communicators, but not all of us are Peter Norvig. Many amazingly excellent technologists and developers are in fact quite poor communicators (at least to non-technical people). However, since they make software and generally need to communicate to technical people, that’s not a real problem.

i have to mostly disagree. i think that the developer should be rock-solid in touch with customer needs, but i certainly don’t think that he should need or want to be able to answer questions at a moment’s
notice to satisfy a coworker in, say, marketing. that just exacerbates the reality that the technologists are being told what to do by the non-technologists.

it’s more of a management issue – the guys changing the ball bearings out on an airplane wheel shouldn’t need to have clean hands and a cheery smile when the president of the airline drops by to ask about how much they love customer service. they should simply be the best damn ball-bearing replacement guys in the world. and the guy who is their boss should be busy sucking up to his boss to save them the agony of having to do so. that’s why management jobs suck so much, and why there will always be jobs “in the trenches”.

one sentiment as expressed i agree with, and that’s that everyone should keep customer needs in mind. but it is certainly a marketing/sales mentality to pretend that design-the-box exercises have anything at all to do with whether or not the sorted list actually gets fixed. anyone can design a box, even if only semi-poorly. not anyone can fix the sort. don’t require the guys who know how to fix the sort to learn to smile if the guys who know how to smile can’t learn how to fix the sort.

nobody likes to hear, “be more like me because i can’t be more like you.”

s.