When the interview ends the candidates are given a simple assignment: the business needs to convert a csv file from one format to another. The candidates are given 24 hours to complete the task.
The first developer goes home and designs an amazing yet simple site where multiple files can be uploaded simultaneously and users can choose to be notified via SMS or email when the task is completed. It's great software.
The second developer receives the assignment and spends the next 30 minutes talking to the business to see how the software will be used and what value it provides. After he's gotten the information he needs he says thanks, but instead of letting him leave, the CTO offers him the job on the spot.
The first developer gets the "thanks, but no thanks" call the following day.
What the first developer didn't understand was that the assignment was designed to evaluate collaboration, not coding ability. Both candidates had previously submitted code samples and discussed their samples as part of the interview. Both developers could code equally well, but only candidate 2 had collaboration skills. Candidate 2 was clearly a better hire.
Developers love to talk about how software is about people. I know it's about people, you know it's about people, yet when I look around I rarely see developers interacting with people. It doesn't seem to make sense, and yet it happens the majority of the time. We're stuck in the ways of software development past.
Hackers put out code, often good code. That's great. Without hackers I wouldn't have messaging systems, proxies, web servers, etc. At least I wouldn't have such a good selection. But, being a good hacker doesn't make you valuable to a business.
Time after time I see requirements gathered and presented in a way that is totally disconnected from the business problem that's being addressed. There are two ways to handle the situation.
- Write the best code you can.
- Talk to the business.
But, a developer can deliver what the business is looking for the first time. A(n often) quick conversation with the business ensures that the developer knows what to work on and how it will benefit the business. This dialog often leads to a superior solution implementation where the business gets what it wants and the developer is able to do it in the most efficient way (e.g. I don't need a beautiful website, I need a command line application).
A hacker can deliver the same value to the business (on the 2nd or 3rd try), but the time difference between when the developer delivers and when the hacker delivers is the cost of employing hackers. Hackers create waste (lost time), which the business must pay for. Good developers avoid waste by ensuring that the business gets what they are looking for as quickly as possible.
This idea isn't mine, I just see the application of the idea constantly so I felt the need to write about it. Kent Beck has been talking about it for years, most recently at QCon in London earlier this year. Look for the video when it becomes available at InfoQ -- it's relevant for anyone developing software for a business, and Kent puts it much better than I do. When Kent talks about it you think "well, yes, obviously", but look around work and see if Kent's ideas are being applied. If they are, consider yourself lucky to be working with good colleagues.