We’ve all seen a project in chaos. In every choas, there are people who have no idea what’s going on, others are frustrated and others are just trying to keep the building from burning down. No one ever wants to be part of a chaotic situation, you can’t get things done, no one knows which way is up, and it’s simply not a fun time. Software projects aren’t immune from these problems. In fact choatic situations probably happen more often in software than in other domains because the software building process often isn’t well understood.
In my opinion, software has a lot to do with organizing someone’s thoughts into a sensible set of instructions on how to do something.
- Place bread in toaster,
- press down the plunger,
- wait till the toast pops up,
- add butter…
As we build the process, we might realize some shortcuts and take them. We realize that while we’re waiting for the toast, we can also take the peanut butter out of the cupboard. Great, we’re making things more efficient! So we do some more, while waiting for the bread to toast, we can
- get out a plate,
- and a knife,
- and pour some orange juice,
- and make coffee…
Oh, but that’s too many things, the toast will be cold by the time that’s all done. The priority was the toast, so let’s check back for the toast every 5 seconds to see if it’s done.
- Place bread in toaster,
- press down the plunger,
- get out a plate,
- check if the toast is done
- and a knife,
- check if the toast is done
- oops, didn’t finish getting the knife, get the knife
- and pour half an orange juice,
- check if the toast is done
- and pour some more orange juice,
- check if the toast is done
- and pour some more orange juice,
- toast is done!
- oh, but what about making the coffee?
- add butter…
You can see how our process can slowly get out of control, even with changes that all seem like good ideas. There are a number of ways we can combat this.
Standardized solutions
Standard solutions save everyone time and problems. Solve the problem once and generalize it so that knowledge can be re-used in future applications.
When someone says, make me a ham sandwich, we pull out our “make a sandwich” formula and tweak it to work for ham sandwiches. We’ve already spent a lot of time tweaking our “make a sandwich” formula in our last couple projects so we know it will be a good and reliable way to make sandwiches of any type.
Isolation
Make parts of your process as independent as possible. Independence prevents two unrelated things from causing the other to fail. Think of a two car garage. Pretend both you and your wife have a vehicle and you both go to work at a different times. You would never choose to have a two car garage where the cars park one in front of the other. Of course you would choose the side-by-side approach. You don’t want to be dependant on the other when getting out of the garage.
Keep it simple
Make the parts of your process as simple as possible. Don’t have an “insert magic here” process that does all sorts of wizardry. Invariably, everyone working in the system will avoid that process like the plague. One day, someone will have to learn what that process is doing, and will likely break it despite their best intentions. This is simply a liability.
Keeping it simple has a nice side benefit. People will have a much easier time on-boarding, and won’t make mistakes as often. After all, if it’s simple, you don’t have to be a genius to work with it.
Conclusion
There are definitely more principles than the ones I’ve written here, but I think these are some good ones to start.
Working with standardized building blocks that are simple and isolated, the solution becomes an amazingly rewarding process. It’s simply plugging together the legos that make up the system. They’ll be more robust, they’ll be easier to understand and easier to maintain. Those are all terrific qualities to have in a system and they’ve served me well as I’ve used them.
Thanks for reading! I’ve love to hear what you think. Shoot me an email to nate@blue-giraffe.ca
