Confession time. I’m addicted to SimCity BuildIt.

Ok, with that out of the way I want to talk about how this game is making me more conscious of lean software development principles. The gameplay is pretty simple – you construct roads and buildings, then produce raw materials and manufacture goods to complete missions and upgrade buildings.

[ad name=”Leaderboard”]

Simple. But there are some challenges. One challenge is that the time it takes to produce of materials and goods varies by the type. This complicates my life because I don’t know what I’ll need in order to complete a mission ahead of time. So, if a mission comes up which requires 5 watches, for example, I’m in trouble. A watch is built from a chemical, a glass, and a couple plastic materials. Chemicals take 2 hours to make, glass takes 5 hours, plastic takes 15 minutes. The watch itself takes a couple hours and I can only produce 1 watch at a time.

If I go full-blown lean, I’ll do this just-in-time and the first watch will take about 7 hours to build, then each additional one will take 6 hours (I can produce up to 45 materials in parallel, so the material production time is equal to the longest part, in this case the glass).

Here’s the problem. If the mission only lasts 3 hours I won’t be able to complete it. What’s a mayor to do?

I have the ability to carry a limited set of inventory, so I could pre-produce some of these more ‘expensive’ items and hang on to them for when they’re needed. The drawback is that this takes up shelf space and I have no idea when or how many items I’ll need. If I fully stock the shelves but end up needing another item, I’ll have to get rid of some of my fully produced items.

I can purchase fully produced items from other cities. I don’t have to carry the inventory, but I pay a premium in this case and there may not be any available when I need it.


Ok, I hear ya. So what does any of this have to do with software development?

One of my all time favorite software development books is Lean Software Development by Mary and Tom Poppendieck.

I learned that overproduction or producing things that nobody needs is waste. We should be building the smallest increment of an application, measuring the value it returns, and iterating on that. Spending a month adding a feature that nobody uses is a month of lost time that could have been used to produce something of value.

Along the same lines, producing something and letting it sit on a shelf provides no value. Small batch sizes can help with this. Often, we believe that we can’t release a software product until it’s “done”. So we build all the features we can think of, then push them all out at once. While we’re holding all of those completed features in inventory, we’re not realizing any value from them.

Another obvious, but seldom recognized, truth of software development is the effect of the theory of constraints. When building an application we’re only as fast as the slowest part of the process. If I need to produce cheese in SimCity, for example, it’s only a couple of hours – but to produce the raw materials is 5 hours. So what is a 2 hour process on it’s own is actually 7 hours end-to-end.

The theory of constraints shifts our focus to optimizing the slowest part of a system. Instead of compartmentalizing the development process into analysis, design, development, testing, release, etc, see the process as one piece. It doesn’t matter if we can test 20 things per week if we can only develop 4. Optimize the whole.

[ad name=”Footer”]

We have a lot of tools to visualize and optimize our processes. Value Stream Maps can show us where our time is actually spent from start to finish. Cumulative Flow Diagrams can visualize bottlenecks in our workflow. There’s nothing I can do to speed up the production of electrical components, but we have complete control over everything we do when building a software project. The hardest part can be identifying where to focus.

Well, my appliances are done being made. Time to go upgrade a building in my city!