can your team pass the elevator test: programmers
DESCRIPTION
this writing is for programmers and potential coders who are in the industry of software engineering. this article was copied from the internet. i own no rights.TRANSCRIPT
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 1/30
CODING HORRORprogramming and human factors
Zap software errors!Get notified of softwarebugs as they happenwith Raygun.io
ads via Carbon
Senior Software Engineer Mobile (iOS)Wingify SoftwareDelhi, India / relocationios swift
Java Lead Engineer @ a GlobalSaaS product startupZapStitchBangalore, Indiajavaee springmvc
[ad] Enjoy the blog?Read EffectiveProgramming: Morethan Writing Codeand How to StopSucking and BeAwesome Insteadon your Kindle, iPad,Nook, or as a PDF.
RESOURCESAbout [email protected]
26 Sep 2007
Can Your Team PassThe Elevator Test?Software developers do love to code. But very few ofthem, in my experience, can explain why they'recoding. Try this exercise on one of your teammates ifyou don't believe me. Ask them what they're doing.Then ask them why they're doing it, and keep askinguntil you get to a reason your customers wouldunderstand.
What are you working on?I'm fixing the sort order on this datagrid.
Why are you working on that?Because it's on the bug list.
Why is it on the bug list?Because one of the testers reported it as a bug.
Why was it reported as a bug?The tester thinks this field should sort in numeric
order instead of alphanumeric order.
Why does the tester think that?Evidently the users are having trouble finding things
when item 2 is sorted under item 19.
If this conversation seems strange to you, youprobably haven't worked with many software
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 2/30
stackexchange.comRecommendedReading
Subscribe in areader Subscribe via email
Coding Horror has beencontinuously publishedsince 2004
Traffic Stats
Copyright Jeff Atwood ©2014Logo image © 1993 StevenC. McConnell Proudly published withGhost
developers. Like the number of licks it takes to get tothe center of a tootsie pop, it might surprise you justhow many times you have to ask "why" until you getto something-- anything-- your customers wouldactually care about.
It's a big disconnect.
Software developers think their job is writingcode. But it's not.* Their job is to solve thecustomer's problem. Sure, our preferred medium forsolving problems is software, and that does involvewriting code. But let's keep this squarely in context:writing code is something you have to do to deliver asolution. It is not an end in and of itself.
As software developers, we spend so much timemired in endless, fractal levels of detail that it's all tooeasy for us to fall into the trap of coding for the sakeof coding. Without a clear focus and something to rallyaround, we lose the context around our code. That'swhy it's so important to have a clear project visionstatement that everyone can use as a touchstone onthe project. If you've got the vision statement down,every person on your team should be able to passthe "elevator test" with a stranger -- to clearlyexplain what they're working on, and why anyonewould care, within 60 seconds.
If your team can't explain their work to a layperson ina meaningful way, you're in trouble, whether yourealize it or not. But you are in good company. JimHighsmith is here to help. He explains a quick formulafor building a project vision model:
A product vision model helps team members pass
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 3/30
the elevator test -- the ability to explain theproject to someone within two minutes. It comesfrom Geoffrey Moore's book Crossing the Chasm.It follows the form:
for (target customer)
who (statement of need or opportunity)
the (product name) is a (product category)
that (key benefit, compelling reason to buy)
unlike (primary competitive alternative)
our product (statement of primary
differentiation)
Creating a product vision statement helps teamsremain focused on the critical aspects of theproduct, even when details are changing rapidly. Itis very easy to get focused on the short-termissues associated with a 2-4 week developmentiteration and lose track of the overall productvision.
I'm not a big fan of formulas, because they're so, well,formulaic. But it's a reasonable starting point. PlayMad Libs and see what you come up with. It's worldsbetter than no vision statement, or an uninspiring,rambling, ad-hoc mess masquerading as a visionstatement. However, I think Jim's second suggestionfor developing a vision statement holds much morepromise.
Even within an IT organization, I think everyproject should be considered to produce a"product." Whether the project results involveenhancements to an internal accounting systemor a new e-commerce site, product-orientedthinking pays back benefits.
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 4/30
One practice that I've found effective in gettingteams to think about a product vision is theDesign-the-Box exercise. This exercise is great toopen up a session to initiate a project. The teammakes the assumption that the product willbe sold in a shrink-wrapped box, and theirtask is to design the product box front andback. This involves coming up with a productname, a graphic, three to four key bullet points onthe front to "sell" the product, a detailed featuredescription on the back, and operatingrequirements.
Coming up with 15 or 20 product features provesto be easy. It's figuring out which 3 or 4 wouldcause someone to buy the product that is difficult.One thing that usually happens is an intensediscussion about who the customers really are.
Design-the-Box is a fantastic way to formulate a visionstatement. It's based on a concrete, real worldconcept that most people can easily wrap their headsaround. Forget those pie-in-the-sky vision quests:what would our (hypothetical) product box looklike?
We're all consumers; the design goals for a productbox are obvious and universal. What is a product box ifnot the ultimate elevator pitch? It should...
Explain what our product is in the simplestpossible way.Make it crystal clear why a potential customerwould want to buy this product.Be uniquely identifiable amongst all the otherboxes on the shelf.
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 5/30
Consider the box for the ill-fated Microsoft Bobproduct as an example. How do you explain whycustomers should want Microsoft Bob? How wouldyou even explain what the heck Microsoft Bob is?
It's instructive to look at existing product boxes youfind effective, and those you find ineffective. Wedefinitely know what our product box shouldn't look
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 6/30
Continue Discussion 78 repliesSep '07
like.
Have a rock solid vision statement for your projectfrom day one. If you don't, use one of Jim's excellentsuggestions to build one up immediately. Without acoherent vision statement, it's appalling howmany teams can't pass the elevator test-- theycan't explain what it is they're working on, or whyit matters. Don't make that same mistake. Get a kick-ass vision statement that your teammates can relatetheir work to. Make sure your team can pass theelevator test.
* Completely stolen from Billy Hollis' great 15-minutesoftware addicts talk.
Related posts
Recommended Reading for DevelopersThe Ultimate Dogfooding StoryFive Things You Didn't Know About Me (and myoffice)No Matter What They Tell You, It's a PeopleProblemConcluding the Great MP3 Bitrate Experiment
Written by Jeff Atwood
Indoor enthusiast. Co-founder of Stack Exchange and
Discourse. Disclaimer: I have no idea what I'm talking
about. Find me here: http://twitter.com/codinghorror
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 7/30
AdrianC
You can activate Microsoft Bob from Vista. just google search.Its kinda cool
Sep '07
Mike
When I first started my job, I was confused why we, theprogrammers, would be the ones talking to the business area andwriting documentation for our projects. Afterall, I just graduatedcollege 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 atmy job, I've understood that it's much easier to work on a projectwhen you and the business area are on the same page. I find thatI run into far less unforeseen problems in the future because allof the requirements were established from the very start. I'm gladour company has the programmers work this way.
Sep '07
RobertF
I am 75%+ in agreement with you.
Unfortunately, there are times when it comes down to "Thebusiness said so". Particularly when it comes to UI design,sooner or later you have to let go of the wheel and just do whatthe designer says.
Sep '07
Leo11
I don't see the problem with your first example conversationwith the developer. He knows exactly what he's doing, and allthe responses are correct, and the final answer is what you'relooking for (what matters to the user). Whether someone comesup with that right away or after a few questions is irrelevant,either way they still pass your 60 second test. The problem
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 8/30
either way they still pass your 60 second test. The problemdoesn't arise until the developer can't tell you at all why a changerequest is being made.
By the way, will someone please tell Microsoft to fix THEIRsort order in Windows Explorer? Drives me absolutely nutswhen outputting lots of log files.
Sep '07
Steve
One of your more relevant posts for coders.
Part of this comes from the need for a coder to stop worryingbecause they are coming up with a technical solution for arequirement which means they are closer to being done.
And, many developers are told "just write code to meet therequirements" it's the team lead or business analyst's job toknow why the requirements are thus but in the meantime getthat coder coding!!
Nevertheless, too many people are too anxious to start typingand get something done quickly.
Sep '07
Mythbuster
@adrian you mean thisIt turns out that there’s an entire functional copy of the 1995Microsoft BOB operating system hidden inside of WindowsVista. BOB was supposed to be an ...http://technabob.com/blog/2007/04/01/windowsvistaeastereggdiscovered/ HA HA
BTW great blog Jeff !
Sep '07
workaholicus
The addicts talk mentions 50% of software developers asaddicts. Well there is another issue, it may go side by side withaddiction and sometimes is the cause for that addiction,
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 9/30
addiction and sometimes is the cause for that addiction,sometimes it is the sole reason why one became a coder. Justlike some doctors (i.e. surgeons) are natural born butchers andkillers, that transformed their "need for blood" to somethinggood, beneficial for society, like treating people, and bringingthem back to life. Same way some software developers deepinside are just natural dictators with extreme need to control andachieve absolute obedience/submission from somebody orsomething. And writing software is one of the socially acceptedactivities that such needs can be satisfied with, when coder hastotal control over and strict obedience of the machine. It maysound ridiculous, but that's true for some coders.
Sep '07
ICR81
I think the point Jeff is making is that if you can't easily/quickly(with a little prompting) summarize what your working onmeans to the customer and how it benefits them then you arelikely not working to the benefit of the customer, which inreality tends to be the whole reason you are coding anyway (inthe broad scope of things).
I'm getting plenty of practice with pitching what I'm doing todifferent levels. My mum often asks what I'm doing, and I haveto explain in quite low level terms. My girlfriend asks, and I getto elaborate a bit more (only because she has more patience) butstill have to be careful.
Sep '07
Dave_Cannon
Jeff: I wonder if you can fix this blog annoyance? When I readCoding Horror, I tend to hit the first page, and then read throughthe entries. When I get to the bottom, I click on the "Read olderentries" link at the bottom.
Unfortunately, that link doesn't take me to a page of your olderentries, instead it takes me to a specific entry. I can't easilynavigate through your posts in reverse chronological order, asmuch as I would like to.
Would you please fix this?
Sep '07
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 10/30
GeorgeS
My job is most certainly not to solve customer's problems. Why?Because customers are idiots. One step removed from acustomer is a tester, who knows just enough of what they'retalking about to be a tremendous pain in the ass on top of beingan idiot.
My job is to take a problem and solve it. It's up toproduct/project/program management to define that problem if itoriginates from an outside source (and I'm including testers in'outside').
It's bad enough that upper management will make promises topeople that are not easily kept by the people that have toimplement them. It's worse then when you think that it's myresponsibility to have anything to do with the customer.
Sep '07
Vince
Jeff I like your writing style, and tend to agree with your ideasmost of the time. This is not one of those times.
What happens when you work in a large corporate structure andyour project is not a customer facing one. Rather, your projectinvolves building/maintaining a data repository, managingrequests of some sort or another, providing web service access tosome piece of data or another, etc. Now, your customers areother products within your company. You, as the developer, willknow that you need to build a new method that will take in xand y, and then using those build a custom formatted return of vand w, sending an audit/billing record to z. You have noknowledge of what v and w are going to be used for or whythey are needed, where x and y came from, or what z plans tocharge if anything. Not only that, but you have no reason toknow either.
Developers in my group can and will give you such answers toyour why questions as "it was on my list of requirements forgroup X". If they didn't, nothing would ever get done.
I think you are confusing a developer in a small shop to adeveloper anywhere when you make your assumptions aboutwhat someone should and should not know.
Sep '07
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 11/30
vortexo
What are you working on?I'm fixing the sort order on this datagrid. (ok go away now, i amusing the subtle body language cue of staring at an ide andtyping, 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 bossask you to write him a status report? i'm working on it because itwas assigned to me by you, our bug tracking system has beentaking 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 managementby walking around? someone kicked you out of your office touse as a meeting room again? we showed you the button to clickto get status reports from the bug reporting system, go play withyour powerpoint, then i can close this one and make both of ourstats look better)
Why was it reported as a bug?The tester thinks this field should sort in numeric order instead ofalphanumeric order. (that's what it says here in the bug reportingsystem)
Why does the tester think that?Evidently the users are having trouble finding things when item2 is sorted under item 19. (it's 3pm on friday and i want to finishup, it is worrying that you don't understand enough about thisproject to know why sorting data in the wrong order on thisscreen would be bad. i am trying to stay polite but my adrenalsystem is worn out from taking it from all sides. if you areimplying that i screwed up, please just say so instead of puttingme through the wringer, because I'll admit it straight off. or wasthat a trick question?)
Sep '07
AdrianM
@Rob
Sorry, but I agree with Jeff even though I work on dataprocessing apps deep in the heart of very large companies, themost sucessful projects are those where we have a clearconnection and regular contact with the end user. The hardestones are where the developers are insulated by layers ofarchitects, designers and business people who will not actaullyuse the data we produce.
Sep '07
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 12/30
Sep '07
codinghorror
let go of the wheel and just do what the designer says
Wouldn't you also want to understand why the designer says todo something?
The addicts talk mentions 50% of software developers asaddicts.
What he's referring to is the 15 minute video linked at the bottomof the post. All the good stuff is in the first 10 minutes:http://video.google.com/videoplay?docid=317659265568822821
manyprobably mostdevelopers have no need to explain theirwork to a layperson
Really? So the auto mechanic doesn't need to explain to thedriver what's wrong with their vehicle, and why it will cost$1000? And the doctor doesn't need to explain to the patientwhy 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'mfixing the datagrid sort order, because it's confusing our users.Get your mind right. Frame your work in terms of benefit to thecustomer/user. You build a house intending for people to live init; 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 differencebetween successful and unsuccessful software is that the teamswho are successful frame all their work in the context of serviceto their audience. Without an audience, what's the point?
However the best of teams also have people devoted to thetechnology
The best technologists tend to be the best communicators, peoplein tune with the overall product vision they don't just quietlysquirrel away on technology in a lab, they'll happily tell you whythat technology they're working on will let the users kick ass.That's part of the vision statement and it's something everydeveloper should be able to do.
Sep '07
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 13/30
Frank
Excellent post, Jeff! I recently got a new job and will beinheriting some young coders. I have printed off several copiesof this and intend to hand it out when I start working.
Sep '07
PeterP
good post
I remember once complaining about coworkers not focusing onthe software product our company was depending on. But then afriend of mine said; "do you put yourself in their place? Do youlook at what the sales, economic or hr guy is doing? "
It is so easy to just sit on your chair, writing your silly code andcomplain about everyone not understanding what you are doing.I remember working at places where people would not put newpaper in the printer because it was not their job, administratorswould not help with the server because it was not theirresponsibility, 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, maybethey want to show that greatness in their code or in the salary,but why not show their greatness in being the one that makes thesolution a success. Be the one that connect the dots and makescoming to work a joy.
Sep '07
Mitch
Maybe someday when we are all “professional softwareengineers” we can live up to one tenet of the Code of Ethics forprofessional engineers that states:
“8) present clearly to employers and clients the possibleconsequences if professional decisions or judgments areoverruled or disregarded”
http://softwareindustrialization.com/PreparingTheWorldForSoftwareEngineeringPart2.aspx
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 14/30
Sep '07
M1157
Saying that a programmer's job is not to write code isdisingenuous. It's like saying that a construction worker's job isnot to build a house, but to make sure that the customer has awarm place to sleep. This is wrong. The decision has alreadybeen made. The worker WAS hired to build a house.
As usual, Jeff, your opinions reflect the environment you workin, and the type of software you make. I refer you to Joel's "FiveKinds of Software".Not all software has users in the normal sense of the word.Many programs are not desktop or web applications. Who is theuser of a router's software? A car's computer? An automatic fruitsorting machine's software? Who are the users of a bank'sHUGE software base? The customers? The tellers? MaybeOTHER pieces of software are the users?Much of the software in the world does not interact with peopleat all. And when it does, those people have almost no controlover it, no more than they can control the airplane they aretraveling on (and even the pilots only have SOME control overan aircraft's software).
It is quite common for many programmers to be unable to easilyexplain what they are doing, since their job is the guts ofsoftware, and they work with abstract ideas. This is especiallytrue if you work in the kind of software place where thesoftware is extremely complicated, requiring dozens ofprogrammers and many layers of abstraction.It is also common in places where the person buying the productdoesn't really know or care there's software inside (like a router).
"Customer: What are you working on? Programmer: I'm building a lockfree linked listimplementation"."Customer: Huh!? what does that even mean? I'm paying you tobuild me a request processing server"...10 to 20 minutes of explanations later (assuming theprogrammer is REALLY REALLY good at explainingcomplex, abstract ideas to laypeople):"Customer: So how will that even help me?""Programmer: Your server will be able to function well enoughwhen the expected 1000 people will work on it".
This is of course an imaginary conversation. Not one customerin 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 fluxcapacitor coils. Tell me what was wrong with the car, and if it'scomplicated, it doesn't matter. Just make it work, and tell me
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 15/30
complicated, it doesn't matter. Just make it work, and tell mehow much it costs (this assumes I trust my auto mechanic, but inthe world of software, we generally do trust the programmers).This is also why customers and programmers are sometimesseparated, and communicate through special channels (likeanalysts, requirements, a customer's representative, etc...).
I do agree that it's very important for developers to knowWHAT they are working on, and why, and all that jazz. I justdon't think it's that important for those reasons.
Finally, the BEST technologies are sometimes excellentcommunicators, but not all of us are Peter Norvig. Manyamazingly excellent technologists and developers are in factquite poor communicators (at least to nontechnical people).However, since they make software and generally need tocommunicate to technical people, that's not a real problem.
Sep '07
steveu
i have to mostly disagree. i think that the developer should berocksolid in touch with customer needs, but i certainly don'tthink that he should need or want to be able to answer questionsat a moment's notice to satisfy a coworker in, say, marketing. that justexacerbates the reality that the technologists are being told whatto do by the nontechnologists.
it's more of a management issue the guys changing the ballbearings out on an airplane wheel shouldn't need to have cleanhands and a cheery smile when the president of the airline dropsby to ask about how much they love customer service. theyshould simply be the best damn ballbearing replacement guys inthe world. and the guy who is their boss should be busy suckingup to his boss to save them the agony of having to do so. that'swhy management jobs suck so much, and why there will alwaysbe jobs "in the trenches".
one sentiment as expressed i agree with, and that's that everyoneshould keep customer needs in mind. but it is certainly amarketing/sales mentality to pretend that designtheboxexercises have anything at all to do with whether or not thesorted list actually gets fixed. anyone can design a box, even ifonly semipoorly. not anyone can fix the sort. don't require theguys who know how to fix the sort to learn to smile if the guyswho 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 morelike you."
s.
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 16/30
s.
Sep '07
MatthewC
The answer to the question depends upon who asked it.
Technically minded folks might want to know about the detailsin the weeds.Status report filers might want to know what they can put on thereport.End users might want to know if the reconcile checkbookfeature is working yet.
If I'm working on the 'reconcile checkbook' feature, and I'mabout 1/2 done with it and I'm working on some DataGrid orcreating a user control, I ought to be able to figure out whichanswer is appropriate for the audience.
Doesn't seem like rocket science to me, but evidently it is.
Sep '07
Nick
I have a few problems with this.
First, abstraction is the key to developing software. It may wellbe good to know what business purpose the method you aredebugging fills, but when you are down in the trenches workingin the code, you can't be thinking about all that. All you need tobe thinking about is "I am getting input x, I am supposed toreturn value y, but instead I'm returning value z". If instead youare too busy thinking about what high level function the user istrying to perform, you are never going to get the job done.
Second, as mentioned several times, a lot of software doesn'tface customers at all. What if you are developing a frameworkthat is being used by other developers? You don't need to knowwhat business purpose the user of your framework is filling,your work should should be independent of that. In fact, if youare too focused on how a particular developer is using yourcode, that can lead to make it too specific to that particularpurpose and not reusable for other developers.
Third, many changes that are made have no impact at all on thecustomer. For instance updating outdated or missing comments,fixing the code to match general coding conventions, and ingeneral cleaning up code.
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 17/30
general cleaning up code.
And fourth, if you think the project manager/architect/whoeverwrote the high level designs did a bad job and you don't think acustomer will ever use what you are told to design, you can't justthrow away your assignment and work on something else. Thatwill just lead you to losing your job. And its perfectly possiblethat your project manager is not the idiot you think he is andsimply knows more about the business than you.
Sep '07
KashifS
Jeff,
Not all of us develop products for customers to use. Some timewe sell a product to OEM customers, who then sell it otherOEMs, and etc before it gets to a customer.
So we're severely removed from the customer. And I hate that,because you end up designing software for "some customer"who might need feature A,B,C,D,E,F,G. When in reality, all thecustomer needed were features A, C, and G.
Kashif
Sep '07
ICR82
As some people have said, amongst the mass of "we don't allwrite for customers", you can replace customer with any enduser of the product (Surely you have one. If not, why the hell areyou writing it?) If you don't know how you are writing isbenifiting them then more than likely what you are writing isn'tbenfititing them.
Are people really living in a bubble of "spec in, code out"without any context what so ever? You don't even know who isgoing to use the code, where it is going to be used or how?That's just scary.It seems most of you people need to learn how to stop takingthings so literaly and be able to apply them to wider situations.
Sep '07
Chris
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 18/30
Chris
Wow. I work with tons of software developers, and not a singleone would ever answer "because it's on the bug list." We allknow why we're doing our tasks, even if we think the reason isstupid ("the users want a nonlinear way to get to this option, butonce I implement they'll see that it's really impractical to goanother way").
For me, giving responses like those you started the post withwould be an immediate red flag that this employee is not goingto be very useful much longer.
Sep '07
John
Completely agree with Chris above. The conversation onlyhappens with a slow learner. The very first thing a programmerwho was given a bug would do is to verify the legitimacy of thebug. So the answer of sorting by numeric order should comequickly.
Sep '07
Catto
Hey Now Jeff,This is a great post, I like the answer it's on the bug list. You areso right our job is not to write code, it's to provide solutions.Coding Horror Fan,Catto
Sep '07
BrianC
I love working with software (and hardware) engineers becauseof the concrete, inward looking, utterly absorbing, manylayeredwork they do. With an artificial language built on top of anextremely limited instruction set, they create something that cantalk to a machine and make things happen.
That’s it: that’s the transaction at the heart of writing code.
To do this at a very high level requires a kind of attention,
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 19/30
concentration, and devotion that is practically religious in nature.It’s not uncommon to see a certain species of engineer lose theability to speak coherently after a few hours of writing code.
This is not “project management mind” nor is it “whyarewedoingthis mind”. It is a state of rapt attention and intention moreaptly compared to the spiritual or aesthetic mind found in prayer,meditation, art, or sport. To characterize this as a primitive stateof mind is not to say it’s simple or unsophisticated, as GarySnyder points out in his great essay “Poetry and the Primitive”,but to say it’s been with us from the beginning.
The primitive mind and its attendant joy in naming and makingcan of course be domesticated or cultivated for economic gain(LeviStrauss, via Snyder) as surely as wild pigs or prairie. Thisis exactly what most of us are doing, as we sit in our cubes oroffices amidst the great expanse of our multinationalcorporations or the more scaled down hillsides and vallies ofsmaller companies and startups.
Within these organizations, there are still thickets where the wildmind survives, and even thrives, and software engineering is oneof those great preserves. Bill Gates’ (possibly only) genius is thathe understood how to attract that kind of mind, then tame it tothe end of making money.
When a human being writes a poem, makes a song, or tries totame the wild machine, (s)he partakes in a primitive wonder thatknows no remuneration (often quite literally). Oddly, it is thissame human being an organization turns to with its mostintransigent technical issues. No matter how erudite, facile atabstraction, or managerially converted we become, there is still aside of us that knows the real work of making. Yes, there arestill worlds where no explanation is required.
Sep '07
Jeremy
@MI think you missed the point. First off he said softwaredevelopers, not programmers. To me a programmer is JoeyUndergrad, fresh from the Uni. with his BS in one hand and akeyboard in the other. We were all "programmers" at one timeor another, I know. But if we are any good at our profession weslowly become proactive in development and graduate tobecome developers.
Secondly, the comment on how we don't all need to be greatcommunicators to be effective programmers. You're absolutelyright. But at some point someone has to communicate with auser. To me Jeff's articles seem geared more towardsprofessional growth. Yeah, I could fortup in my cube churning
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 20/30
professional growth. Yeah, I could fortup in my cube churningout assembly optimized code all day or I could hire someoneelse to do that and I could go deal with customers so that wehave money to allow people to code. That makes me a betterdeveloper and my resale value in the industry goes up.
Sep '07
Jeremy
@MI think you missed the point. First off he said softwaredevelopers, not programmers. To me a programmer is JoeyUndergrad, fresh from the Uni. with his BS in one hand and akeyboard in the other. We were all "programmers" at one timeor another, I know. But if we are any good at our profession weslowly become proactive in development and graduate tobecome developers.
Secondly, the comment on how we don't all need to be greatcommunicators to be effective programmers. You're absolutelyright. But at some point someone has to communicate with auser. To me Jeff's articles seem geared more towardsprofessional growth. Yeah, I could fortup in my cube churningout assembly optimized code all day or I could hire someoneelse to do that and I could go deal with customers so that wehave money to allow people to code. That makes me a betterdeveloper and my resale value in the industry goes up.
Sep '07
Dave_Markle
Great article. I'm going to really start writing vision statementsfrom now on. I'll admit, I'd neglected them...
Bob is an example of sooo many things that could go wrong inthe design of a product, but it really came down to stupidarrogance MS devs and management thinking they knewbetter than their clients, and that's why we mock MS so forreleasing this product. Their vision statement may have gonesomething like this:
for BEGINNING COMPUTER USERSwho WANT TO BE PRODUCTIVE ON THEIRCOMPUTERSthe MS BOB PRODUCT is a ALLINONE SUITEthat MAKES IT EASIER TO USE YOUR MACHINEunlike WINDOWS EXPLORER AND OFFICE
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 21/30
our product HAS AN ANIMATED DOG
Sep '07
DaveS
I wrote about this sort of thing a while back and coined it thejournalism model (TRADEMARK!!!!!).If your developers can't explain the who/what/when/why/whereof what they're developing, I see it as a management problem.My understanding of the problem set that I'm working to solvedoesn't come from the ether.I can give a better elevatorlevel description of what I'm doingand why when I've been involved in the project from itsinception than when I've had a requirements document the sizeof a telephone book dropped in my lap.You can't always have all your developers from start to finish,and that's where managers hypothetically come in they keep amental model of what needs to be done and keep people ontrack and excited about what they're doing (given all that yes Isaid hypothetically). I don't have much confidence that, were I toturn the tables, some managers would be able to pass theelevator test I posed to them either.http://48klocs.blogspot.com/2007/07/softwaredevelopmentjournalismmodel.html
Sep '07
Wayne
A very famous philospoher, mathemetician, inventor once said:"Please excuse the length of this letter, I did not have the time tomake it short."
Those words are attributed to Blaise Pascal. What he was gettingat is the crux of this blog post... If you can't explain something ina quick conversation, email, letter, etc... you don't have a deepunderstanding of what you are doing.
For the past 12 years, I have been a software developer in avariety of industries from car insurance, fiber optic management,retail market research, and even crop insurance data mining. Ateach of the places I have worked, I have generally spent 34weeks up front just learning what the company did and why.That allowed me to frame my development efforts around whatwe are calling a vision... but in the broader sense of theorganization, not just the application.
In all things, I try to work so that any explanation about the
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 22/30
software (or the organization) would be such that a 9 year oldcould get the idea... Now that I work for the government, I havelowered that expectation to 6 year old!
Sep '07
sldr
The conversation at the top of this page is the process ofbreaking a developer's train of thought while they are gettinguseful work done.
Sep '07
Neil
I think the disconnect that some of the posters here have withJeff's article is that the customer can be technical and have noproblem with technical jargon. For instance, the customer ofrouter software is the router manufacturer (the one paying for thework), not necessarily the enduser. I'm sure that Cisco iscompletely invested and interested in every aspect of the codethat is programmed for them.
I think is some cases the "customer" of a piece of code is theproject manager. If a PM breaks down a coding problem into aset of abstract parts and farms them out to set of developers, itmay not be realistic for each developer to be able to explain howtheir individual piece will serve the customer.
That said, no developer works in a vacuum and must be able toaccept direction and give feedback to the results of their coding.They must be able to interact with the customer, be it a PM, atech manufacturer, or a layman enduser in a way that theyunderstand.
Sep '07
Jim
You didn't mention a whole 'nother layer of disconnect.
The end user of the websites I work on is not my client myclient is the person hosting the site. As an experienced webdeveloper who has studied web UI over the years, I often knowbetter what will work for end users than the customer for whom
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 23/30
I'm writing the software.
The only times either the client or the developers see a real liveend user, is (maybe) when the site is for the client's internalconsumption, or if we can convince them to invest in UAT(ROTFL)
sldr on September 27, 2007 07:08 AM:The conversation at the top of this page is the process ofbreaking a developer's train of thought while they are gettinguseful work done.
That's funny but maybe that's why it's supposed to take placein the elevator and not a cubicle. Perhaps it should be theparking lot test.
Sep '07
Peter_Grant
As so many of you have pointed out, we don't always writesoftware for a customer; however, I think you missed the pointJeff was trying to make. There is (almost always) a reason thatwe write software, someone who is the intended user, and somekind of capability that it provides.
I would argue that if you can't tell me the who/what/why of yoursoftware, you're not very good at what you do. If your firstresponse is not at the highest level, that's fine. What's reallyimportant is that you actually know all of the subsequent (higerlevel) answers.
If you don't understand what you're working on or why you'reworking on it at all levels of detail, you're probably not equippedwell enough to do any of the following: reuse code that doessomething similar; write code that can be reused in the future;improve upon the prescribed solution; communicate orcollaborate with your team or the business; prioritize; keep fromrepeating your mistakes; and be proactive.
The bottom line is, if you don't know the answers to thesequestions, you're buried too deep in your current task tounderstand how you could be doing it better. This can easilybecome an endless cycle: you keep rushing to put out fires, andall that happens is you get burned by more fires. Take a stepback, figure out what you're doing, communicate with peoplearound you, and find a better way to work.
Sep '07
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 24/30
EricM
Perhaps you missed the point? For me it is not so much what myjob is but what my passion is, the last thing on my passionate listis usually what the clients business is involved with as its usuallyso boring I want to kill myself. My passion is programming, Ifocus on this point to the extent that in some instances it mayblind my alternate thinking reality into a zone where the businessproblem is slightly faded, this however is not a bad thing as longas I bring it back into focus when needed. This lets usdevelopers focus on the problem at hand, at least this is how Ihandle the situation.
Also soft skills are something you are really talking about hereand lots of developers that the skills to communicate efficientlyto the client the answers that are required. Given enoughtraining/time this problem is usually resolved, however if you area short term contractor the time duration is usually so short thatthe problem can only be resolved by proper training in how tointeract appropriately with your client. With that kept in mind,not all situations will be kosher, if I am concentrating onsomething the client should avoid bugging me while this is inessence part of my reality distortion field where reality is bentinto a particular pattern that is no recognizable by anyone otherthan myself I still wish for this particular interaction cooperation.
Just my $1.02, out!
Sep '07
Alan_Shutko
It's amazing how many people here are missing the point. All theexamples I've seen have simple, easy explanations:
Ball bearings? So the plane's wheels don't freeze up and causethe plane to crash. Car software: better gas mileage so the ownerpays less, or better emissions so we all breathe better. Or maybeit's so that it just works better and causes the car fewer problemsmeaning less maintenance. Caching DNS server? Why wouldyou put that in if not to reduce latency when the user isconnecting to sites or to reduce your bandwidth bills so thecompany saves money? Router software: basically boils down tothe router does what it's supposed to do better, so the users of thenetwork have fewer problems.
If you can't boil it down to that level, as a developer you're indanger of doing something wrong, of going the wrong direction,of wasting your time and the company's money by doing thewrong thing. If you don't understand the impact that your workhas to the bottom line, you may overwork something that's reallytrivial or underwork something that's essential.
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 25/30
trivial or underwork something that's essential.
And honestly, if you don't understand how your work affectsthings, do you know why they've hired you? Can you expect tokeep your job?
Sep '07
BrianC
I love the DesigntheBox idea. I wonder if anyone has takenthat idea to the point of printing actual boxes for the team. ForUI design, it seems popular to create and print elaboratepersonas to reflect typical users. One could do the same with theBox to clarify the software vision.
Sep '07
JamesT
Great post. I think that programmers should also think abouthow they can help their customers fend for themselves. Thingslike encoding business logic in business rules and isolatinghighly volatile decisionmaking logic in their own decisionservices can make a huge difference.JThttp://www.edmblog.com/weblog/2006/08/the_secret_of_b.htmlhttp://www.ebizq.net/topics/biz_opt/features/6387.html
Sep '07
Preeti_Edul
I couldn’t agree more! What makes matters worse is not only arethey unaware, they also believe that understanding businessrequirements is a WASTE of their time. They would ratherspend 5 days finding the fastest way to sort a grid than spend 5minutes understanding why the end user needs a sort in the firstplace.
People who disagree with you have been lucky to notexperience such developers first hand; else they wouldempathize.
But is having a vision statement enough?
Preeti Edul
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 26/30
Preeti Edul
Sep '07
brian57
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 mindright. Frame your work in terms of benefit to thecustomer/user. You build a house intending forpeople to live in it; similarly, you build softwareintending for people to use it.
Jeff go find a construction site and ask the first guy you see whyhe's doing what he is doing. Chances are you wont get "Well thecustomer wants blah blah".
If someone came into my office and asked why i was doingwhat i was doing i was doing... i will tell them exactly why i amdoing what i am doing in full on techno speak.
Why?
I make the assumption that anyone asking me questions in myoffice is there for technical reasons.
If not then why are they even in my office? They should betalking to the PM or the User liaison or they guy that wrote theUser story. And why cant they read the User Story note card onmy bulletin board? If they have a question on the technicaldecisions I am making then I'd gladly converse with them.
I also make the assumptions that those other people on my teamare doing their jobs.
Like anyone at all in the business sphere gives 2 cents aboutwhat a programmer is doing or the decisions they make from atechnical perspective.
What is my answer to that question when refactoring?
What are you working on?I'm refactoring this bit of code.
Why are you working on that?Because it lacks cohesion and has a cyclomatic complexity over20.
Oh... Is it on the bug list?No. But it needs to be reworked.
Why are you rewriting code? We need to have a meeting....
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 27/30
...
Sep '07
brian58
"A very famous philospoher, mathemetician, inventor once said:"Please excuse the length of this letter, I did not have the time tomake it short."
Those words are attributed to Blaise Pascal. What he was gettingat is the crux of this blog post... If you can't explain something ina quick conversation, email, letter, etc... you don't have a deepunderstanding of what you are doing."
You sure its not because it is harder to explain things tersely andwith brevity then not?
Sep '07
codinghorror
i certainly don't think that he should need or want to be able toanswer questions at a moment's notice to satisfy a coworker in,say, marketing
That's fair, but forget the customer for a minute. I've workedwith plenty of developers who couldn't adrequately explain tome, one of their technical peers, what they were working on andwhy it mattered.
This isn't specific to commercial, consumer software. There areplenty of software products targeted at technical folks, evenother software developers. The same advice still applies: you'rebuilding software to satisfy the audience in some way, so whynot frame your work in that context?
What is my answer to that question when refactoring?
I'm making it easier for us to make changes in our software later,and reducing the chance that those future changes will causenew bugs.
Sep '07
codinghorror
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 28/30
You sure its not because it is harder to explain things tersely andwith brevity then not?
It IS hard! You're absolutely right!
That's why the project should have a VISION STATEMENTwhich makes it dead easy for people to deliver a succinct,compelling summary of what the project is, and why their workon it matters.
Sep '07
AnonymousC64
Get your mind right. Frame your work in terms ofbenefit to the customer/user.
You forget the situations where the answer is because we choseto do something using technology X. There are times when Ihave more work to do simply because we chose X, or moved toX after choosing Y.
When the answer is "because the boss said so" it may be time tomove on.
Sep '07
Kim
Separation of duties is different per company. In somecompanies the developers will also be the project managers anddecision makers. In others they have the developers do whatthey are told, period. The PM's decide the business reasons forwhy things are the way they are.
The answer "because the user said to do it that way" is the truthand it is the only reason the developer is doing it that way. If itwere up the developer they would have done it a different way(and they did or else they wouldn't have received a changerequest).
Example: The business can decide to go down a path of reducedperformance in order to gain added security or flexibility. It isnot the developer's job to put their foot down and say no. It istheir job to do what they are told and if the business later comesback and says they want performance instead then the developercan implement that. IT Managers can put their foot down, butdevelopers do what they are told. Period.
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 29/30
Sep '07
Brent
The point you make with this entry is very similar to one I makequite often, and one I call the "Tool Test". All software issupposed to be a tool. It should allow a user to do at least one ofthe following:1. Do a task faster.2. Do a task easier.3. Do a task better (with less mistakes)
If the end result of a software project will not do at least one ofthose things, it is a total waste of time and money, and shouldnot be undertaken, or if already underway, scrubbed.
Too often we forget the elusivelysimple fact that software issupposed to help in some way.
Sep '07
JoshuaD
"Example: The business can decide to go down a path ofreduced performance in order to gain added security orflexibility. It is not the developer's job to put their foot down andsay no. It is their job to do what they are told and if the businesslater comes back and says they want performance instead thenthe developer can implement that. IT Managers can put their footdown, but developers do what they are told. Period." Kim
Unless that manager has the integrity to tell the business usersthat they now have to write the whole system again from theground up, I am sure glad I don't work there.
The business MUST be made aware of the trade offs they aremaking, the cost associated with their decisions. From your postI doubt that they have even a clue, and that the IT Manager justgoes along with whatever they say, including an impossible"deadline", which is why I don't work there. I doubt many gooddevelopers do either.
Sep '07
Frank_Booth
Software developers think their job is writing code. But it's not.*
7/23/2014 Can Your Team Pass The Elevator Test?
http://blog.codinghorror.com/can-your-team-pass-the-elevator-test/ 30/30
Software developers think their job is writing code. But it's not.*Their job is to solve the customer's problem. Sure, our preferred medium for solving problems is software, and that does involvewriting code. But let's keep this squarely in context: writing code is something you have to do to deliver a solution. It is not an end inand of itself.
The job is to implement the specifications as deliver by thesogftware designer, who created those specification fromrequirements gathered by the analyst.
It is the Business Analyst's and System Designer's jobs to turnthe customer's problem in to something for the softwaredeveloper to code.
If I'm told to code a sorted list, I code "sort(myList)" and I'mdone.You know the old metric about 10 debugged lines of code perday. This is debugged code. When I'm onetenth done for theday.
What? You wanted the list sorted numerically? The specs said"sorted list", not "numerically sorted list".
Think I should know better? You're wrong. My job is toimplement the spec. The spec that the analyst and designer got