Simon Palmer’s blog

March 16, 2011

Why I will never score more than 9 on the Joel Test

Filed under: recruiting — simonpalmer @ 1:54 pm

I love the Joel Test.  Really, I do.  I wish it were stamped on the insides of the eyelids of any person with technical talent looking for a job.

BUT – and of course a BUT was coming – I will never encourage my teams to score more than 9.  And deliberately so.  For the record, and to save you having to switch between pages, here are Joel’s 12 questions:

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Here are my answers:

1-5 Yes.  Of course.

6. DEPENDS.  If you mean an enormous GANTT chart written on wallpaper which demands a team of people whose sole purpose in life is to swim against the tide of inaccuracy, incompleteness and pointlessness, then the answer is a resounding NO.  If you will accept an iteration board, a rough release plan stretching out a couple of months, all of which is written on sticky notes and pinned to the wall and completely subject to change, then YES.  I think I score 0.5

7. I was going to say “depends” again, but my real answer is NO.  We do not have specs in any way that an ordinary person might interpret the word.  A “spec” (shot for specification) is a detailed document running to many pages which completely defines how a feature looks and behaves.  It is a contract between the person defining the requirement and the person delivering it.  We do not have these contracts.  For a start it implies that all the work of understanding and design will be complete prior to work starting.  It also presumes that we really know what the feature should be in advance and that the fungible developer will be able to interpret the words in the spec perfectly and implement both the letter and the spirit of the intent.  This never happens and with the benefit of 20-something years of software development it feels naive.  Not to mention it is in direct contradiction of the Agile Manifesto.

8. NO.  Programmers sit together round tables and are encouraged to talk, debate, call across to other people to help, gather in groups round whiteboards, converse, interact, stand up, sit down, cuddle, sing uproariously and generally be social humans engaged in a common task.  If they are silent and concentrating on work on their own, then they are not pairing and our Agile processes are breaking down and the code will suffer.  I say NO to silence.  On the rare occasions where someone has a solo task to perform (research spikes are an example) which will require dedicated concentration for a period of time I will encourage (and facilitate) them to go and find a space which suits that.

9. Yes

10. It’s another “depends”.  There are testers, and there are testers.  If you are doing TDD, then isn’t everyone a “tester”?  If you are aiming for 100% functional and integration coverage using an automated tool, then don’t you need Quality Engineers rather than testers?  Isn’t there every bit as much discipline in writing the tests as there is in writing the code?  We think there is and we religiously chant the TDD mantra, so in the same way that you won’t find “specs” in our world, your won’t find “testers” either.  Yes, we have people whose sole job is quality and we take it very seriously, but I don’t think they would call themselves testers.  I think I score a 0.5 here too.

11. Yes.  Of course.  In fact we have taken it one step further and give people coding challenges to complete between interviews and we review the code together collaboratively when they are done.  For more on this see my blog and RedCanary.

12. Yes.

So, I still love the Joel Test, but the worst, most prescribed waterfall places to work as a developer could score 12, and great creative software shops who do interesting valuable work in a collaborative and genuinely Agile way will rarely get full marks.

We’re the latter, not the former, so I stand proudly by my 9.

About these ads

9 Comments »

  1. [...] and of course a BUT was coming – I will never encourage my teams to score more than 9. And… [full post] simonpalmer Simon Palmer's blog uncategorized 0 0 0 0 [...]

    Pingback by Why I will never score more than 9 on the Joel Test — March 16, 2011 @ 2:32 pm

  2. Couldn’t agree more. It sounds like you probably score 1.5 on question 10 – you have “testers++”

    Comment by Andy Balaam — March 16, 2011 @ 3:29 pm

  3. Sorry, I must disagree with #8. Any company that does not score YES for this question I will not work for.
    You expect me to work while people around me are SINGING? For real?
    When the support people sitting near me take a call, or people hold an impromptu meeting at the next desk, it’s not always practical to stop what you’re doing and go to the quiet room. In fact, it’s that kind of distraction that the question is trying to avoid.
    And the guy who sits next to me and hums all day? I’d be surprised if by the end of this project his brains aren’t all over the floor.

    Comment by darnkitty — March 24, 2011 @ 5:07 pm

    • To be fair, we limit the singing to those moments when we really need a good sing-song, we don’t sing *all* day.

      I am sad that you have excluded yourself from working for our company because it’s great and we’re growing and hiring aggressively. Otherwise I would have asked for your CV because you’re obviously reading the right blogs.

      And regarding your humming buddy, give the guy a hug. Better still, join in. Sing along! One of two things will happen, he’ll stop humming or you’ll start enjoying it.

      Comment by simonpalmer — March 25, 2011 @ 6:59 pm

      • Seriously? The developing work is a pile of people running around in circles coming over with ideas and disputing them all day?

        Do you think that the actual craft of writing software is any different by all other engineering work that requires focus and concentration? Good luck hiring the new kids on the block and getting script out of them.

        Real programmers work on a 2-3 teams of highly focused and respected individuals who take pride in what they build. Not “call across to other people to help” and break the focus of the whole group.

        “give the guy a hug” hahahaha. Give him a hug and go be buddies. Who needs quality code writing anymore. Group hugging, yeah!

        Comment by Ian — April 23, 2011 @ 6:39 pm

      • @IanRihter@gmail.com, thanks for your perspective, it’s healthy to have all sides of the argument. Let me try and answer your questions.

        “Seriously?” Yes. And no.

        “…a pile of people running round in circles coming over with ideas and disputing them all day?” No. And sometimes yes. I see a bit of that, but I see much more focused team based work following agile principles, in our case XP. Take a read of James Shore’s Art of Agile book, as I think this quite closely resembles our environment, attitudes and working practices; you are clearly not familiar with it. And I have seen running round in circles in the environment you describe too.

        “Do you think that the actual craft of writing software is any different by all other engineering work that requires focus and concentration?”(sic). A question to the very heart of the matter, and yes, I do. In fact I think the term “Engineering” is entirely inappropriately applied to software development. It’s not predictable and mechanistic in my experience, it is much more like building dry stone walls, it’s a cross between puzzle solving, research, heavy lifting and creativity. It certainly requires concentration a lot of the time, but sometimes that’s the opposite of what you need to get really great work done. Decompression and latitude work just as well and much better in certain circumstances. And thank you for your good luck, although I don’t think I need it. I have a strong pipeline of new recruits from a variety of backgrounds including researchers, new developers and seasoned pros, and they are forming the most capable dev teams I have worked with. No script kiddies in my world – although I would never turn them away.

        I’m afraid I don’t recognise the “real programmers” that you refer to, although I confess I have done my best to avoid environments that don’t value the human interactions, and in which an ask for help would be considered either a distraction, or a sign of weakness. In fact I find it curious, and slightly offensive, that you would judge me and my developers and working environment as somehow inferior to what you believe to be right, and presume we are not capable, high capacity, high integrity, intelligent individuals doing great work, just because you don’t recognise or value the practices. I do recognise the respect and pride that you mention, but don’t see that in any way at odds with a bit of fun and a conversational and personal atmosphere.

        And what’s wrong with giving the guy a hug? What experiences in your life lead you to believe that hugging and quality code are somehow mutually exclusive? (rhetorical questions, this isn’t Oprah).

        Comment by simonpalmer — April 24, 2011 @ 1:29 am

  4. @darnkitty

    Hold on a second, if there was ever a time for you to recognize sarcasm it was here. Obviously agile teams don’t just sit around and sing with each other. Unless the song is about reverse boolean logic in C# then it would be a little useless, however there are circumstances where a little song and dance among team mates produces something even stronger then good code. It’s called a good team rapport, and I would argue that having a team which works well together (regardless of the activity), will always produce results which rival the best of code. Teams who play together will also work together towards the common goal, great software. It would be much easier working with a complicated and overly complex enhancement request if the product manager and the dev team got along. If they could even speak the same language (or sing the same song), wouldn’t that be the truly harmonious team? Isn’t that what all software development teams should strive for? Agile or not, a good, well working team will always produce amazing software. (Of course, that’s just in my experience in developing both in the Agile world and the Waterfall world).

    Also, we’re talking about an AGILE team, it’s incredibly unlikely that a support technician is sitting at the table with the rest of the team. His work would prove to be a little distracting, but on the other hand, listening into his calls and understanding what common problems your users are running into will definitely help you build greater software. If anything, putting a support guy that close to you serves one great purpose, to make you see the problems your users are encountering and motivate you to fix them. (If not to make the software better, then to make the support guy less distracting by having less support calls to deal with).

    @Ian

    There is a line that needs to be drawn here, and a pinch of process to go with it. Ideas are either constructive to the creative process or a hindrance (depending, of course, on how you look at them, and of course, what the idea is). If I were to approach a project manager who manages building cogs with the idea for building a great pop can, that’s going to be nothing but a hindrance. Of course this is what the project manager is for, to steer the ship and help weed out the great ideas (like automation, Kaizen, new cog greasing apparatus) from the terrible ones. (Then again, if your programmer can’t tell that a pop can has nothing to do with a cog builder, then maybe you should rethink your hiring process….)

    I love how you draw unnecessary attention to software development by calling it a “craft”. Sit down for a second and get off your pedestal, we’re not curing cancer here. Of course building software is different then other engineering tasks, there are some minor similarities (process, specifications, teamwork), but there are also major differences (try as I might, I can’t possibly become a structural engineer with my knowledge of JAVA). Explain to me in a simple straight-forward manner, how software development is NOT different from engineering work? I mean hey, every job requires a degree of focus and concentration, perhaps the heart surgeon would make a great programmer after all by your standards.

    I’d be scared to have a developer on my team who didn’t ask questions or “call out for help”. Imagine how much disaster is going to befall the project when the “new kid” checks in code which he developed in solitude in his cubicle. It won’t integrate, it will be buggy, and we will spend a lot of time fixing the problems. All of which could have been avoided with proper, healthy interaction. (Again, healthy interaction, talking about the last Jays game at the water cooler isn’t really constructive now is it?)

    “Real programmers” – such as you label them – are a dying breed of stone tablet chiselers who believe that the only way to develop software is their way, and resist change and collaboration with every fiber of their being. The “Real programmers” of today are taking a much more active stance when it comes to active collaboration. I’ve worked (literally, at the same desk), side by side with project managers, quality assurance testers, UI experts, database developers and more, and each time I do this I learn something incredibly important about their roles and how it relates to my “craft”. Even more importantly, I learn a lot about my role and how it influences them. The code I develop today is 100, even 1,000 times better then the code I developed 2, 3, 10 years ago. Why? Because once we learned to work together as a team and respect each other, we recognized the impact it had on the software and kept on collaborating with each other. We have teams which rival the top development teams at industry leading corporations.

    @Simon

    I don’t 100% agree with your answer to number 10. TDD is not a replacement for a fully functional QA, nor is it meant to be. TDD replaces the dreaded manual unit testing, BVT & Smoke test which does nothing but suck up time in a schedule, but it is no replacement for exploratory testing. There’s a saying at my company ” A developer makes a lousy QA “, and I’m sure it’s common in other places as well, but it’s 100% accurate in every scenario I’ve seen. Developers just don’t have the ability to see the forest through the trees and will only focus on the scenarios they know of. Exploratory QA is meant to test everything that developers aren’t thinking of, if anything, turning a QA into a developer is almost a guarantee that your automated testing will truly become an acceptable replacement for functional and regression testing. This leads me to the “Quality Engineers” section, are they developers? Are they QA? Are they both? In my experience, a QA Engineer is someone who learned how to write automated scripts, but if all they script is the functionality placed in front of them, are they truly able to see beyond the screen and think of the scenarios that they aren’t seeing? Or are they too locked into only testing what they can see because they don’t have the time/patience/skills to be able to move outside their box? I think QA engineers are important to achieving the 100% coverage goal (more like a dream, really), but so are regular “testers”. Something to ponder over.

    As much as you love the Joel test (I did too the first time I read it), I believe you shouldn’t use it as the basis for judging an Agile team. There’s far too many “Depends” answers here which really take away from the focus of the test. Why not come up with something on your own which actually applies to Agile?

    I’m not touching the “hug” question, there are far to many shades of “gray” in this area. My current table mate sings and hums to himself and I’m at peace with it. Throw on your headphones, crank the tunes and watch your fingers dance across your keyboard as you build something wonderful. Beats having to listen to him and also fixes the question about the “hug”.

    Comment by Medwyn — April 29, 2011 @ 12:05 am

    • @Medwyn Thanks very much for the effort you put into replying. Looks like we are quite aligned and I hear you about testing. We have three levels of testing, unit, integration and exploratory, and we major on the first two and don’t have as much formality as we should in the third. It’s a good shout and thanks again.

      Comment by simonpalmer — April 29, 2011 @ 1:13 pm

  5. Such a false dichotomy… there are options between “plan everything upfront and never deviate” and “plan nothing and wing everything,” and there are options between “each developer codes independently on his or her own continent” and “everyone sits at a table and talks all day.” There’s a balance to be struck here.

    Did you read Joel’s series on writing functional specs? He linked to it from the article you’re referencing. Specs aren’t gospel chiseled onto stone tablets. They’re living documents, describing what you’re building right now. They *will* change if you’re doing things right, unless you really did happen to have the right idea from day one.

    Besides, why can’t specs be per-iteration?

    Communication is a tricky subject—it can be productive, or it can be a distraction. Contrary to popular belief, most humans are terrible multitaskers. Sure, I’d love to hear about your new date picking widget that remembers your dog’s birthday, but not while I’m in the middle of debugging an obscure floating point issue.

    We can’t even talk and drive safely. (I’ve met people who can’t seem to talk and walk safely!) How do you expect us to talk and code at the same time?

    Why not send me an e-mail instead and let me read it when I’m done? If we need to hash something out on a whiteboard, we can head to a conference room when I get this code fixed and checked in. We can socialize at lunch, or at other times when I’m not actively working on something.

    Why does it have to be “caffeinated bullpen” or “no one ever communicates at all?”

    Comment by Jeremy — June 23, 2012 @ 3:03 am


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Silver is the New Black Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: