Overall, I agree that smaller teams move more quickly and swarm more effectively on task than large ones seem to, and that there is definite overhead with large groups.
You already know some developers are more effective than others.
What if you could find 1000 within the 2000 that collectively are twice as effective as the other 1000?
Joel Spolsky has claimed the best programmers can be as much as 10 times more effective than the worst programmers.
The argument continues describing how many developers are much better than others, and are better in a smaller group than they can be when they are encumbered by less competent programmers.
I also agree that smaller teams of more expert programmers make sense on many levels and represent a savings in frustration, cost, and time.
As Red Adair would say: "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur."
Mythic "better people"
I don't think that Curtis is wrong. I have seen teams with too many programmers, staffed hurriedly with warm bodies or with badly-defined HR requirements and biases towards archaic styles of work and project management.
I've seen managers repeatedly hire and fire for the same position, complaining "why can't I find the people who can do what I want them to do?"
Should we consider a different question: Are we asking for feats that real people cannot perform?
There's an old saying about marriages that "If it's more than two, it might be you." I suspect this applies also to revolving door positions in a company.
Sadly, a lot of these revolving door positions exist when we are looking for unicorn developers -- magic omni-competent people who have hyper-productivity and efficiency installed in their DNA. People who never say no, never complain, and always deliver just the right thing on their first try and are never a problem to manage.
They are "better people." Programmers on staff, are, by comparison "not very good people" -- evidenced by the fact that we want more stuff than they can deliver. We're already frustrated with the system we have, and the answer must be "better people."
 |
| The Mythical SuperDeveloper |
Should we consider a different question: Are we asking for feats that real people cannot perform?
There's an old saying about marriages that "If it's more than two, it might be you." I suspect this applies also to revolving door positions in a company.
Sadly, a lot of these revolving door positions exist when we are looking for unicorn developers -- magic omni-competent people who have hyper-productivity and efficiency installed in their DNA. People who never say no, never complain, and always deliver just the right thing on their first try and are never a problem to manage.
They are "better people." Programmers on staff, are, by comparison "not very good people" -- evidenced by the fact that we want more stuff than they can deliver. We're already frustrated with the system we have, and the answer must be "better people."
Deming has offered us the sound bite that 94% of our problems involve the system, and only about 6% of them are attributable to individuals. That's harder to see when the work is largely invisible, as is the case with knowledge workers, instead of physical laborers.
It's just easier to see progress when work is motion and products are physical. All sympathy for that problem, but it goes wrong when we try to make management easier by treating knowledge work as if it were physical work. Sometimes we want people who can do great information-type work as if it were great physical-type work, and who make management and measurement easy. Such is the nature of bad HR requirements.
It's just easier to see progress when work is motion and products are physical. All sympathy for that problem, but it goes wrong when we try to make management easier by treating knowledge work as if it were physical work. Sometimes we want people who can do great information-type work as if it were great physical-type work, and who make management and measurement easy. Such is the nature of bad HR requirements.
Not recognizing the information-nature of the work makes industrial-age management a really bad system for managing software development, and "a bad system will beat a good person every time" Deming would quip.
Bad Systems?
Size may be the symptom of organizational dysfunction.
It may be that the organization isn't dealing with people well, and so it must have many of them. If it is only 10% effective, it certainly feels as though the organization needs 10x as many people.
An organization's system may involve too much process around getting permission to do work, too many cycles through finished-work approval processes (reviews, QC, expenses, time reports). All of these can prevent quick feedback and learning. Without feedback and learning the productivity of programming is significantly limited.
The system may have strangled productivity so much that all the work being done is treated as a one-off rush job.
Perhaps the code base has been rushed so much that it has started to take its revenge in the form of immutable code and multiplying defects. There are always consequences for deferring crucial tasks indefinitely.
There might be a planning problem at hand, where the organization is trying to do large things in a single step. Without small steps (story slicing) and continuous delivery, there is no chance to exercise options. Instead the problem seems to be all about "going faster." Perhaps cutting scope is smarter and less expensive than adding headcount.
Or possibly you have evolved the system to work with 2000 developers during a rapid growth period only to find out now that you can't operate your current system as-is with only 200 or 20. You will need a whole new (simpler) way of working to get back to being productive in small numbers.
Good Systems?
But maybe you have great people that you've worked very hard to gather and train and educate and you have given them reason to believe that you are looking out for their interests.
Perhaps there are many of them because you've had such a great growth in the market place and having more experts (and a steady stream of new thought leaders) has kept you operational and cutting-edge.
Maybe you are an extremely good organization with a great culture and your success has blessed you with fairly deep pockets.
Maybe you are just looking for a way to continue operating, produce results well, and not break your commitment to the people who look up to you.
You just don't want to let go of the people you have, and they don't want to go either. Maybe a lot of these people have shown leadership interest and potentially, and have earned jobs in management.
You want to preserve your organization because you have taken responsibility for the well-being of your chosen tribe. Good for you. I see nothing wrong with that. I do recognize that it leaves you with some difficult questions and issues. I want to help.
You want to preserve your organization because you have taken responsibility for the well-being of your chosen tribe. Good for you. I see nothing wrong with that. I do recognize that it leaves you with some difficult questions and issues. I want to help.
Maybe the question isn't so much about how few people you really need, but how to maintain a humane, productive, innovative culture and introduce products now that you have the critical mass to take on many projects at once.
It may be that un-encumbering people by using a more lean or agile process will free up resources to do more creative and innovative work -- along the line of Google's famous 20% time.
It may be that un-encumbering people by using a more lean or agile process will free up resources to do more creative and innovative work -- along the line of Google's famous 20% time.
Curtis didn't say that you have too many people. He only suggested that you might.
No comments:
Post a Comment