How Analogies Can Destroy Your Software Company
Back in high school, when it came time to take the SATs, I scored much higher on my math than my verbal. Perhaps it was due to analogies such as this one:
LUMMOX: CLUMSY ::
A) boon: beneficial
B) egotist: conceited
C) rascal: predictable
D) maxim: hackneyed
E) toady: important
One of the worst things you can do to your software company is to make up an analogy to help explain the software development process to yourself and others. Analogies are great in poems, fictional writing, and, to some extent, when writing arguments. The right analogy can make your writing interesting, make it come alive. The right analogy can win over a skeptic. When applied to the software development process, and management thereof, it can grow into a untamed, all-consuming hydra that leaves a trail of burned-out developers in its wake.
Let’s go over some software management/development analogies I have encountered out in the wild.
I am the Captain, and this is my Ship
The origins of this analogy are as old as time itself (or at least, the invention of travel by sea). The sea, a powerful uncharted mass, full of mystery – and possibly deep, evil sea creatures with a blood-thirst for man, or the false and alluring death song of the sirens. One tiny ship expressing the will of its crew braves her waves and lightning storms to reach destinations unknown. The ship, the vessel: a fragile creation of man easily smote by the whims of Neptune.
Managers that come from naval (or general military) stock seem to be especially prone to this line of thinking. Joel Spolsky called it the Command and Control style of management. There are two company-killing premises with this analogy.
#1: The captain has absolute authority and responsibility over the ship and its crew.
Nothing could be further from the truth in a typical software project. While software management definitely should plan and guide higher-level company goals, authority and responsibility are shared elements between management and developers or should be if they aren’t. Developers have insight into the technology, scope of work, and the huge responsibility of estimation. To deny them to set realistic deliverables and provide honest feedback about the technological choices is to ignore your first level of quality assurance. Early choices can and should be critically analyzed by the people who will eventually execute them, well before any customer (or competitor) are aware of your upcoming product. If you truly care about what emerges from your software production, authority and responsibility needs to be more fluid between management and development. Your developers will thank and respect you for it.
#2: The captain is always at the helm, to guide the ship, especially in the eye of the storm.
First, there’s no storm. If there’s a storm, it’s because management failed to listen to developers and set realistic deadlines (see #1). Also, the analogy that management steers the ship, or sits at the controls of the factory, or any other Great Commander-based analogy suffers from a completely unrealistic view on the nature of abstract work. Abstract and creative work is not dictated nor directed from above or without. In this type of environment, what is really happening when a manager retreats into her office is that she’s being a coward. Instead of doing the hard work of software management, she has decided to “focus on the big picture” in her office until the developers manage to eke out something unworthy of a release, usually late. This premise is a really courageous-sounding way of saying you’re going to stick your head in the sand until the problems go away.
The Captian can sink your company to the bottom of Davy Jones’ locker. Developers that appear to thrive under the Command and Control model are actually a class of authoritarians, the ones who prefer to have a strong, external guidance to their actions. Such developers are not your spontaneous and creative types. It’s not a judgement on authoritarians, but they’re more suitable to handle more visceral matters, such as server/network maintenance and databases. Developers that aren’t followers will feel alienated and leave your company. Over time, you’ll end up with a loyal crew, but they won’t innovate past what could be a myopic view of your world and your products.
I am the Zookeeper, and these are my Animals
This analogy can take on various forms, such as Gardener/Plants or Father/Children. Managers that have children or have strong religious inclinations seem to be drawn to this form of thinking. The basic idea is that developers are wild savages, driven by base instincts and do not recognize the more refined and civilized nature of Business. The behavior of the manager operating under this analogy will be to satisfy each developer’s environmental needs. This could be done by providing sufficient hardware, a quiet environment, snacks, unfettered internet access, etc. The thinking is that if you take a developer and put them in a clean cage with plenty of access to food and water, software will be produced without further interaction. If a developer escapes, say, to go kayaking over the weekend, the Zookeeper needs to fetch the developer and make sure they return to their cage to produce more software.
Some people thrive under this laissez-faire management style, in other fields, because other work lends itself to much easier cross-collaboration and interaction with different stakeholders. In software development, business people need to recognize that a successful product serves an audience, and is more than just the sum of requirements and specification documents. Without a business analyst on-hand, and some level of feedback, software development ex nihilo is to dream the impossible dream. You’ll get a product that serves the interest of the developers that works to make their jobs easier, all while ignoring your customer’s real needs. The failure to communicate these needs, to perform the duties of management, means a sub-par product, and inevitable failure of acceptance in the market.
That’s not to say you might get lucky. Developers that are passionate and care may go the extra mile and consult the business analysts themselves. Don’t count on that. Often, this behavior leads to the Zookeeper putting a quick stop to it. After all, if a developer isn’t with his hands on the home keys, then the software isn’t being produced. This is a similar manifestation of the Captain/Ship analogy, in the sense that developers somehow can’t be trusted to make appropriate decisions on behalf of the business. If you hire great developers, they are also great abstract and creative thinkers. To deny them input, to view them as wild savages running around your office, is to do your company a great injustice.
The Zookeeper threatens your company because the answer to great software productivity is not always a third monitor or a foosball table. In trusting their opinion, you are validating their view of developers as wild. In sequestering developers from the rest of the company, another form of alienation takes place over time. Developers lose connection to the business case for your software, and your other business units start to view development with resentment for all their perks. If only the groups were to communicate together, they would have common ground to produce a superior product. Isolated, both sides take a toll.
I am the Surgeon, and you are my Assistants
Scalpel, stat! Sometimes, the worst software managers are those with prior software development experience. They were the best of the group, and other developers looked up to them for advice. Naturally, a promotion was in order. First, to software lead. Then, to full-time manager. Only they never quite made the transition smoothly. When the deadlines started slipping, this type of manager assumes the role of the Surgeon, the great mind with his hands in the patient’s body cavity, saving a life. The patient is this busted up software project, that is literally clinging on to dear life. Who mangled it? None other than these other untrustworthy and unskilled developers lower on the chain.
If you have software manager that is all too eager to clean up after other developer’s coding mistakes, then you have a Surgeon problem. She might tell you the developers are incompetent, unable to follow the grand software architecture she planned out. She may only delegate the most mundane tasks, such as shell-scripting, SQL scripts, reporting, or creating data access objects. She is also quick to take all the credit for all successes, and quicker to throw the Assistants under the bus when things fail.
This and other similar analogies rooted in pure ego can and will destroy your company. No developer wants to work with somebody like that. High turnover follows the Surgeon, which is the death knell of any software project, or your company if you depend on software releases. It is preferable to have a headless software department than to allow such a scenario to play out.