Can Your Team Pass The Elevator Test?

Great post. I think that programmers should also think about how they can help their customers fend for themselves. Things like encoding business logic in business rules and isolating highly volatile decision-making logic in their own decision services can make a huge difference.
JT
http://www.edmblog.com/weblog/2006/08/the_secret_of_b.html
http://www.ebizq.net/topics/biz_opt/features/6387.html

I couldn’t agree more! What makes matters worse is not only are they unaware, they also believe that understanding business requirements is a WASTE of their time. They would rather spend 5 days finding the fastest way to sort a grid than spend 5 minutes understanding why the end user needs a sort in the first place.

People who disagree with you have been lucky to not experience such developers first hand; else they would empathize.

But is having a vision statement enough?

Preeti Edul

“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.”

Jeff go find a construction site and ask the first guy you see why he’s doing what he is doing. Chances are you wont get “Well the customer wants blah blah”.

If someone came into my office and asked why i was doing what i was doing i was doing… i will tell them exactly why i am doing what i am doing in full on techno speak.

Why?

I make the assumption that anyone asking me questions in my office is there for technical reasons.

If not then why are they even in my office? They should be talking to the PM or the User liaison or they guy that wrote the User story. And why cant they read the User Story note card on my bulletin board? If they have a question on the technical decisions I am making then I’d gladly converse with them.

I also make the assumptions that those other people on my team are doing their jobs.

Like anyone at all in the business sphere gives 2 cents about what a programmer is doing or the decisions they make from a technical 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 over 20.

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.

"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."

You sure its not because it is harder to explain things tersely and with brevity then not?

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’s fair, but forget the customer for a minute. I’ve worked with plenty of developers who couldn’t adrequately explain to me, one of their technical peers, what they were working on and why it mattered.

This isn’t specific to commercial, consumer software. There are plenty of software products targeted at technical folks, even other software developers. The same advice still applies: you’re building software to satisfy the audience in some way, so why not 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 cause new bugs.

You sure its not because it is harder to explain things tersely and with brevity then not?

It IS hard! You’re absolutely right!

That’s why the project should have a VISION STATEMENT which makes it dead easy for people to deliver a succinct, compelling summary of what the project is, and why their work on it matters.

“Get your mind right. Frame your work in terms of benefit to the customer/user.”

You forget the situations where the answer is because we chose to do something using technology X. There are times when I have more work to do simply because we chose X, or moved to X after choosing Y.

When the answer is “because the boss said so” it may be time to move on.

Separation of duties is different per company. In some companies the developers will also be the project managers and decision makers. In others they have the developers do what they are told, period. The PM’s decide the business reasons for why things are the way they are.

The answer “because the user said to do it that way” is the truth and it is the only reason the developer is doing it that way. If it were up the developer they would have done it a different way (and they did or else they wouldn’t have received a change request).

Example: The business can decide to go down a path of reduced performance in order to gain added security or flexibility. It is not the developer’s job to put their foot down and say no. It is their job to do what they are told and if the business later comes back and says they want performance instead then the developer can implement that. IT Managers can put their foot down, but developers do what they are told. Period.

The point you make with this entry is very similar to one I make quite often, and one I call the “Tool Test”. All software is supposed to be a tool. It should allow a user to do at least one of the 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 of those things, it is a total waste of time and money, and should not be undertaken, or if already underway, scrubbed.

Too often we forget the elusively-simple fact that software is supposed to help in some way.

“Example: The business can decide to go down a path of reduced performance in order to gain added security or flexibility. It is not the developer’s job to put their foot down and say no. It is their job to do what they are told and if the business later comes back and says they want performance instead then the developer can implement that. IT Managers can put their foot down, but developers do what they are told. Period.” -Kim

Unless that manager has the integrity to tell the business users that they now have to write the whole system again from the ground up, I am sure glad I don’t work there.

The business MUST be made aware of the trade offs they are making, the cost associated with their decisions. From your post I doubt that they have even a clue, and that the IT Manager just goes along with whatever they say, including an impossible “deadline”, which is why I don’t work there. I doubt many good developers do either.

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 involve writing
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 in
and of itself.

The job is to implement the specifications as deliver by the sogftware designer, who created those specification from requirements gathered by the analyst.

It is the Business Analyst’s and System Designer’s jobs to turn the customer’s problem in to something for the software developer to code.

If I’m told to code a sorted list, I code “sort(myList)” and I’m done.
You know the old metric about 10 debugged lines of code per day. This is debugged code. When I’m one-tenth done for the day.

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 to implement the spec. The spec that the analyst and designer got paid a lot of money to come up with.

Did we even have a QA session on the specs? Probably not. They tend to come from the ivory tower, and assumed to be correct. Only software get QAed. If you’re lucky.

/rant

Software developers think their job is writing code. But it’s not.* Their job is to solve the customer’s problem

I disagree. There should always be a disconnect between business and tech to keep a healthy balance of interests (this is the core of MSF, and for a very good reason). Business interests do not always align with technical interests - so it should fall to the PM to distill this.

I know we don’t live in a perfect world Jeff but it seems your job is pretty client-side/sales cycle - your post is indicative of this role’s thought pattern (which I’m also a part of). However the best of teams also have people devoted to the technology to keep us mavericks in line.

I am afraid, I have to agree with the author. Here’s the view from the business

http://dailysalty.blogspot.com/2007/09/focus-on-important-stuff-in-technology.html

and also linked in is a post about my bewilderment about agile and and and…

@ workaholicus,
Where’d you read all that?
Sounds interesting.

And Jeff, I have failed the elevator test several times, for example the boss will catch me researching commands for a batch script, which I somehow have to sum up to “fixing joe’s printer”.

Great read. - Keep up the good work.

Maybe we should put it another way. If you’re a developer who wants to sit back and mindlessly code the requirements, you’re expendable. Your job is one that can easily and effectively be outsourced to another company, offshored to India, China, Singapore, Eastern Europe, or whatever. New programming tools or methodologies will gradually make you less useful, because something will eventually let the business sort a list.

You offer no value. You will only be able to operate in companies with very static markets. You will not be able to capture opportunities in a rapidly changing business environment. Your company will eventually be bought or driven out of business by a more agile one, and you’ll be out of a job.

There is nothing strange about the conversation you quote, and you’ll find similar conversations in any field you care to name. “Why are you fixing this car?” “Because it’s the next one on the list.” “Why are you talking to this patient?” “Because she has an appointment.” If you want to know what’s wrong with the sort order in the datagrid, ask that.

Furthermore, many–probably most–developers have no need to explain their work to a layperson. You cannot, for example, summarize “a caching DNS server” for a lay audience’s benefit on an elevator. That’s fine. If you’re working on one, the lay audience aren’t your customers.

There’s a kernel of truth in what you say, but the way you state it is both insulting (“think their job is writing code”–fah!) and limited to the very narrow world of consumer product design.

“I TAKE THE SPECS FROM THE CUSTOMERS TO THE ENGINEERS!!”

“Well why can’t the engineers just take the specs directly from the customers?”

“BECAUSE ENGINEERS AREN’T GOOD WITH PEOPLE, EVERYONE KNOWS THAT!!”

All hale Office Space. Fortunately for me, I develop applications for use in-house, so if I don’t solve the customer’s problem then he/she will be standing on my desk within the hour. I think it’s been a great learning experience for me in the difference between righting code for code’s sake and writing code that solves customer problems. Perhaps all budding software developers should be force to directly interface with customers early on in their careers?

This post and the one on coding the “smallest” thing possible are nice, because discipline is good, but I personally put these arguments in the context of these two imperatives:

  • Do you (the software engineer/designer/programmer) enjoy your job? Are you having fun?
  • Does the customer like what they’re getting, and do they like interacting with you?

Writing software, and consuming software, all happen in the realm of life, and the purpose of life is to be happy. Thinking about the process too much, and doing too much introspection, causes neuroses. They call it “coding bliss” because it’s blissful. You shouldn’t have to give that up.

What gives you the authority to pontificate on the subject of software development? Your rabble wisdom speaks only to serfs, yet you speak of “Software Development” as if you were a god passing judgement on the entire industry. How enfuriating! I wouldn’t have read this at all if my boss hadn’t “enlightened me” with this heaping pile of horse crap. Now, what about code reuse? What if you are creating tools for other software developers? It amazes me how much you fools can get away with. You are like that guy Dr. Phil who “cares so much” about these morons living in trailer parks and these “middle class super rabble” that are even worse. You are trying to appeal to something, something. Got it. Your attempt is to simultaneously add credibility through a false sense of security while hinting that personal growth is in order. You do this instead of saying “YOu are worthless and I will destroy you!”. That is too scary. Perhaps, you are afraid of this yourself. Perhaps your musings are an unconcious attempt to give yourself credibility. Who knows? Who cares? It doesn’t matter. However when someone is this transparent, it is usally a cry for help. So, here is my advice: STFU!

hmmmm… Have you ever worked with Chinese or Indian software companies? - they certainly subscribe to the Idea of:

“Software developers think their job is writing code.”

An Analyst formulates requirements, the developer takes the requirements and “codes” them (amongst other things, such as unit test, document, version control etc), and the PM oversees that requirements (and eventual solution) will meet the expectations of the business.

In some businesses there is never any direct contact to a “Developer” - as a analyst (business/solutions) has the ability to properly explain functionality to the end user - as this requires skill’s that a developer is not necessarily expected to have.

You don’t ask a painter to cook you a cake (unless of course they’re a cook as well).

In my world, my team aren’t interested in “why does the business I work for sell widgets”, and I don’t think they should be. Its not their job to get excited about that. They are (or should be!) interested in “the page that allows the business to sell a widget will be 5x more productive if I implement xyz - and this is the cool way I would do it…”

Steve