brian:
the Pascal comment was meant to illustrate that most people will ramble on about something and continue to fling BS at you trying to show you they “know” what they are talking about… but if you can’t explain what you are talking about (or doing) in very basic terms, you may not have a deep understanding of the subject matter.
I can say in my experience that the times I’ve had the most success at any project was when I knew the why’s and what’s of what I was programming not just the how.
I have had several programmers working for me over the past 2 years that were “spec in, code out” types. And as the lead, it was a pain in the azz…
Case in point, the spec says: "the data will always contain a 4 digit number."
So one of my developers didn’t check for Nulls or zero. I noticed this and asked him to handle those cases, his response was the spec didn’t mention that. So, we take it to the person that wrote the spec (the BA for the data analyst), they confirmed “there will never be nulls in the data”.
I was subsequently overruled, and the product went live. Within 3 hours, the data had nulls and the program started throwing errors.
I would much rather have had a programmer that went the extra step to find out how the dat would be populated and then add in null protection. Me pointing out that the column in the database was not set to NOT NULL, didn’t seem to convince them that nulls could get in there.
Developers certainly need to see and know the Big Picture, but to the same extent that other members of the team need to know the Small Picture.
Coders make the software – they create the product. Marketers, salespeople, HR folks – these people are key members of the team, but most have no idea what the Small Picture is. None. It is as disingenuous to say “I don’t care if the software is written in …iguana juice” as it is to say “Because one of the testers reported it as a bug.”
Many developers would fail the elevator test, but many other members of the company would not be able to answer simple questions about the core construction of their products. Could they respond correctly to “What language is our product written in?” or even “What operating system does our product run on?” These things matter, and to imagine that a product written in, say, COBOL, is equivalent to one written in Java is silly. Maybe the one written in COBOL still solves the customer’s problem today, but I ain’t taking any stock options with that company.
At a quick glance through the comments (I only read the first 20 or so in detail… others I just skimmed) it seems a roughly 50/50 split between people who agree with Jeff on this and those that don’t.
I’m with the “don’t” group on this one. I can think of many valid reasons why an elevator conversion should go exactly like the one described. But regardless of that this article doesn’t take into account who the customer is nor who the interrogator is.
I’ve been in some organizations where the only input a developer has is an email from their manager with a change request. This effectively makes the customer your manager and manager’s are notorious for not wanting to explain themselves to their subordinates (“Dan, make this change before you go to lunch. Chop-chop.”).
More importantly, when I am asked what I am working on in the elevator I tailor my answer to the person asking the question. If its an executive I would give them a response involving the customer and how we’re keeping them happy. If its a technical person I’ll give them a more technical answer. If its the receptionist I’ll say “nothing important, wanna go to lunch?”
There was a time when this blog had entries on why our life is great because we can code ‘this’ to achieve ‘that’. Now-a-days we have entries on why our lives are miserable exactly because we can code this to achieve that.
Maybe Jeff has climbed up the management ladder.Adieu friend, so long and thanks for all the fish!
All the idealism and pragmatism on this page is impressive. Let’s add a medical thought: I suspect that some developers I’ve worked with had Aspergers Syndrome and were incapable of relating to other sentient beings. But man, were they really great heads-down developers (for which there is a need).
If you are still reading at this point, GET BACK TO WORK!
If you can explain WHY you are writing code, share it also with me and I’d understand myself a little better. I don’t see any reason why I’m banging a plastic box 10+ hours a day when I could make my living in some other more humane way. Still, it’s the only job I’d ever really want to do. If someone asks me to write a piece of code that sorts a list, I don’t give a fuck what it is used for, all I care is writing a masterpiece of code. Prefer bogosort.
btw. go ask a mathematician or physicist what their latest results can be used for.
It’s all too easy to spot the code addicts in the comments. “Hey, I just want to code! It’s somebody else’s job to make sure it’s relevant.” Your privilege to feel that way, of course. But there are implications to that way of thinking, whether you like it or not.
Alan Shutko summed it up best in his comment above: “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.” The guys who focus on nothing but code may not like that, but it’s the world we live in.
Granted, from the same question, you can get different answers from the developer, depending on who is asking. I know I would answer differently to my boss(we are chasing the deadline so we can bill them early), my client(the problem you mentioned, yeah, I’m fixing it), my colleague(maybe if we can ship it earlier, we can get some bonus this year), and heck even my kid (dad is doing work). Are you expecting the same answer every time a developer was asked about what he is doing? Maybe you should reflect on what perspective the developer has when he was asking the question.
Yes, I also agree with Alan Shutko. Going that extra mile to understand all aspects of the company you work for may or may not be your job, but you can damn well bet that some day your job will depend on it. If you can’t explain why what you do helps the company make money in the greater scheme of things, how can you conceivably justify your paycheck to your employer?
To use the auto mechanic analogy; would you choose the guy who simply works on your car doing only what you asked him to do, who then hands you a bill without explanation? Or would you go to the guy that takes the time to explain why you need to replace your worn out spark plugs and brake pads, even though you only came in for an oil change?
I agree with having a project vision statement. As the PM, it’s my job to keep everyone focsued to make the best use of everyone’s time and to get the product to the customer, on-spec, and on-time. Pointing to the vision statement (we call it the project objective statement, same thing) shuts down a lot of unnecessary chatter and the occasional folks who ‘drive by’ and decide the scope really has more to it. I really stress the value to the business and if folks are writing code or spending time on anything not contributing to the vision, then they are wasting their time and the clinet’s money.
this is the classic staffing issue. Companies that dont hire project managers and business analysts are “playing house”. Why is the analysts problem, how is the developer/architects problem. As software engineers it is our duty to create elegant mainatainable algorthims that solve the problem. If we are given system requirements and function specifications we can build software that is accurate to the business’s need. Typically the types of people that make great software guys are not the same types of people that make great analysts.
I agree with the guy who called you a pontificating idiot.
When I go to the doctor, I don’t expect the nurse taking my blood pressure to know the details of my condition.
When I get my car detailed, I don’t expect the guy waxing my car to know or care about my date plans.
When I go to the deli and get a fruit salad, I don’t expect the guy at the counter to know what kind of party I am throwing.
If the programmers are having to worry about the customer’s needs, then the intermediate levels (pm, ba, architect, designer) have not done their job properly.
Wow, I usually get 900k down off my work connection, the groktalk video is coming in a solid 8.5k and getting slower every minute. Some aspiring entrepreneur could start HorrorMirror.com
I love it! The “elevator test” is one of the first items that go into the Operational Concept Description documents I write for projects here. It helped in SO many ways when I had to rewrite a program due to bad programming and business logic in the current model. Using that elevator speech easily lines up the flaws and the benefits, which makes the “big wigs” more agreeable with the process.
I think I’m going to put an “elevator description” of a hobby program I have on the front page of the website and see if any saavy folks pick up on it. It makes for a great opening paragraph and intrigues people to click into the fine details.
When I’m setting up the elevator talk or tracking my progress in general, I like to categorize things in one or more of these areas (I’m probably missing one or two as well). So my conversation can flow like this:
Why are you fixing the sort order on the datagrid?
– To make it easier for the user to view their data. They’ve been having issues with it up to this point. Fixing the sort order also saves them a bit more time processing the record they need.
Why are you doing that fancy mumbo jumbo to the router?
– So that it functions more efficiently and will adequately handle the 1000 concurrent users you’re expecting next month.
If your life is just “code the spec” and you have no feel for why, or what good this can possibly do, you have a sad, shallow existence, and I pity you.
You also run the very real risk of doing the wrong thing. You need to understand how the software will be used, and by whom. If you do not, you will never know when to question the spec. If all I wanted was to turn a spec into code, I’d get a CASE tool.
We as humans have the capacity for so much more. We can notice when someone upstream who wrote the spec made an error (I have other people check my code, why not use this as a chance to check the spec.) We can maybe even see when the spec, while doing what they need, could be so much better for less work.
All software has users, whether internal, external, or just other developers. Every change affects them, even just fixing comments affects the speed and accuracy of future fixes.
Software without a user is pointless. I will not live that way.
As long as someone mentioned Asperger’s syndrome, I thought I would add my two-cents. Many programmers have Asperger’s syndrome a form of mild autism. While it would be ideal if everyone could pass the “elevator test” and be able to explain “to clearly explain what they’re working on, and why anyone would care, within 60 seconds” this is NOT a skill that most with Asperger’s possess…now or EVER!
There are great programmers who can write tremendous code if they are given specific and clear instructions which is what is needed if your programmer has Asperger’s. As long as his code meets specs and he has clear written directions, then maybe the elevator test is unnecessary. Anyway, if you or a loved one (or colleague) has Asperger’s and you want to learn more about it, the site http://www.AspergersSociety.org is a great place to get some info and sign up for a free newsletter.
I don’t think that precludes me from being able to . I actually find it mildly insulting that you presume that I’m not able to relate to customer problems. Even if AS can’t empathise with the “customer” they can at least understand what the requirement it.
All programmers need specific and precise boundaries on the task at hand.
In terms of the “elevator test”, I find that if a coder is unable to explain why, it’s because they haven’t been told “why”.
I don’t accept work tickets now unless they are clearly specified, with a user story (“As I… I Want… In order to”) and tractable acceptance criteria (“given/when/then”).
