The Swiss Army Knife Approach to Software Engineering

Swiss Army KnifeThe Swiss Army knife is a popular tool. Since its origin in the Swiss Army — yes, really — in the late 19th century, they’ve become so popular that they’ve also turned into a colloquialism for adaptability and usefulness.

There’s only one problem with that: The Swiss Army Knife is not the greatest knife. It’s also not the greatest can opener. Nor is it an awesome screwdriver, or a stellar saw. So why the appeal? Because it’s better than not having a given tool at all. After all, a decent screwdriver is better than nothing. The same goes for a can opener and a saw… and a knife.

You actually have three choices here:

  1. Don’t have the tool at all. This is the kind of behavior that leads to either using odd tools (a dime to turn a screw), or to borrowing someone else’s saw.
  2. Have the best version of the tool. Buy the best knife you can find, a good can opener, a great saw, etc. It’s expensive and takes up a lot of room, but it’s doable.
  3. Compromise. This is how you end up with a Swiss Army knife. It’s not the best of anything, but it’s convenient and relatively cheap.

The Swiss Army Knife of Engineers

The same is true when it comes to engineering. Particularly in Agile methodologies, there’s a lot of talk of generalists being more desirable than specialists. SCRUM is predicated on the idea that the team can pick up each other’s work to meet their collective commitment, which implies that each member can do each task. In other words, they’re generalists. Kanban is similar. Engineers don’t take the top thing off the backlog that meets a particular team member’s skill set. They just take the top thing off the backlog. Again, generalists.

Generalists are the Swiss Army knife of software engineers. They probably aren’t as good at any one thing as a specialist (a database engineer, for example, or a release engineer). The theory is that the generalist is good enough, and that versatility is more important than the improved quality of specialization. It’s convenient and relatively cheap.

The Right Tools and the Right Team

When I’m putting together an engineering team, one of the first decisions I have to make is whether to build a team of generalists, specialists, or no team at all. Let’s look at those three choices again, this time through the lens of software:

  1. Don’t have the engineer at all. This is doable, as long as the company is willing to use compromise tools (WordPress instead of a custom website, for example), or is willing to borrow engineers when they’re needed. For companies whose business isn’t technology, this is often a great choice. I have a client whose business is selling toys. They don’t need a software department; they need to hire a development firm when they have a software project.
  2. Have the best version of the engineer.Hire a great database engineer, and a stellar designer and someone who breathes JavaScript. It’s expensive — specialists who are that good command a premium. It creates bottlenecks in software development since, say, no database work is going to get done when your database engineer is on vacation.This option’s also sometimes worth the increased expense and development overhead, particularly when you face special software or market needs. Several years ago, I worked for a company which differentiated itself with amazing UI design and a great user experience. It hired designers — specialists — because they were worth the expense and development slowdown.
  3. Compromise. Hire engineers who can work on a a database schema in the morning and a JavaScript-heavy UI in the afternoon. They won’t be the best at either, but they’ll often be good enough, and the team’s overall delivery speed will be much faster than it would be with specialists. An engineer is out sick? No problem. Another can pick up the last of his tasks and get the feature done. For most of my clients, where speed of delivery is more important than pushing technical boundaries, this is a perfectly acceptable way to build a team.

Like a tool set, an engineering team is about balancing cost and specialization. Your challenge is to make the choice that’s right for you and for the problem you’ve got to solve.

Image: Victorinox

Comments

  1. BY David Strom says:

    Catherine, I really like the way you have presented this. Not every job requires a hammer, despite our attempts to try to bang things around. Thanks for presenting this so clearly.

  2. BY Lee Crites says:

    The problem I am finding is that companies are now advertising for folks who are not generalists, but specialists in EVERYTHING. Job reqs state “significant experience” in virtually every point. As a generalist who has a very wide array of skills, I can speak to most of the needs of most of the clients I talk to — until they start asking minutia that only someone who truly has “significant experience” could answer.

    I recenly had an interview where I was asked to VERBALLY write an entire start/stop/restart script for a *nix service. One shot through the code, not in writing, but verbally. I’ve written these in the past, but nobody in their right mind would wait for someone who had done so many of these that they could accomplish this task. It was one of 18 points on the resume, and all of them had similar questions. Another was “write a regular expression to validate every possible phone number, including extensions and European numbers.”

    If the market is truly working on getting generalists, this would be a wonderful thing!

  3. BY Bobalicon says:

    @Lee Crites – in your next life, pick a standardized career where you learn the subject material once. Law, Medicine, Dentistry, Nursing, and Pharmacist are career paths that quickly come to mind. That way, you won’t have to be a jack of all trades, expert of none.

  4. BY RMS says:

    I disagree that a generalist is probably not as good as a specialist. I am a “generalist” but I’ve been told I excel at a couple of skills/tools. Aza-Matter-of-fact more than once I had to pick up a mess caused by a “specialist” with zero grasp of the world beyond his specialty.

    I suspect many generalists do in fact excel at one thing, whilst being capable of doing other things, and having proven they can learn to do just about anything. Therefore I suggest seeking a specialist who enjoys the specialty but for personal reasons also enjoys doing other things as the opportunities are presented.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>