development-process

22 Useful Software Development Analogies (Meme Version)

Use these handy memes to explain to your friends and coworkers just what it is you do all day. Here's the text-only version of this post.

Writing Code

Writing code is like putting windshield wipers on your car, except that if you fail to install them in the right order the engine falls out.

Writing code is like working in a robot factory, only sometimes the entire line stops because one robot has to tell you about the size, shape, and color of an out-place bolt, all while holding a severed finger. Image is modified from KUKA Industrial Robots IR.jpg, and used under license.

Refactoring code is like sweeping the floor: only when all the debris is gone can you be sure you did a good job Image is modified from Hair pile dust pan broom hair salon, used under license

Getting your code reviewed is like getting a root canal: it sucks while it's happening, but after taking some time and some pain medication you'll be glad you did it. Image is modified from HI I'M GETTING A ROOT CANAL (which is clearly the best name ever) and is used under license.

Debugging

Debugging code is like getting lost in the desert: you'll see the fix right in front of you, but 99% of the time it's only a mirage. Image is modified from Desert mirage, used under license.

Debugging your own code is like having a mental illness.  You spend a lot of time talking to yourself about a problem that only exists in your head, and nobody believes you when you tell them about it.

Debugging someone else's code is like trying to solve a puzzle: eventually you're be trying to fit the last piece in place but can't until you realize that you've been holding it upside down the entire time. Image is modified from Puzzle black white missing, used under license.

Paying down technical debt is like flossing: it's easy to ignore, but if you don't do it you will eventually have to seek a professional's help. Image is modified from Oral hygiene, used under license.

Testing

Writing tests is like having sex: the more you do it, the better you get at it and the better it feels.

Testing your own code is like eating healthy: you know you *should* do it, but it's very easy to keep putting it off until it's painful to start and you have to get a trainer to help you. Image is modified from Colorfull, used under license.

Testing someone else's code is like trying to flatten a car with a sledgehammer: you smash the obvious weak points first, and then hit it repeatedly until something breaks.  More experience will tell you where other, less obvious weak points probably are, and you can smash the car faster each time.

Tech Support

Getting asked to fix someone else's computer is like being an elite race car driver who gets asked to fix his car's transmission simply because Image is modified from BuschSeriesFieldAtTexasApril2007 and used under license, conforming to that license's terms.

Actually FIXING someone else's computer is like being a magician: no matter how simple the trick is, the other person will be amazed, simply because you know something they don't. Image is modified from Zan Zig performing with rabbit and roses, magician poster, 1899-2, and used under license

Planning

Attending a planning meeting is like trying to play a team sport where nobody agrees on what the rules are.

Starting a new project is like being an artist; your client tells you Image is modified from Josh Rosenthal artist actor, used under license and conforming to that license's terms.

Designing a software application is like designing a boat: you spend countless hours locating the ideal materials and testing the engine to the customer's exact specifications, only when you're done the customer tells you,

Personalities

Working solo on a non-technical team is like baking a cake: you mix all the ingredients together, throw it in the oven and hope it comes out right.  If it doesn't, you can use sugar to cover up the bad parts; it's not like anyone will know the difference anyway. Image has been modified from 1-2-3-4 cake and used under license

Being a cowboy developer is like being a house cat: you're fast and unpredictable and nobody knows what you're up to until they hear the racket you've caused. Image modified from Large Siamese cat tosses a mouse, used under license and conforming to that license's terms.

Being a blogger is like being a street preacher: you're constantly shouting to the rooftops about your ideas and thoughts, but the only people who listen either loathe you, adore you, or stumbled across you by accident.

Work Environment

Working for startups is like being a baby sea turtle: 99% of the time something will eat you before you reach maturity. Image modified from a source found on Flickr and used under license.

Working for big corporations is like being a professional cyclist in an uphill race: it takes a lot of effort to get anything done, the road is terribly maintained, you weren't given adequate supplies, and when you've finally reached the top your sponsors (having already flown there in a helicopter) wonder aloud what took you so long?

Working for yourself is like going fishing but forgetting to bring food: you get to do everything at your own pace and in your own time, but you'd better land a big one or you'll be starving tonight.

Did I miss any analogies that you've found useful, or did you find a better image for one of the analogies above? Let me know! Share in the comments!

Happy Coding!

22 Useful Software Development Analogies

Use these analogies to explain to your friends and coworkers just what it is you do all day. Also check out the meme version of this post.

Writing Code

Writing code is like putting windshield wipers on your car, only if you fail to install them in just the right order the engine falls out.

Writing code is like working in a robot factory, only sometimes the entire line stops because one robot has to tell you about the size, shape, and color of an out-place bolt, all while holding a severed finger.

Refactoring code is like sweeping the floor: only when all the debris is gone can you be sure you did a good job.

Getting your code reviewed is like getting a root canal: it's painful while its happening, but after taking some time and pain medication you'll feel much better and be glad you did it.

Debugging

Debugging is like being lost in the desert: much of the time you'll see a fix in front of you, but nine times out of ten it's only a mirage.

Debugging your own code is like having a mental illness. You spend a lot of time talking to yourself about a problem that only exists in your head, and nobody believes you when you tell them about it.

Debugging someone else's code is like trying to solve a puzzle: eventually you're be trying to fit the last piece in place but can't until you realize that you've been holding it upside down the entire time.

Paying down technical debt is like flossing: it's easy to ignore, but if you don't do it you will eventually have to seek a professional's help.

Testing

Writing tests is like sex: the more you do it, the better you get at it and the better it feels.

Testing your own code is like eating healthy: you know you should do it, but it's very easy to keep putting it off until it's painful to start and you have to get a trainer to help you.

Testing someone else's code is like trying to flatten a car with a sledgehammer: you smash the obvious weak points first, and then hit it repeatedly until something breaks. More experience will tell you where other, less obvious weak points probably are, and you can smash the car faster each time.

Tech Support

Getting asked to fix someone else's computer is like being an elite race car driver who gets asked to fix his car's transmission simply because "hey, you know cars, right?".

Actually fixing someone else's computer is like being a magician: no matter how simple the trick is, the other person will be amazed, simply because you know something they don't.

Planning

Attending a planning meeting is like trying to play a team sport where nobody agrees on what the rules are.

Starting a new project is like being an artist; your client tells you "I don't know what I want, I'll know it when I see it, but it has to be done in five days and for less than $100." And then when you, against all odds, manage to do this, she'll tell you "Eh, it's not really what I was looking for..."

Designing a software application is like designing a boat: you spend countless hours locating the ideal materials and testing the engine to the customer's exact specifications, only when you're done the customer tells you, "Great job, we love it, just one little thing: we need it to fly."

Personalities

Working solo on a non-technical team is like baking a cake: you mix all the ingredients together, throw it in the oven and hope it comes out right. If it doesn't, you can use sugar to cover up the bad parts; it's not like anyone will know the difference anyway.

Being a cowboy developer is like being a house cat: you're fast and unpredictable and nobody knows what you're up to until they hear the racket you've caused.

Being a blogger is like being a street preacher: you're constantly shouting to the rooftops about your ideas and thoughts, but the only people who listen either loathe you, adore you, or stumbled across you by accident.

Employers

Working for startups is like being a newborn sea turtle: 99% of the time something will eat you before you reach maturity.

Working for big corporations is like being a professional cyclist in an uphill race: it takes a lot of effort to get anything done, the road is terribly maintained, you weren't given adequate supplies, and when you've finally reached the top your sponsors (having already flown there in a helicopter) wonder aloud "what took you so long?"

Working for yourself is like going fishing: you get to do everything at your own pace and in your own time, but you'd better land a big one or you'll be starving tonight.

Did I miss any analogies that you've found useful, funny, or both? Share in the comments!

Happy Coding!

15 Fundamental Laws of Software Development

(AKA How To Sound Smart At Your Next Team Meeting)

Occam's Razor

This widely-known adage dates to a philosopher and friar from the fourteenth century named William of Ockham. Occam's Razor is often stated as:

"Among competing hypotheses, the one with the fewest assumptions should be selected."

It's no surprise that the whole reason we can recall an adage from 600+ years ago is that it works so well. Occam's Razor is so basic, so fundamental, that it should be the first thing we think of when deciding between two competing theories. I'd even go so far as to argue that in the vast majority of cases, simpler is better.

Hanlon's Razor

Sometimes I feel like users are intentionally trying to piss me off. They push buttons they weren't supposed to, found flaws that shouldn't have been visible to them (since they weren't to me), and generally make big swaths of my life more difficult than it would otherwise be.

I try to remember, though, that the vast majority of actions done by people which may seem malicious are not intentionally so. Rather, it's because they don't know any better. This is the crux of an adage known as Hanlon's Razor, which states:

"Never attribute to malice what can be adequately explained by stupidity."

Don't assume people are malicious; assume they are ignorant, and then help them overcome that ignorance. Most people want to learn, not be mean for the fun of it.

The Pareto Principle

The last Basic Law of Software Development is the Pareto Principle. Romanian-American engineer Joseph M Juran formulated this adage, which he named after an idea proposed by Italian economist and thinker Vilfredo Pareto. The Pareto Principle is usually worded as:

"80% of the effects stem from 20% of the causes."

Have you even been in a situation where your app currently has hundreds of errors, but when you track down one of the problems, a disproportionate amount of said errors just up and vanish? If you have (and you probably have), then you've experienced the Pareto Principle in action. Many of the problems we see, whether coding, dealing with customers, or just living our lives, share a small set of common root issues that, if solved or alleviated, can cause most or all of the problems we see to disappear.

In short, the fastest way to solve many problems at once is the find and fix their common root cause.

Dunning-Kruger Effect

Researchers David Dunning and Justin Kruger, conducting an experiment in 1999, observed a phenomenon that's come to be known as the Dunning-Kruger effect:

"Unskilled persons tend to mistakenly assess their own abilities as being much more competent than they actually are."

What follows from this is a bias in which people who aren't very good at their job think they are good at it, but aren't skilled enough to recognize that they aren't. Of all the laws in this list, the Dunning-Kruger effect may be the most powerful, if for no other reason than it has been actively investigated in a formal setting by a real-life research team.

Linus's Law

Author and developer Eric S. Raymond developed this law, which he named after Linus Torvalds. Linus's Law states:

"Given enough eyeballs, all bugs are shallow."

In other words, if you can't find the problem, get someone else to help. This is why concepts like pair programming work well in certain contexts; after all, more often than not, the bug is in your code.

Robustness Principle (AKA Postel's Law)

One of the fundamental ideas in software development, particularly fields such as API design, can be concisely expressed by the Robustness Principle:

"Be conservative in what you do, be liberal in what you accept from others."

This principle is also called Postel's Law for Jon Postel, the Internet pioneer who originally wrote it down as part of RFC 760. It's worth remembering, if for no other reason than an gentle reminder that often the best code is no code at all.

Eagleson's Law

Ever been away from a project for a long time, then returned to it and wondered "what idiot wrote this crap?" only to find out that the idiot was you?

Eagleson's Law describes this situation quite accurately:

"Any code of your own that you haven't looked at for six or more months might as well have been written by someone else."

Remember that the next time you're rejoining a project you've been away from for months. The code is no longer your code; it is someone else's that you've now been tasked with improving.

Peter Principle

One of the fundamental laws that can apply to managers (of any field, not just software) is the Peter Principle, formulated by Canadian educator Laurence J Peter:

"The selection of a candidate for a position is based on the candidate's performance in their current role, rather than on abilities relevant to the intended role."

The Peter Principle is often sarcastically reduced to "Managers rise to their level of incompetence." The idea of this principle looks like this:

A chart showing the advancement of a candidate to higher and higher levels of management, until reaching a point at which s/he is no longer qualified to obtain via skill.

The problem revealed by the Peter Principle is that workers tend to get evaluated on how well they are currently doing, and their superiors assume that those workers would also be good at a different role, even though their current role and their intended role may not be the same or even similar. Eventually, such promotions place unqualified candidates in high positions of power, and in particularly bad cases you can end up with pointy-haired bosses at every step of an organization's hierarchy.

Dilbert Principle

Speaking of pointy-haired bosses, cartoonist Scott Adams (who publishes the comic strip Dilbert) proposed an negative variation of the Peter Principle which he named the Dilbert Principle. The Peter Principle assumes that the promoted workers are in fact competent at their current position; this is why they got promoted in the first place. By contrast, the Dilbert Principle assumes that the least competent people get promoted the fastest. The Dilbert Principle is usually stated like this:

"Incompetent workers will be promoted above competent workers to managerial positions, thus removing them from the actual work and minimizing the damage they can do."

This can be phrased another way: "Companies are hesitant to fire people but also want to not let them hurt their business, so companies promote incompetent workers into the place where they can do the least harm: management."

Hofstadter's Law

Ever noticed that doing something always takes longer than you think? So did Douglas Hofstadter, who wrote a seminal book on cognitive science and self-reference called Godel, Escher, Bach: An Eternal Golden Braid. In that book, he proposed Hofstadter's Law:

"It always takes longer than you expect, even when you take into account Hofstadter's Law."

Always is the key word: nothing ever goes as planned, so you're better off putting extra time in your estimates to cover some thing that will go wrong, because it unfailingly does.

The 90-90 Rule

Because something always goes wrong, and because people are notoriously bad at estimating their own skill level, Tom Cargill, an engineer at Bell Labs in the 1980's, proposed something that eventually came to be called the 90-90 rule:

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."

Perhaps this explains why so many software projects end up over budget and short on features.

Parkinson's Law

What is possibly the most astute observation that can be applied to the art of estimation comes from British naval historian C. N. Parkinson. He jokingly proposed an adage called Parkinson's Law, which was originally understood to be:

"Work expands so as to fill the time available for its completion."

Remember this next time you pad your estimates.

Sayre's Law

Economist and professor Charles Issawi proposed an idea that came to be known as Sayre's Law, named after a fellow professor at Columbia University. Issawi's formulation of this law looks like this:

"In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake."

In short, that the less significant something is, the more passionately people will argue about it.

Parkinson's Law of Triviality (AKA Bikeshedding)

Sayre's Law segues directly into another law that applies to meetings, and here we again encounter the ideas of C.N. Parkinson. Parkinson's Law of Triviality states:

"The time spent on any agenda item will be in inverse proportion to the sum of money involved."

Parkinson imagined a situation in which a committee of people were tasked with designing a nuclear reactor. Said committee then spends a disproportionate amount of time designing the reactor's bikeshed, since any common person will have enough life experience to understand what a bikeshed should look like. Clearly the "core" functions of the reactor are more important, but they are so complex that no average person will understand all of them intimately. Consequently, time (and opinions) are spent on ideas that everyone can comprehend, but which are clearly more trivial.

Law of Argumentative Comprehension

The last law is one I totally made up I use to shorthand both Sayre's Law and Parkinson's Law of Triviality. I call it the Law of Argumentative Comprehension:

"The more people understand something, the more willing they are to argue about it, and the more vigorously they will do so."

Summary

You'll notice that many of the laws above don't directly apply specifically to software, and this is intentional. The fact remains that software is built for people to use and interact with, so many of these laws relate to dealing with people rather than code.

No pithy quote will ever replace the experience you gain every day by writing code, interacting with users, and generally getting better every day. Still, by keeping in mind these 15 laws of software development, you might just make yourself a better developer. Or at least a more knowledgeable one, and really, aren't those the same thing?

Did I miss any laws that you consider fundamental to the process of creating software, or any of the activity that goes on around said process (e.g. estimations, meetings, etc.)? Share in the comments!

Happy Coding!