You're the manager of a big firm with little or
no training in software development. Nonetheless, you have
been placed in charge of a large software project. You
decide to make a list of those skills needed for the
project and go seek them.
Or, alternatively, you are an HR person who has been handed
the above list and has been instructed to seek out a set
of engineers who meet those qualifications. So you rely on
a time-honored principle and assume:
All engineers are basically the same. If someone has the
words OO Design or C++ on his resume, then it must be there
for a good reason. After all, these people have gone to
college for this stuff, haven't they?
Despite what we hear, all engineers are not interchangeable.
Two people can be in the industry for the same length of time
and have widely different ranges or depths of experience.
Also, don't assume that since a person has "six years of
industry experience" and "Smalltalk" on his resume that that
means he has been programming in Smalltalk continuously for
One common application of PlugCompatibleInterchangeableEngineers
. If Team A is working on a project you can take it from them and give it to Team B with no loss of schedule or scope; after all, the two teams have the same skill sets. Large corporations play FungibleTeams
with enthusiasm. In such a corporation, it is common for a team to spend as much time defending their ownership of a project as they do creating software.
emphasis on frameworks and libraries is (ab)used in the push for PlugCompatibleInterchangeableEngineers
are mistaken in their thinking that knowledge of the libraries has any relationship to knowledge of the domain. The result is lots of awful code.
When I was about to go to college, the head of an engineering department told me that when I graduate with a degree, all I will have done is demonstrated is that I know how to learn. The real learning is life-long and continuous.
I've also seen articles that mention that it is far more important to hire based upon proven ability to acquire new skills rather than specific skills that you may need currently. I prefer multi-lingual developers and when I see someone who isn't I have to ask myself why. I'm sure everyone knows of at least one engineer or developer who never decided to move on from their particular language. Reality is not very tolerant of that. At worst, an organization staffed with people like that is bound to become a time capsule. -- MichaelFeathers
I would agree with this point. Let me put it another way: if you are hiring someone to be part of a company, would you rather have the guy that is a "hardcore Perl Guy" that insists every problem calls for 'something I pulled from CPAN', and refuses to learn new skills (yes, they are out there, and posting on slashdot.org), or the guy that fell into software a few years ago while working on his English Literature degree. I can tell you: the ones with college degrees in something interesting often are a pleasure to work with. (Compared to that Perl guy that never finished college because his Comp Sci professor 'wasn't teaching what I wanted to learn'...
I smell over-generalization here. Hard-core Perl shops can get a lot done (I am not a Perl fan, BTW). Also, are you saying that the literature guy was more productive, or simply more entertaining?
You are managing two projects, both of such a high priority that you cannot assign an engineer to one of them and ignore the other.
Assign the engineer 50% to one project, and 50% to the other. This makes excellent use of the engineer's time. People can easily devote exactly four hours of thought per day to one project, and four hours to the other.
And if there are three high-priority projects, assign the engineer 50% to project A, 50% to project B, and
50% to project C.
In the situation above, the engineer will normally work one of the projects and ignore the other. The real solution is to work one of the projects to completion and then do the other. Parallel task lines on a schedule look nice and they save you, as a manager, effort in explaining why something has not started yet, but parallelism does not get the tasks completed any sooner. Serialization is the most efficient use of resources to get the projects completed in the least amount of time. Being full time on a project is almost always better than being split - unless you're stuck or waiting on somebody else. When you're full time then the project gets your "shower thoughts". By working one to completion and then the other you finish on average ahead of when you would have with a parallel approach.
Splitting the engineer between two tasks means it takes longer to complete any of the tasks. Simple example with tasks A and B, ignore transition time.
A is completed in 5 time units, B is completed in 10 time units.
A is completed in 9 time units, B is completed in 10 time units.
Depends entirely on the personality of the engineer. Some engineers thrive on multitasking, some don't.
But serialization of tasks creates bottlenecks along the CriticalPath
that the PointyHairedBosses
can see in their MicrosoftProject
What if you put all the user stories from A, B, and C into a big pile and then started working on the most important story out of all three projects.
Then you'd be doing what that MicrosoftProject plan (and good project planning practice) suggest anyway
This pattern also works with a salesman who sold a software project to a company and who happens to lead the development team.
I think it's important to remember that while engineers may not necessarily be 100% interchangeable, this does not mean they are not replaceable.
See Also: SpecializationIsForInsects