10 analogies for creating software (that aren't building construction)

Software has long suffered with the analogy of building construction. While it is certainly handy, and generally well accepted, I would like to propose my top 10 alternative analogies for software development. 

10- Politics

Creating software is like being an elected official. You get into it to do something, achieve something, and participate in something larger than yourself. You are "forced" to take on non-productive tasks like fund raising and campaigning. Eventually you stop fighting it and set aside a (growing) percentage of your otherwise productive time. Accomplishment slowly moves from what you can do to what you can get others to do and success is measured through polling and statistics. Instead of counting delivered projects, you know what percentage of projects succeed; in place of consistently delighted customers you trend against customer satisfaction scores.

9- Music

Great software is like great music, you might not know it when you first encounter it but compared to some number of others it feels better. It’s a bit more popularity contest then technical superiority that makes great software great. The more people talk about it, the more they promote it, the more "air-play" it gets, the better it becomes. The music industry tracks number of spins and downloads. The software industry talks about de facto standards and broad usage. Neither speaks to the actually quality in any measurable way. Even underperforming is similar in both products. Really bad music, like its software counterpart, just doesn’t get a chance. It is generally identified by a select few and prevented or withheld from the intended audience.

8- The law

Good software, like a good law, is the result of collaborative debate but rarely complete consensus. Great laws, like great software require time ... lots of time... in the real world. They need to be poked and challenged by those impacted by them. They need to be enforced to ensure a large population complies while at the same time requiring a set of experts to judge them in context, interpreting original intent against actual performance. Both may be modified to account for unforeseen circumstance but neither, once broadly accepted, can be readily discarded by the system that created them nor the population they effect.

7- Battlefield management

While I don't mean to in any way belittle the heroic efforts and significant risk to those in real battlefield situations; software, particularly large complex solutions, required a level of persistent focus and simultaneous strategic thinking comparable to battlefield management. Leadership, good or bad, radically impacts the outcomes. At any moment in time there are hostile activities encroaching, counter insurgency tasks in various states of completeness, supporting logistical efforts in flight, and long range strategic planning efforts undergoing review and change. All of which require error free, clear and decisive decisions. The ongoing dance throughout the team hierarchy (and even the most agile processes have a hierarchy) relies on clear communication and a willingness to do tasks without too much regard for the "bigger" picture. Success is clear in the small and much less so at the macro levels. In both software and battle, victory is as much a state of declaration as it is fact. A solution is baselined be decree, and you may or may not move immediately to the next skirmish / release.

6- Mobs and animal packs

Take a number of people; give them a singular, albeit ambiguous goal. Allow them to self-organize both as they relate to each other and how they address the work at hand. Accept the fact that bad things will happen and progress will not always be in the "right direction”. Congratulations, you have a mob ... or a software development team ... what's in a name anyway. Even the biggest most organized software shops have internal cliques, undeclared leaders, and sheepish followers. It is natural to seek safety in the herd and even more natural to blindly follow when "everyone" seems to be turning in a particular direction. Oddly, this is more a benefit than an issue for the development community. If too many individuals work too independently the solutions are never built, predators eat the heard one-by-one, or the herd simply abandons the individual instead seeking a consistent group dynamic over the pending chaos. Software, built by the collective, is successful of the collective survives to bill another day.

5- Medical diagnostics

When you have a problem you go see a doctor. When our customers have a problem they turn to software. Oh sure, there are times when things are going well and an organization takes preventative measures. It might be improved exercise and diet or the software equivalent of continuous improvement and rigorous process. It might be a simple yearly check-up where they review well-known and meaningful measures from the last period against the current state or identify metrics that don't seem right and require additional action. Unfortunately these preventative good habits are truly rare in the IT world. Instead the most common case is to deal with a traumatic injury. To reactively mobilize, triage the issues, occasionally diagnose the underlying cause, and devise a treatment which will at least relieve the symptoms. Some customers are delighted to "feel better", some demand a real cure and other are simply hypochondriacs, never satisfied, always fearful, and would rather see activity and never actually concern themselves with progress.

4- Diplomacy

Whether it is your first time in a new culture or your first foray into a new business vertical, software professionals need the skills of a diplomat. They need proficiency with multiple languages, and enough empathy to intuit what isn't stated but is still required for understanding. If a stranger from a strange land who doesn't speak a language you recognizes sits across from you, lifts a cup of liquid from the table and says "flubber", what do you suppose they are telling you? "Flubber" is cup? Or is it liquid or are they toasting to you? Creating a software solution that adequately addresses the needs of real people requires soft skills before hard skills. Much like a diplomat, IT professionals need to gently interrogate customers, users, stakeholders, team members, and peers. Listening and questioning trump pure knowledge every day. Generally imposing ones assumed knowledge too early in the process creates haunting errors un-resolvable later on. What one might know to be true is irrelevant in the face of learning and understanding what those around you believe to be true.

3- Team sports

Building software has more in common with team sports than simply requiring a well-functioning team to succeed. Unlike brick and mortar construction which has a large number of well-known examples against which complete can be judged, both software and team sports play until they are out of time. They strive to achieve throughout the available time period but the time box rules the overall process. How much you achieve, be it points or requirements, touchdowns or iterations, goals or scenarios, is fluid. More often than not success is doing just a little bit better than the customer expected. Delivery alone is good, but beating the point spread makes everyone that much happier.

2- Driving in dense traffic

Building software is like driving in dense traffic. You control your immediate surroundings and there are clear boundaries between what you can affect and what should affect you. You look ahead and change lanes based on the conditions of the moment only to have those conditions change immediately afterwards. Others nearby have goals of their own. They too are empowered with little thought of you or concern for your choices. You’re as much a part of their changing environment as they are of yours. No car in the flow can make a choice in isolation. Just like the evolving subsystems within an enterprise. Each seems discrete. Planning, based on known current and best guesses of the future, is important, even useful, but must continuously adapt. Changes made to any one will, intentionally or through unpredicted side effect, impact all others.

And my number one replacement for building architecture as a metaphor for software development is;

1- Sailing

Leading a development team is much like captaining a ship. You know where you began, you were there. You know where you are for the same reason. You know where you want to end up and you have a plan to get there. You lean on your experience and the skills of your team. You apply the best tools available. Even so, the weather, the tides, and the general randomness of the universe will find a way to challenge you. Simply following the coast line requires continuous observation. Every detail of every part matters, and every part doesn't work perfectly. The plan on paper is nearly a straight line, but the real world finds even the smallest variation from perfect and creates unforeseen challenges. When things are going well you must look for the problems you might have missed. You need to perceive the unseen rocks below the waterline. Usually, things aren't going to go well. You adapt, adjusting course, conceding time, but never forgetting the destination. Anything less would leave you and your crew simply lost at sea.