I noticed an interesting post from Allison Beckwith about Project Planning Grids. She also provided links to Todd Warfel's Task Analysis Grid and Blink Interactive's Objects & Actions Analysis. All three posts centered around different grid styles & focuses, but they all discussed ways to map out the different objects/features of a project in an easy-to-understand grid, so that you can flesh out requirements, standardize vocabulary, and understand which items need to be developed when.

Allison & Todd's grids felt higher-level, and included color & position to denote schedule & priority. Blink Interactive's grid was more detailed & was perhaps a better way to ensure you didn't miss a requirement. I could perhaps see starting with Blink's grid to round out your featureset, and then a grid like Allison or Todd's for planning & priority.

At DevelopmentNow we do a lot of project work, so one of the first things we do is map out a project featureset into "chunks" and rough feature descriptions, then assemble them into a basic dependency & delivery list. One of the big aspects in project management is getting scope right, and since there's always a tradeoff between delivery time & overall features, it's important to make sure that you haven't forgotten a critical feature, and that everyone (including and especially the client) understands what will be delivered when. So I can see how the additional dimensions in a grid, along with colors, can help add additional contextual scope information without sacrificing simplicity.

FYI, Todd actually prints out his grids on huge (like 6 feet wide) paper, puts them up on a wall, and talks through them with clients, allowing the client to write on the paper, interact with it, etc.

Some sample screenshots of grids below:

 

As an IT manager, you'll have team members who initially aren't able to get things done as quickly as you or other experienced team members can. A good portion of that productivity gap is due to their lack of your codebase, development process, etc. So one way you can speed their progress is to ensure that they have access to domain knowledge through a wiki, training videos, documentation, shadowing other programmers, etc.

There's an old joke about how knowledge is most of the battle.

There was a business whose expensive machine suddenly stopped working. Since the machine was vital to daily operations, they called in an expert to do the repairs. The expert looked at the machine, checked a few settings, pulled out a hammer, and rapped the machine lightly on the side. The machine instantly sprang to life and the business was able to move forward with its work.

The delighted business owner said, "Great, what do I owe you?" to which the expert replied "That'll be $100."

"100 dollars?" the owner cried. "But you were only here for 5 minutes! $100 for one swing of a hammer doesn't seem worth it."

So the expert quickly wrote up an itemized invoice and handed it to the owner. The owner reviewed the invoice, sighed, shrugged, nodded, and paid the expert his $100.

On the invoice were two line items:

Swinging the hammer -- $1
Knowing where to swing the hammer -- $99

One of the things I do is help new team members know "where to swing the hammer" by suggesting approaches, resources, or even the particular modules, files, & functions that they would probably be working with. I ease up on that direction as they come up to speed, but I feel it's valuable initially to help new people focus in on the problem and still get things done. I'm not robbing them of a chance to learn the systems, since I'm only providing a high-level suggestion, and they'll still be working on the code in depth.

Ice Cream for Everyone wrote about their experiences in hiring a designer, listing out where they placed ads and what kind of candidates they found. Me the Geek also has a list of specialty job boards for finding programmers, and has a great quote (from Michael Arrington) on why companies often choose to post ads on smaller, niche boards:

The idea is that the best candidates read these blogs, and by definition are up to speed on cutting edge tech issues. By advertising there, you get the benefit of access to those candidates, without the hundreds of unqualified resumes that come flying in from a Craigslist or Monster.com listing.

I like playing devil's advocate, so I'll say that while it's true that sharp people keep up with technology, there are also a lot of bright programmers who don't read TechCrunch. There are also ones who read TechCrunch, but not the TechCrunch job boards.

A friend of mine runs a consulting company and had his best success on Monster.com, of all places. He mentioned that while he had to wade through a lot of bad candidates, the mere fact that Monster.com cast such a wide net helped ensure he'd find someone. He also felt that if people were looking for a job, they'd be sure to check Monster.com -- he didn't think there would be many viable candidates who ignored Monster and only focused on niche boards.

Anecdotally, I posted ads on ThinkVitamin and Authentic Jobs, and I did get a number of resumes from really sharp-seeming developers. However, they were on average outside the range that I could afford. When I posted on CraigsList, I actually didn't get as many responses as I thought I would -- largely because posting ads was free (until recently), and so your CraigsList job ad would get buried within a day or two by tons of staffing company ads.

So...maybe I don't get it. Or maybe if you're on a tighter budget, niche boards aren't the right place to look. But now that CraigsList charges $25 per ad in Portland, I might get better visibility.

 

An assortment of links to thoughtful blog posts on how to hire IT folks.

Atlassian's Life is a Hire Way

OnStartups' 6 Subtle Signs You Might Have a Winner

SmugMug's How We Hire

Troy Bettinger's Five Tips for Hiring

And once again, Joel Spolsky's Guerrilla Guide to Interviewing.

And Marc Andreessen's How to Hire the Best People You've Ever Worked With

I wanted to write a little bit on effective IT hiring techniques. But today's a busy day, so instead of a massive essay called "Strategies for Effective Hiring" you just get a Cliffs notes Jank Handy thought list. Which is probably ok since you don't have time to read a giant hiring guide. If you want a big guide, read Joel Spolsky's Guerrilla Guide to Interviewing. It has a lot of good suggestions. Ok, moving on.

Finding Candidates

There's a lot of advice on finding good candidates, and I don't have a magic, easy answer. I will say that good candidates sometimes have to be lured and convinced to join your company. Eons ago, a startup I worked for was able to eventually convince a really good DBA to come work for the company. The IT manager had worked with this guy before & knew he'd be a great asset to the company. Initially our attempts to convince the database superhero failed, as he had a nice contracting gig that he didn't want to give up. But, we didn't give up. After several months of subtle and non-annoying wooing, he finally came on board. Granted, the defining moment was when the future coworker was told by his consulting company that he'd have to start travelling or commuting more. He then contacted us and said, "Hey, tell me again about your new startup, I think I might be interested."

So does that mean you should bribe consulting companies to send their top programmers on crappy travel assignments? No. But it means a few things:

• Good candidates aren't just lurking on Monster.com, CraigsList, and other resume databases. You should ask around, tap your network, and try to come up with a list of good people that you can contact and see what their situation is.
  
• If a person isn't available, don't give up. But don't annoy them, either. :) Listen to them, and just follow up in a friendly way from time to time, letting them know how the company is doing, telling them that if their situation changes, feel free to look you up, etc. This is a basic tenet of standard networking anyhow -- keeping in touch with worthwhile people. If you used to be a programmer, you may not be into (people) networking. But you should try to change that, if you can.
  
• Be in a position to consider great candidates, and try to be a place where people might be interested in working. You never know when a good candidate will appear, so ask yourself, "If I were working somewhere else and wanting to make a move, would I want to work here?" If the answer is "no", you have a problem.

Interview Effectively

I could write a lot this, but I'll try to keep it short for now. Joel's aforementioned article has a lot of good interview tips, but I'll add my own.

Multi-level interview process

Have a multi-level interview process so that you don't spend a ton of time on candidates that aren't a good fit. The levels act as a filtering mechanism, so candidates who don't pass a level get rejected and don't continue to the other levels. 

For me, the first level was often handled by recruiters -- an in-person discussion and some technical screening questions. That filtered out 80-90% of the candidates, so that probably saved me 10-20 hours a week. Well worth the recruiter fee. If you aren't using recruiters, that's ok -- you'll probably just start with a phone screen.

Next would be a phone screen where I would ask a series of questions, talk a bit about the company, and learn more about the candidate. Phone screens were mostly technical questions, and if a candidate was doing terribly halfway through, I would usually not ask the rest of the questions and wrap up the phone screen. If you know someone's a "no," don't spend another 30 minutes. And if you hear a long pause and some clicking after you ask a tough question, you know they're looking up the answer. :) Phone screens probably filtered out another 75% of candidates.

After a successful phone screen, I'd invite candidates to come into the office. I would tell them to plan on being there 2-3 hours. The candidate would come in and meet with me for a bit, and then take a 1-2 hour written aptitude exam. I'd have them wait in the meeting room while I looked through the exam to see if they did well enough. 

If they passed the exam, I'd have them meet with several members of the existing team for 30-60 minutes.

BTW, some people prefer to do the initial screen in person, but I don't, and here's why: 

I went back & forth about meeting people in person vs phone calls for the initial technical screen. An in person meeting will give you more information about whether the person is a good fit, and eliminate the chance of them cheating during a phone screen. However, many of my phone screens ended after 15-20 minutes when it was apparent that they didn't have the knowledge we were looking for. I didn't want to invite people into the office and then send them away after 20 minutes (it seemed rude to me for some reason), and I certainly didn't want to conduct hour-long in person interviews with people that I could evaluate in 20 minutes over the phone.

Technical Screens

For technical screens (both in-person and over the phone), try to ask some open ended questions. Technical questions are good, but avoid obscure ones that even great programmers might not know but that can be easily looked up online or in a book. Ask questions that demonstrate someone has a strong grasp of concepts & fundamentals and that illustrate that they have experience with the language/platform in question. Have a few questions to see if the person is a good thinker, creative, and a problem solver -- I always liked SQL or pseudocode questions for that (e.g. write pseudocode to read a parent-child database and display a hierarchy). The questions partly depend on the level and type of position you're interviewing for.

Bad question: "What are the parameters of <obscure function> and which ones are optional?"

Good questions: "What are some methods to improve the performance of a data-driven web site?" "What is database normalization and what are some pros and cons about it?" "How can you implement caching in ASP.NET?" "In HTTP, what is GET and POST?" "Tell me about your experience with AJAX."

Then listen to their answers -- you'll know how deep their knowledge is based on how detailed and thorough their answers are. You can ask follow up questions if you want. For example, you might ask someone "What is ViewState in ASP.NET?" If they have a good response, you could then follow up with "What are some pros and cons about ViewState?" or "How can you develop an application without using ViewState, and what are some pros & cons to that?"

Have a written set of questions that you can print out when you interview candidates. The document should have fields at the top for job title, candidate name, time and date, and a yes/no decision. Then below can be a list of questions with space below to write down the candidates answers. During the screen, you can ask the questions and jot down their responses (or indicate their lack of response). At the end of the screen, go through the questions and "grade" each one. How you grade is up to you: it could just be Yes or No, or a point system, or grade school like A, B, C, D, E, F. Then go through, and make your decision on a candidate. Try to make the decision right there, and stick with it. The printed sheet is also good because it gives you a written record of the interview results in case your company gets sued later, or in case you're asked why you didn't hire Mr So-and-So, or if you encounter the candidate again in 6 months and wanted to remind yourself why you passed on them before.

Over time, you'll be adjusting your screening questions as you come up with better questions, or realize some questions suck, or that you never end up asking them. Another suggestion is to ask some of your existing staff the questions, and get their opinions on whether the questions are good. If none of your staff can answer a particular question, then that means either your questions aren't very good, or ...

In general, try to involve your staff -- they're a good resource and sounding board for you, they'll (often) appreciate being involved in the process (since they'll have to work with whomever you hire), and it's good training for them if they'll eventually become managers. Some staff won't be interested, and that's ok.

Have your team meet candidates

Your team should interview candidates, too. After the interviewing is done, meet with the candidate a bit more & send them home, then meet with your staff right away and get their feedback. Getting feedback immediately is important because the sooner you get it, the better quality it'll be. And you need to get their feedback anyhow, because if you don't, then you're wasting your staff's time.

Sell Your Company

During the interview process, you should try to talk a bit about what it's like to work at your company and why it's a good place to work. Give them a little walking tour. Think of ways to make your company worth working at, because it'll make your current staff happier, it'll make it easier to attract good candidates, and even candidates that don't get hired (for whatever reason) might come back to you later or tell others about your company.

No company is perfect though, but don't lie to candidates. There's no reason to go on & on about the company's downsides, but I think being honest is important. You establish yourself as someone trustworthy. You also filter out people who would be a bad fit. E.g. if you lie & tell people that the team never works weekends, even though they do, then if someone comes to work for you that really can't accommodate weekend work, they'll probably be grumpy, quit later, waste everyone's time, and tell all their friends what a lying jerk you are. Or you'll be forced to live up to your lie & not make them work weekends, whereupon your current staff will say "hey how come New Guy doesn't work weekends but we do?"

Ah, lies and the web they weave.

Make a Decision

I don't agree with Joel's "if you have any doubts, don't hire the person." I wish I could, but I don't think it's practical for every company, when sometimes you're struggling to even find decent candidates, let alone great ones. I think it's a goal to aspire to, but perfect candidates are often hard to find, and sometimes you need to take a few days to decide on a candidate (or decide between a few good candidates). That having been said, if you know someone's no good, don't hire them. Don't ever be tempted to hire someone you don't like "just to get someone in the door."

And even though HR people will tell me it's a bad idea, I like to get back to candidates and let them know if they haven't been selected. I know the convention is sometimes to just blow people off, but that's rude IMO. I try not to go into specific details, because that can be a legal issue, although if someone's experience is clearly and severely lacking, I say so. Anyhow, candidates appreciate at least being told, "thanks for interviewing, it's not the right fit right now, but we'll keep you on file for openings down the road." It's about respect and honesty, which will help you in the future. People remember that you were one of the few hiring managers that was up front with them, and that your company was the place that employed people like you. And it's good karma.

If the candidate was good but just lacking in experience, I might say something like "you don't really have the experience we need, but keep us in mind and get back to us in a year or two, or if you get a chance to take some training."

Move Quickly!

Wow, did I say this post was going to be short? Anyhow, this is a very important point. If you find a candidate that you want, start them as soon as you possibly can! See, I even bolded that. Ask them when they can start. If they can start right away, get them in the next day, especially if they're good and interviewing with other companies. Have them come in and shadow another team member for a bit, or install a wiki and enter documentation into it, or do research, or something -- just get them in. And get them an offer in writing ASAP. If they're still working, see if they can swing in after work or for an afternoon even, just something to get their feet in the door. Something to physically establish that they are your future employee.

Why get them in right away? Because otherwise they might take another offer between the time they accept your offer and their official "start" time.

I lost several great candidates by not following this rule. I made offers, they accepted, and we set a start date of 2-3 weeks out. But since they were still interviewing, they ended up going with other jobs, or being talked out of the job. A common excuse was "my wife/husband doesn't like <insert random point about your company or the job> so I can't accept the job, sorry." Yes, I know they "accepted" the offer, and it's kinda lame of them to back out. But it happens, and you need to make sure it doesn't happen to you. If they're still working, it's less likely to happen, but it still might.

BTW, it's my belief that the "my spouse doesn't approve" excuse isn't always true (maybe 50/50), but people feel they need to give some sort of explanation on why they changed their mind, and saying someone else vetoed their decision means that hey, they would have kept their acceptance of your offer, but since their better half said no...

Final Thoughts

Ok, I need to wrap this post up. I meant for this to be a quick post, but I guess I just had a lot to say.

So...hiring people is a lot of work, but it's arguably your most vital function as a manager. The more effort you put into finding good people, the happier you'll be.

Well it's been a while since I wrote something, and even longer since I wrote something management-related. So I need to play a bit of catchup.

Programmer To Manager

Before I came to Portland, I was the software development director at ShopLocal, a Chicago-based startup that did a lot of growing, a lot of changing, graduated to medium-business status, did some acquiring, got acquired, and became a popular comparison shopping site, among other things. I was with ShopLocal for over 6 years and started out in 1999 as the (main/only) programmer, working in ASP, VB6, and COM+. The company grew & grew, and over the years I had the opportunity to move up in leadership roles, first as a team lead, then manager, then director.

Towards the end I still considered myself a technical person, but I didn't do any programming, and instead dealt with staff, departments, projects, clients. It was an interesting transition, from programmer to manager, and when I left ShopLocal I thought it would be helpful if I wrote down some of the things I learned and/or struggled with, since I felt that there would be a lot of programmers & other techies who would become managers, some reluctantly, some willingly, some in order to get a pay bump, some to grow professionally, and some in order to stay employed.

Whew. Ok, that's out of the way. Blah blah blah, I wanted to write stuff for new programmer-turned-managers. :)

New Managers Need a New Focus

Anyhow, if you're a new IT manager, and you used to be a programmer or other technical person, you have a new focus and role that you need to bear in mind. I'll just assume you used to be a programmer, but you can mentally substitute in what you used to do.

When you were a programmer, your goal was pretty much to produce code. Your personal technical productivity and effectiveness was the measure of how valuable you were to the company and how well you were doing your job. Sure you mentored others, worked on a team, collaborated on things, etc. But at the end of the day, it was mostly about how well you could produce.

As a manager, it's different. The technical productivity and effectiveness of your department (or team, or group, or whatever) is the new measuring stick. You are judged on how well your team does as a whole -- your personal productivity doesn't matter.

Your personal level of technical productivity is of secondary importance. I can't stress that enough, because many new IT managers (myself included) go through a phase where they're trying to "be a manager" but also crank out code, and they sometimes find themselves doing programmer-type tasks because they are "better at it," or they're the only one who knows how to do it, or it's fun, or it's "only an hour" of work, or whatnot. Don't fall into that trap.

To be a good manager, you need to make sure that your department is producing at optimum level. If you're still cranking out code at a rapid clip, and everyone else in your department is under-utilized, or coding slowly, or putting out too many bugs, you have failed. It doesn't matter if your personal code output is stellar.

Your Department is Like a Web Server

Think of it in terms of multithreaded applications, e.g. a web server. Web servers get tons of simultaneous hits, and their output is measured in requests per second. In order to have a fast web application, the total output of all involved threads is what matters. If you have one thread that's really fast, and all the other threads are dog slow, that's not as effective and scalable as if all threads are decently fast, but you can scale out to dozens or hundreds of threads.

You should keep that in mind as you ponder the question, "now that I'm promoted to manager, how can I be even more valuable to the company than before?" Because that's the truth -- you got promoted, and the last thing your company wants is for the IS department to get worse (other than an initial adjustment period). The irony is often really good programmers have an opportunity to get promoted to managers, which can be a big initial blow to the team's productivity. So to be a successful programmer-turned-manager, how can you help the company produce even more software before, when you're no longer coding as often or at all? The key of course is to ensure that your staff becomes more productive. Think of your staff as the threads of a multithreaded application, and work on ways that each of them can be more effective.

That may be harder than you think. If you were a good programmer, think about why you were good. Was it because you typed quickly? Was it because you knew the API and coding environment? Were you good at managing scope and detecting pitfalls ahead of time? Did you estimate well? As a manager, you'll have an opportunity to teach your staff some of your tricks. Plus, you'll probably be involved in projects enough to still utilize some of your skills (e.g. detecting project pitfalls).

Ok that's probably enough rambling for now. Remember, you are now orchestrating a multithreaded application, and your goal is optimimum combined output. Don't worry about the performance of a single thread (e.g. you) if the other threads (e.g. your staff) are doing poorly or average. Instead, focus on ways to make most or all threads better. You can cherry pick caveats to this, but you need to focus in the right direction first.

I came across Unfuddle today. It's an ASP model that offers hosting for project management tools, source code, and bug/issue tickets. Plans range from free to $100/month.

I've been looking for a simple bug tracking solution, and while Fuddle may not be the right way to go (for me), it seems like an interesting offering. They use Subversion for source code hosting, and a Rails-built platform for managing projects, tracking to-dos and milestones, handling bugs and feature requests, entering time spent, and keeping a project moving along. Might be a good option if you have a small team of developers and don't want to deal with setting up a source code repository, and you're tired of emailing Excel spreadsheets around.

Note that hosting companies like Dreamhost offer easy Subversion setup, but AFAIK don't offer the other stuff -- issue and project tracking.

It's been a while since I posted anything in the management category, so it's time to get caught up. In a past life I was a Software Development Director, so I wanted to write about some things I figured out so that other programmers-turned-sudden-managers have some tips. The below is about goals, and is written for the employee (i.e. the person writing and achieving the goals), but it's equally useful for managers -- just adapt the perspective so that everytime you see the word "You" mentally replace it with "My Employee".

Goals as Performance Review Items

I was thinking the other day about employee goals. Some companies have managers sit down with their employees each year and come up with goals to achieve for the upcoming year. An employee's performance review is then often tied to whether they complete their goals or not. So there's an incentive to be shouting "Gooooaaaaaallllll" at the end of the year.

However, it's hard for many people to come up with their own goals in the workplace. We all know it has to be work-related, and in some professions it's easier than others (e.g. sell 10% more widgets than last year). In fact when I researched this in the past, a lot of the example "good goals" were in terms of manufacturing or sales.

But as a programmer (or other IT worker), in a workplace where priorities can change and projects come and go and get completed in months or weeks, what do you do? What are some goals you can choose and have a chance at pulling them off?

Be Smart About Your Goals

First of all, let's review some basics on goal picking. There's an acronym for good goals: S.M.A.R.T. (or as a friend liked to say, "TARMS"). I've seen many versions of what the different letters mean, but in genenral SMART goals are

• Specific
  • What specifically will you do? Answer the Who, What, Where, When, Why behind it.
  • Bad: "Do a better job of estimating effort" 
  • Good: "Have my actual effort come within 30% of my effort estimates, on average, for my web development projects in the next six months."
  • Other meanings for "S":
    • Stretching: it should be a challenge for you
    • Significant: it should be important
    • Systematic: it should be something you can work on or chip away at
    • Synergistic: working towards the goal should not be at cross-purposes to getting your job done -- you don't want feel like you're stealing time away from your "real" projects to work on your goals. It would be ideal if working towards your goal is incorporated into or part of doing your job. This is particularly important for employees who are already overloaded at work and don't have a lot of free time outside of work.
• Measurable
  • How will you and your manager know if the goal has been achieved? There should be some criteria for knowing that it's been completed. Anyone who deals with project management should be familiar with this theme.
  • Bad: "Learn C#"
  • Good: "Complete a C# class this fall and get a Brainbench C# certification by the end of the year."
  • Other meanings for "M":
    • Meaningful
    • Motivating
    • Memorable
• Acceptable
  • The goal should ideally be set by you, or at least acceptable to you. You should have a desire and willingness to complete it. It should be something you're interested in and that will have real value for you when it's completed (other than just a performance bonus based on goal achievement). For example, will you learn a new skill or technology? Will you feel a sense of pride and accomplishment?
  • Bad: "Devote an extra day a week to code maintenance on our legacy systems" (unless you like legacy maintenance, in which case I have some jobs for you....)
  • Good: "Research new technology and development techniques and deliver a proposal on upgrading some of our legacy systems."
  • Other meanings for "A":
    • Attainable: this is a common meaning for "A". It closely overlaps with Realistic, below. 
    • Action plan: you should put together a plan on how you will accomplish your goal
    • Agreed-upon: similar to Acceptable, it should be something that the manager and employee both agree is a good goal.
    • Accountability: you should be accountable to completing your goal, and failing at it should require an explanation from you as to why. Not achieving your goal should be seen in a similar light as not completing any other project.
• Realistic
  • You should be able to actually attain this goal. It should be a bit of a challenge to accomplish, but not so much that it's a hardship. It should require a level of commitment from you.
  • Bad: "Run 1 mile a month" (too easy) or "Work out twice a day" (too much)
  • Good: "Register, train for, and participate in the marathon this year, including finding a training regimen and/or running club appropriate for beginners"
  • Other meanings for "R":
    • Relevant: it should be relevant to work or your career. It probably shouldn't be "Take a wine-tasting class this fall." FYI, I feel a fitness- or health-oriented goal is OK as long as you have other goals that are more IT-focused. IMO a healthy, fit employee is beneficial to the company because they're less sick, have more energy and less stress, can save the company money on health insurance and/or workers compensation, and can inspire fitness in others. Plus they're better able to help lug those 21" CRTs to the new office. ;)
• Time frame
  • There should be a timeframe or deadline for completion of the goal. This is part of being Specific, but having an end point helps encourage employees to get it done.
  • Time frame also means you should know when you're going to be able to work on your goal. Do you have available time to complete it? When will you work on it? How much time will it require to complete? There are a lot of people who are overloaded at work, working 50+ hours a week, and have full and equally-demanding family lives outside of work. Those people will need to sacrifice something to gain the time they need, or choose goals that don't require as much time, or get their boss to free up their work schedule a bit so they can work on their goals.
  • Bad: "Take a C# class sometime" or "Write a 1000-page book on project management next month"
  • Good: "Take a C# class in the evening next quarter" or "Write an article on project management next month and submit it to at least 3 web sites and magazines."
  • Other meanings for "T":
    • Tangible: a goal that can be measured on paper or in an otherwise physical manner is tangible. But IMO that's too closely tied to Measurable

That's all for today, but next time I'll follow up with more suggestions, guidelines, and ideas for goal-setting in an IT world. I'll write more for the manager's perspective.

 

 

SADeveloper has an interesting article on programmer productivity, basically along the lines that a good programmer can be 5-20 times as productive as a poor one. My first boss drilled into me that "software development was one of the few professions where a one person can be ten times as productive as another." And I believe it -- poor programmers can screw up code, get stuck constantly, miss requirements and have to re-work things, deliver bug-ridden code, etc. Other "creative" professions (science, music, etc.) are similar in that the productivity gap can be surprising.

Ray from CodeBetter had some interesting counterpoints to the article, but I've seen firsthand how much poor developers can stink. If you remove all thinking from the task, then the only measurement you'd need was typing speed & mouse-hand speed. But that's not what defines the productivity of a developer -- it's what their brain does that makes the difference.

Now, the funny part is I think with proper training, a good architect, smart division of labor, & in-place processes, you can narrow the productivity gap. Someone who sucks should be moved or fired. And in a gunslinger code culture, your rock stars will always smoke the average Joes. But what if you instead have

• training so that everyone knows the project process
• an actual project process that minimizes problems of scope creep, requirements confusion, and implementation/architecture snafus. RUP comes to mind, but there are others (MSF, XP, etc.).
  
• dedicated people for the tasks that "poor/average" programmers often mess up on (architecture, project planning, requirements, etc.)
• a software architect who can divide tasks among developers according to their skill level
  
• a culture that encourages learning and asking questions
• a good screening system to get rid of or avoid hiring people who don't work well in teams
• a mentoring system to pass along tips and information

With the above, I think you can reduce the productivity gap. You eliminate or reduce many of the issues that cause weaker developers to fall so far behind their counterparts. You'll still have faster and slower programmers, people who can devise algorithms or who know their APIs and patterns backwards and forwards instead of having to Google them all the time. But time and again, some of the biggest sandtraps I've seen programmers fall into are ones related to architecture, project management, and failure to follow a methodology and process that guides people towards better applications.