Philosophy of Coding: Planning

In this continuation of my philosophy in coding series, I want to talk about planning and the way we think about planning.

Start with the end in mind

Many of you probably recognize this phrase from the 7 Habits of Highly Effective People. In it, Steven Covey does an exercise where you imagine your own funeral and what you want people to say about you. The question is: How does that line up with what they would actually say? More importantly, what do you need to do differently to achieve the end you want?

I used to do a lot of mountaineering and backcountry skiing. We employed this principle all the time. We called it backwards planning. For example, if we knew that thunderstorms hit the peak at 1 pm, then we would decide we needed to be off the summit by noon. That meant we had to reach treeline by 10 am. To do that we would have to leave the parking lot by 6 am, which meant to leave the house at 4 am, etc.

We can use this same idea when planning software projects. If we collect all our user stories, we notice that often they build upon each other. We really want to do a particular calculation. But to do that we have to collect data. To do that we have to communicate with the instrument. Having clear sight of our end goal can help us in trying to prioritize which stories to work on.

A good plan executed now is better than a perfect plan 10 minutes from now.

I first heard this quote during my brief interaction with Marine Corps PLC in college. The premise is that on a battlefield it is better to do something now, even if it is not perfect rather than take the time to come up with a perfect solution. The reason is that the battlefield is dynamic. It is constantly changing which makes it nearly impossible to come up with a perfect solution. Even if you could, by the time you got around to executing it, the situation would have changed and it would no longer be the perfect plan.

Software development is similarly dynamic. The market is constantly changing and requirements are constantly changing. We constantly have to respond to these changes. The whole Agile movement is based on the word agile as in mobile and quick to change direction. We need to expect change and embrace it. We need to not let that stop us from moving forward.

A corollary to this adage is “No plan survives contact with the enemy.” The enemy is unpredictable and is bound to do something to frustrate your plans. In software development, the customer can be equally unpredictable. One of the principles of agile is constant feedback and reevaluation. We need constant feedback from the customer in order to be able to know which direction to go. These meetings are just as important as the initial planning sessions.

4 Comments on “Philosophy of Coding: Planning

  1. It’s not just the customer that is unpredictable, the system can throw curve balls that you simply weren’t expecting or were prepared for. Your code needs to be flexible enough to cope with those problems as well.

    • Good point. There are a lot of things besides the customer that can throw you curve balls. When I worked for Westinghouse we built nuclear powerplants. Everything was looking great until Fukushima. Things changed overnight. The regulation fallout after that drastically changed all our requirements. No one could have predicted that.

    • Good point. I think anything that makes you think on a longer time horizon is a good thing. I think a lot of problems stem from short term thinking.

Leave a Reply

Your email address will not be published. Required fields are marked *