I'm not a big fan of fast food restaurants. Their food isn't always healthy. The menus are necessarily constrained so that it's easy to get bored with the food they offer. While I'm not a connoisseur of great foods, I know that gourmet and fast food don't often get used in the same conversation. Most attempts to make fast food gourmet have failed miserably.
However, I end up eating from a fast food restaurant a few times a week. Why is that? Well, because it fits well with my schedule, it's convenient, and strictly speaking it solves the primary problem: It is food, and after eating it, I'm not hungry.
Software development has similarities eating at a fast food restaurant. Everyone agrees that there are better ways to develop software and healthier ways to eat. But in the end, we settle for what is convenient and what works within our constraints, be they time, money, or something else.
If you explore the similarities between the eating at fast food restaurants and developing software, you'll find you can learn a lot from those similarities.
Consistency, not quality
Why are fast food chains popular? Is it the high-quality food that they offer? Is it the clean, friendly environments? In most cases, these aren't the reasons why we go to fast-food restaurants. The attempt by McDonald's to bring higher quality foods to their restaurants over the past years has not been successful. Romaine lettuce on a sandwich and a higher quality bun wasn't what we had come to expect from McDonalds. It wasn't what we were looking for at McDonalds either.
When I travel, I have an array of options for where to eat. With an expense account, it is easy to decide to eat at more expensive restaurants. But frequently, I end up eating at a fast food restaurant. Why is that?
The answer is simple -- consistency. I know what I will get at a Burger King in Las Vegas. It will be the same things that I get at the Burger King in Indianapolis. I'm willing to give up the possibility of some higher quality foods in favor of knowing I'll get a consistent experience.
When I go to a fast food restaurant, I'm not looking for the best food or the lowest price, I'm looking for something that is quick that I can predict so that I can get on with my day. This is the fundamental thinking of fast food — fast and consistent.
Consistency can also be desired and applied to software development. If you look at high ceremony processes, whether waterfall or iterative, the objective of the ceremony, whether effective or not, is to improve the consistency in the results.
Fast food restaurants accomplish their consistency by creating a formula for their products. That formula is expressed as the ingredients that are used, the assembly line created to put those ingredients together, and the training given to the individuals who work the assembly line. Additionally, training posters and reminders plastered all over the back rooms of the restaurants help to guide the process.
Software development doesn't crank out the same result over and over like a fast food restaurant, but it can create different products by utilizing one consistent process to create those products. It can have its own formulas and assembly lines to put the ingredients of a project together.
In software development, the process is utilized, most visibly in the form of the documents or other artifacts that the process produces. This creates a consistency of results similar to what can be seen in a fast food restaurant. We accept that we have lower efficiency due to the need to create the artifacts. We accept it in order to get consistency--just like a fast food restaurant trades gourmet ingredients for consistency.
Painfully, there are differences between the way that software is developed and the mechanical assembly of fast food. The same approaches that lead to consistency in fast food are only marginally effective in software development. They only work if the artifacts that are created are actually used to ensure the project is on track. If they become shelfware, then in spite of the fact that the artifacts have been created, the results they encourage produce little consistency.
Another factor that substantially influences our decision to go to fast-food restaurants is that it's convenient. In other words, it's easy. It's something that doesn't require a lot of work. Most fast food restaurants don't even make you walk twenty feet. You can remain with your butt in seat, and drive your car around to get your food. We're turning into car potatoes just as much as we are couch potatoes.
Much of software development is based on ease. It's easy to use the same coding standards as the last project, the same process and methodology, and the same artifacts. By using items from prior projects, you can use little thought or concern in the current project.
By contrast to fast food, which is the same thing over and over, a gourmet chef can improve his recipes with time. Similarly, a company can improve its development process. Like improvements to an already superb dish, a continuous improvement on the standards, processes, methodologies, and artifacts is difficult. It requires continuous attention and thought about how to do things better, what's working and not working, and so on.
It is no wonder then, why we don't improve our software development process. If we can't stop going to fast food restaurants that are quite literally killing us (if we trust the dieticians), then how can we ever hope to improve the way we look at software development. The answer is simple but just like a diet, requires some discipline.
Getting healthy in software development
Software development is ill. We know that we continue to struggle with schedule and budget overruns, poor quality, and other maladies that hurt us and the industry. If you want to get healthy in your software development, then here are some steps for you.
- Make a commitment to eat better — Just as you have to recognize the impact that consistently eating fast food has son your health, recognize that the way you're doing software development today isn't the best way to do it. Realize that you need to learn new ideas, try new things, and think about the process before you have any hope for getting better.
- Make small changes in your eating habits — You don't give up a life long love affair with fast food over night. Similarly, you can't give up your current software development methodology in one fell swoop. Rather than redefine your process from waterfall to Agile, make a small change. Instead of having a 100-page requirements document, move to two 20-page documents. Find ways to make a small change in the amount of documentation you're doing. If you can capture certain requirements in one page of diagram rather than three pages of text, do it.
- Evaluate what you're eating — Just because you're eating at a fast food restaurant doesn't mean you have to eat unhealthy food. Similarly, if you're doing things in your software process, make sure that you're doing them for the right reasons. If you produce a detailed PERT chart at the beginning of the project and never update it from there, ask yourself if you really need it, or if instead it would be better to come up with a rough schedule order and adapt as necessary.
- Listen to your body — A body knows when it's been fed unhealthy things and it begins to make you aware through small ways, like that extra few pounds you've added. Software developers, business analysts, architects, and project managers embody the process. They are inherently aware of some of the challenges that the process is facing. Ask people what is wrong with the process and can be improved.
What it all means
If you choose to eat super-sized value meals, then you can't blame fast food for your weight gain. It was your choice. In software development, your choices can also impact the results of your projects — and not always in a good way. For the good of your project, it is sometimes better to slow down and make a healthy selection.