Plug Compatible Interchangeable Engineers

Name: PlugCompatibleInterchangeableEngineers

Problem: 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:

Solution: 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?

Discussion: 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 six years. -- KyleBrown

One common application of PlugCompatibleInterchangeableEngineers is FungibleTeams. 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.

The JavaLanguage emphasis on frameworks and libraries is (ab)used in the push for PlugCompatibleInterchangeableEngineers. PointyHairedBosses 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?

Related pattern:

Problem: 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.

Solution: 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.

Refactored Solution:

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.

Pragmatic Objection

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.

AAAAABBBBB

A is completed in 5 time units, B is completed in 10 time units.

ABABABABAB

A is completed in 9 time units, B is completed in 10 time units.

Personality Issues

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 reports.

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.

AntiPattern/CategoryAntiPattern.