Of Snowstorms and Software Development

Explaining Software Development in terms of Snow

This winter has been brutal in the US. Record snowfalls, the Polar Vortex, crazy ice storms. I love analogies, because I think they can help non-technical people understand technical concepts. So what can snowstorms teach us about software development? More importantly, how can we use these analogies to explain these issues to non-developers?

How To Shovel a Driveway

How many times has this happened in your software development career? You are given an incomplete specification, or no specification, and asked to just start programming something. Or, you are asked to start some inefficient process (say, deploying some software by hand) because it will be faster than doing it the "right" way. (I'll talk about "The Right Way" in a future blog post.)

Or you've been asked to work on a single feature for a single project, knowing that it is (or should be) identical to the same feature in another project. But the software teams are divided by project, not by feature. For example, in pharmaceutical software development, there is often a team dedicated to a particular (prescription!) drug, with redundant development being done across teams.

How can you explain to management what they need to know about software development, when they don't recognize the things you take for granted (code re-use, automation, etc.) as valid and relevant?

I like to use the snowy driveway analogy.

Suppose your manager says, "Please, shovel the driveway."

Here are the things you should ask in snow-terms (and business terms):

• Is it even snowing yet? (Is there anything to do yet?)
• Do I have a shovel? (Do I have the necessary tools?)
• When is the snow starting? (When does the first requirement come in?)
• How long will it be snowing? (How long will requirements continue to come in?)
• How much snow do we expect? (What is the scope?)
• What is the reliability of the weather report? (Do we have an accurate spec?)
• Do we have enough shovelers? (Who else do we need on the team?)
• Should we get a snowplow? (What equipment do we need to buy?)
• Should we hire a plowing company? (Should we hire a contractor or outsource it?)
• Am I physically capable of shoveling? (Do we have the talent and staff to do this?)

On it's face, this technique seems juvenile if not ludicrous. But stick with me.

You have to remember that salespeople, project managers, and non-technical managers don't speak geek. How can I be so sure? Because the only thing more ludicrous than my analogy is the requests you get as a software developer to "shovel the driveway" without knowing answers to any of the above questions. And you're being asked to do things that are counterproductive by people who don't understand how and why their requests are counterproductive.

And one of the major goals of this blog is to help get you outside of your geek braincase and help you understand how non-developers think and communicate. This is the key to your professional satisfaction, productivity, and career advancement.

How Not to Shovel a Driveway

Here are some typical requests, and how you might reply.

Manager: I know that everything isn't ready, but please start on the project with the information you have.

You: I can certainly start some basic prep work, but it probably won't save any time. It would be better for me to work on another project while we wait for the spec to be defined a bit further. I can work with the project manager on that.

Manager: We need to get started on this project so we don't fall behind, and because Mary (Mary is always evil) will have my head on a stick if we don't start on it this week.

You: Well, I'll do what I can to help move the project along, but I want you to understand that it won't save any time. It is as if you are asking me to start shoveling a driveway while it is still snowing. I can shovel the entire driveway, but since more snow is still falling, the driveway is still going to be covered again. I'll have put in work now, with very little to show for it. And, I'll still need to shovel the whole driveway again later.

Manager: That can't possibly be true. What is the easiest thing for you to implement in module XYZ?

You: Any design you reasonably come up with is going to take the same amount of time to implement. What takes extra time is if the design changes. The best thing for me to do is work with Mary to agree on the spec. There is no benefit to starting on something that is not defined and/or highly likely to change.

Manager: Mary is out this week, please just get started.

You: Okay, now that you understand the situation, I feel much better that we had this conversation and know that I'm on the task you want me to be on.

Free Advice: Don't remind your manager s/he is uninformed. S/he understood the decision is inefficient, at best, but doesn't want to admit it to you and has a different agenda. S/he will use the same analogy to Mary's face later, because you gave her/him a talking point that Mary can understand. Your career will advance much faster if you see yourself as the student when it comes to office politics, and not the teacher. If you don't take my free advice, take your manager's free advice. Programmers are used to highlighting the important points to each other, such as, "You need to use this compiler flag or it will fail." Non-developers just speak English and expect you to read between the lines, which you're probably not very good at.

Always, be sure to check yourself. Are you just being combative or lazy?

Is it true that your snowy driveway analogy holds?

If the snow is already deep, then maybe you could take a pass now and get ahead on some of the work. If you wait, maybe the snow would be so deep you have to shovel twice anyway. Or, you can take this time to do research, so you can ask intelligent questions later.

Don't take the snow analogy too far. You can affect the weather! Instead of complaining about the snow, work towards solutions. Don't use the analogies as an excuse to shut down conversation. Use them as a path towards a shared understanding.

The Nor'Easter

For those who don't know about Nor'Easters, they are swirling snowstorms shaped like the Milky Way.

The relevant characteristic of a Nor'Easter is that they contain heavy bands of intermittent snow, interspersed with lulls in which the storm appears to have passed.

Here is how to use this analogy in business:

Manager: Now that we are done with that major push, we have time to work on this huge backlog of work.

You: Sorry, but I think this project is like a Nor'Easter. I think we are in a temporary lull after a ferocious period, but the storm is still there, and we will be hit by periodic waves of snow every three weeks for the next quarter.

Of course, this analogy fails if the other person doesn't know how a Nor'Easter works, so you may need to explain, or use a different approach.

The sneaky part of the analogy is that you've subtly introduced the concept of a recurring storm, which your manager can understand without any knowledge of software development.

You've taken the focus off the geek-speak, and given them a mental image of something they can grasp onto.

How do you drive that home?

Consider naming each of your projects after some weather-related event, and add a photo (in this case of a Nor'Easter) to the project home page. Once your manager sees the photo, s/he'll understand intuitively.

Tech Debt

Tech Debt is one of the most important concepts in all of software development.

Here is how to explain it in terms of snow:

Tech debt is like when you don't shovel your driveway, but you drive the car over it. That snow seems to be "out of the way," and you don't need to deal with it any more, right?

Wrong! That snow will turn to ice, and someone will undoubtedly slip and fall on it. When/if you decide to deal with it, it is much harder to scrape off the ground because it has been compacted and re-frozen. It is 100X easier to deal with by shoveling before driving the car over the snow.

Now let me give you the software developer's definition of Tech Debt:

"If I don't refactor this module, then the code will be brittle, and we'll have to spend more time in QA, and the software won't be as robust or performant."

Which one do you think your manager is going to relate to?

So try this:

"I can take a shortcut today, but it is going to cost us dearly in the near future. Any perceived benefit is just an illusion. It is like driving over snow in your driveway instead of shoveling the snow first. The part you drive over is going to be hazardous and hard to deal with later. Please authorize me to head off this problem today, and it will pay itself back 10x within a week."

Forecasting and The Weather Report

How many times have you been asked to estimate a project without being given any details?

Manager: We need you to build an advertising site for this new cell phone our client is promoting.

You: Okay, do we have any details?

Manager: No, we just need to know how long it would take to do a micro-site.

You: Well, I can give you a better weather forecast if I know the city, the latitude/longitude, and the season. At this point, I don't even know the planet we're talking about.

Manager: Just assume it is like every other project we do.

You: Okay, I can give you the typical highs and lows. These sorts of projects usually take two weeks to spec and three weeks to develop. But, I don't know if there is going to be a freak snowstorm that dumps ice on the unsuspecting Southeast. When the storm hit Atlanta, a typical 45-minute drive took 7 hours.

Manager: You made your point, but I just want to know what is typical.

You: Okay, thanks. I just feel obligated to meet my promises and my deadlines. As long as you understand this is just a ballpark estimate that will need to be revisited when I have more specifics, I'm happy to do everything I can to help approximate the work. Is there someone I can work with to get more specifics?

Manager: Thanks, I'll let you know.

Conclusion

We've covered a lot of territory here.

Some take-aways

• Look for creative non-technical ways to relate technical concepts.

• Use visual images to relate concepts. Most people think visually.

• You've made your point, now keep your mouth shut. Non-programmers can only keep from strangling each other because their communication is built on a foundation of ambiguity that allows them to constantly save face or leave room for interpretation.

• People in glass igloos shouldn't throw snowballs. Recognize that communication is a two-way street. Stop chalking it up to your manager's failure to understand your brilliance and expertise.

• Make a snowman in the shape of your manager and watch him/her melt . Do not run it over with your car. It will only be harder to clean up later.

Happy Coding! Be sure to check out the other posts on the right-hand side. And like/share this article if you found it useful.