Can Your Team Pass The Elevator Test?

blog
21

The answer to the question depends upon who asked it.

Technically minded folks might want to know about the details in the weeds.
Status report filers might want to know what they can put on the report.
End users might want to know if the reconcile checkbook feature is working yet.

If I’m working on the ‘reconcile checkbook’ feature, and I’m about 1/2 done with it and I’m working on some DataGrid or creating a user control, I ought to be able to figure out which answer is appropriate for the audience.

Doesn’t seem like rocket science to me, but evidently it is.

22

I have a few problems with this.

First, abstraction is the key to developing software. It may well be good to know what business purpose the method you are debugging fills, but when you are down in the trenches working in the code, you can’t be thinking about all that. All you need to be thinking about is “I am getting input x, I am supposed to return value y, but instead I’m returning value z”. If instead you are too busy thinking about what high level function the user is trying to perform, you are never going to get the job done.

Second, as mentioned several times, a lot of software doesn’t face customers at all. What if you are developing a framework that is being used by other developers? You don’t need to know what business purpose the user of your framework is filling, your work should should be independent of that. In fact, if you are too focused on how a particular developer is using your code, that can lead to make it too specific to that particular purpose and not reusable for other developers.

Third, many changes that are made have no impact at all on the customer. For instance updating outdated or missing comments, fixing the code to match general coding conventions, and in general cleaning up code.

And fourth, if you think the project manager/architect/whoever wrote the high level designs did a bad job and you don’t think a customer will ever use what you are told to design, you can’t just throw away your assignment and work on something else. That will just lead you to losing your job. And its perfectly possible that your project manager is not the idiot you think he is and simply knows more about the business than you.

23

Jeff,

Not all of us develop products for customers to use. Some time we sell a product to OEM customers, who then sell it other OEMs, 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 the customer needed were features A, C, and G.

Kashif

24

As some people have said, amongst the mass of “we don’t all write for customers”, you can replace customer with any end user of the product (Surely you have one. If not, why the hell are you writing it?) If you don’t know how you are writing is benifiting them then more than likely what you are writing isn’t benfititing 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 is going 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 taking things so literaly and be able to apply them to wider situations.

25

Wow. I work with tons of software developers, and not a single one would ever answer “because it’s on the bug list.” We all know why we’re doing our tasks, even if we think the reason is stupid (“the users want a non-linear way to get to this option, but once I implement they’ll see that it’s really impractical to go another way”).

For me, giving responses like those you started the post with would be an immediate red flag that this employee is not going to be very useful much longer.

26

Completely agree with Chris above. The conversation only happens with a slow learner. The very first thing a programmer who was given a bug would do is to verify the legitimacy of the bug. So the answer of sorting by numeric order should come quickly.

27

Hey Now Jeff,
This is a great post, I like the answer it’s on the bug list. You are so right our job is not to write code, it’s to provide solutions.
Coding Horror Fan,
Catto

28

I love working with software (and hardware) engineers because of the concrete, inward looking, utterly absorbing, many-layered work they do. With an artificial language built on top of an extremely limited instruction set, they create something that can talk 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, concentration, and devotion that is practically religious in nature. It’s not uncommon to see a certain species of engineer lose the ability to speak coherently after a few hours of writing code.

This is not “project management mind” nor is it “why-are-we-doing-this mind”. It is a state of rapt attention and intention more aptly compared to the spiritual or aesthetic mind found in prayer, meditation, art, or sport. To characterize this as a primitive state of mind is not to say it’s simple or unsophisticated, as Gary Snyder 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 making can of course be domesticated or cultivated for economic gain (Levi-Strauss, via Snyder) as surely as wild pigs or prairie. This is exactly what most of us are doing, as we sit in our cubes or offices amidst the great expanse of our multinational corporations or the more scaled down hillsides and vallies of smaller companies and startups.

Within these organizations, there are still thickets where the wild mind survives, and even thrives, and software engineering is one of those great preserves. Bill Gates’ (possibly only) genius is that he understood how to attract that kind of mind, then tame it to the end of making money.

When a human being writes a poem, makes a song, or tries to tame the wild machine, (s)he partakes in a primitive wonder that knows no remuneration (often quite literally). Oddly, it is this same human being an organization turns to with its most intransigent technical issues. No matter how erudite, facile at abstraction, or managerially converted we become, there is still a side of us that knows the real work of making. Yes, there are still worlds where no explanation is required.

29

@M
I think you missed the point. First off he said software developers, not programmers. To me a programmer is Joey Undergrad, fresh from the Uni. with his BS in one hand and a keyboard in the other. We were all “programmers” at one time or another, I know. But if we are any good at our profession we slowly become proactive in development and graduate to become developers.

Secondly, the comment on how we don’t all need to be great communicators to be effective programmers. You’re absolutely right. But at some point someone has to communicate with a user. To me Jeff’s articles seem geared more towards professional growth. Yeah, I could fort-up in my cube churning out assembly optimized code all day or I could hire someone else to do that and I could go deal with customers so that we have money to allow people to code. That makes me a better developer and my resale value in the industry goes up.

30

@M
I think you missed the point. First off he said software developers, not programmers. To me a programmer is Joey Undergrad, fresh from the Uni. with his BS in one hand and a keyboard in the other. We were all “programmers” at one time or another, I know. But if we are any good at our profession we slowly become proactive in development and graduate to become developers.

Secondly, the comment on how we don’t all need to be great communicators to be effective programmers. You’re absolutely right. But at some point someone has to communicate with a user. To me Jeff’s articles seem geared more towards professional growth. Yeah, I could fort-up in my cube churning out assembly optimized code all day or I could hire someone else to do that and I could go deal with customers so that we have money to allow people to code. That makes me a better developer and my resale value in the industry goes up.

31

Great article. I’m going to really start writing vision statements from now on. I’ll admit, I’d neglected them…

Bob is an example of sooo many things that could go wrong in the design of a product, but it really came down to stupid arrogance – MS devs and management thinking they knew better than their clients, and that’s why we mock MS so for releasing this product. Their vision statement may have gone something like this:

for BEGINNING COMPUTER USERS
who WANT TO BE PRODUCTIVE ON THEIR COMPUTERS
the MS BOB PRODUCT is a ALL-IN-ONE SUITE
that MAKES IT EASIER TO USE YOUR MACHINE
unlike WINDOWS EXPLORER AND OFFICE
our product HAS AN ANIMATED DOG

32

I wrote about this sort of thing a while back and coined it the journalism model (TRADEMARK!!!).
If your developers can’t explain the who/what/when/why/where of what they’re developing, I see it as a management problem. My understanding of the problem set that I’m working to solve doesn’t come from the ether.
I can give a better elevator-level description of what I’m doing and why when I’ve been involved in the project from its inception than when I’ve had a requirements document the size of 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 a mental model of what needs to be done and keep people on track and excited about what they’re doing (given all that yes I said hypothetically). I don’t have much confidence that, were I to turn the tables, some managers would be able to pass the elevator test I posed to them either.
http://48klocs.blogspot.com/2007/07/software-development-journalism-model.html

33

A very famous philospoher, mathemetician, inventor once said:
“Please excuse the length of this letter, I did not have the time to make it short.”

Those words are attributed to Blaise Pascal. What he was getting at is the crux of this blog post… If you can’t explain something in a quick conversation, email, letter, etc… you don’t have a deep understanding of what you are doing.

For the past 12 years, I have been a software developer in a variety of industries from car insurance, fiber optic management, retail market research, and even crop insurance data mining. At each of the places I have worked, I have generally spent 3-4 weeks up front just learning what the company did and why. That allowed me to frame my development efforts around what we are calling a vision… but in the broader sense of the organization, not just the application.

In all things, I try to work so that any explanation about the software (or the organization) would be such that a 9 year old could get the idea… Now that I work for the government, I have lowered that expectation to 6 year old!

34

The conversation at the top of this page is the process of breaking a developer’s train of thought while they are getting useful work done.

35

I think the disconnect that some of the posters here have with Jeff’s article is that the customer can be technical and have no problem with technical jargon. For instance, the customer of router software is the router manufacturer (the one paying for the work), not necessarily the end-user. I’m sure that Cisco is completely invested and interested in every aspect of the code that is programmed for them.

I think is some cases the “customer” of a piece of code is the project manager. If a PM breaks down a coding problem into a set of abstract parts and farms them out to set of developers, it may not be realistic for each developer to be able to explain how their individual piece will serve the customer.

That said, no developer works in a vacuum and must be able to accept direction and give feedback to the results of their coding. They must be able to interact with the customer, be it a PM, a tech manufacturer, or a layman end-user in a way that they understand.

36

You didn’t mention a whole 'nother layer of disconnect.

The end user of the websites I work on is not my client - my client is the person hosting the site. As an experienced web developer who has studied web UI over the years, I often know better what will work for end users than the customer for whom I’m writing the software.

The only times either the client or the developers see a real live end user, is (maybe) when the site is for the client’s internal consumption, 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 of breaking a developer’s train of thought while they are getting useful work done.

That’s funny - but maybe that’s why it’s supposed to take place in the elevator and not a cubicle. Perhaps it should be the parking lot test.

37

As so many of you have pointed out, we don’t always write software for a customer; however, I think you missed the point Jeff was trying to make. There is (almost always) a reason that we write software, someone who is the intended user, and some kind of capability that it provides.

I would argue that if you can’t tell me the who/what/why of your software, you’re not very good at what you do. If your first response is not at the highest level, that’s fine. What’s really important is that you actually know all of the subsequent (higer-level) answers.

If you don’t understand what you’re working on or why you’re working on it at all levels of detail, you’re probably not equipped well enough to do any of the following: reuse code that does something similar; write code that can be reused in the future; improve upon the prescribed solution; communicate or collaborate with your team or the business; prioritize; keep from repeating your mistakes; and be proactive.

The bottom line is, if you don’t know the answers to these questions, you’re buried too deep in your current task to understand how you could be doing it better. This can easily become an endless cycle: you keep rushing to put out fires, and all that happens is you get burned by more fires. Take a step back, figure out what you’re doing, communicate with people around you, and find a better way to work.

38

Perhaps you missed the point? For me it is not so much what my job is but what my passion is, the last thing on my passionate list is usually what the clients business is involved with as its usually so boring I want to kill myself. My passion is programming, I focus on this point to the extent that in some instances it may blind my alternate thinking reality into a zone where the business problem is slightly faded, this however is not a bad thing as long as I bring it back into focus when needed. This lets us developers focus on the problem at hand, at least this is how I handle the situation.

Also soft skills are something you are really talking about here and lots of developers that the skills to communicate efficiently to the client the answers that are required. Given enough training/time this problem is usually resolved, however if you are a short term contractor the time duration is usually so short that the problem can only be resolved by proper training in how to interact appropriately with your client. With that kept in mind, not all situations will be kosher, if I am concentrating on something the client should avoid bugging me while this is in essence part of my reality distortion field where reality is bent into a particular pattern that is no recognizable by anyone other than myself I still wish for this particular interaction cooperation.

Just my $1.02, out!

39

It’s amazing how many people here are missing the point. All the examples I’ve seen have simple, easy explanations:

Ball bearings? So the plane’s wheels don’t freeze up and cause the plane to crash. Car software: better gas mileage so the owner pays less, or better emissions so we all breathe better. Or maybe it’s so that it just works better and causes the car fewer problems meaning less maintenance. Caching DNS server? Why would you put that in if not to reduce latency when the user is connecting to sites or to reduce your bandwidth bills so the company saves money? Router software: basically boils down to the router does what it’s supposed to do better, so the users of the network have fewer problems.

If you can’t boil it down to that level, as a developer you’re in danger of doing something wrong, of going the wrong direction, of wasting your time and the company’s money by doing the wrong thing. If you don’t understand the impact that your work has to the bottom line, you may overwork something that’s really trivial or underwork something that’s essential.

And honestly, if you don’t understand how your work affects things, do you know why they’ve hired you? Can you expect to keep your job?

40

I love the Design-the-Box idea. I wonder if anyone has taken that idea to the point of printing actual boxes for the team. For UI design, it seems popular to create and print elaborate personas to reflect typical users. One could do the same with the Box to clarify the software vision.