Who Doesn't Want to Improve?

"If it ain't broke, don't fix it."

Classic wisdom, right? What about: "If it is broken, ignore it until it becomes a fire." It's not really advice, is it? In fact, reading it that way probably sounds horrible. So, why do so many companies consistently adhere to it?

It's too friggin' expensive

A company I worked for was having a major technical issue with branching and merging repositories. The programmers hadn't discussed it openly. We just all knew it was borked. Being the kaizen minded individual that I am, I suggested an alternate solution to the problem, one that would support how we were trying to use our repositories instead of changing how we use them.

The feedback was, "Wow, this looks like it would definitely do the trick!" and "There's no way we can do this." I probed and the immediate response was, "We'd have to train everyone in how to use the new system, and that would just be too time consuming and expensive."

There wasn't a formal weighing of the time saved by easier merges, by being able to perform local check ins, by having the power to share patches easily, etc. Instead, the executive decision? Less branches. A lot less branches. One branch.

I wish I had numbers for how much time was lost due to broken check ins, lafrge conflict resolutions, and a severely destabilized code base.

There was a focus on the features we had to build and the time left to build them, not the tools we were using to build them. In many senses, our repository technology and the way we applied them weren't right fit.

An open culture

An open culture might have explored alternate solutions. A culture reliant on evolution for its survival would have embraced a new idea.

This is one of the fundamental reasons why the Chaos Report shows that small companies have a higher success rate of developing software on time, on budget, and to specification.

With less overhead, closer communication links, and highly motivated individuals, decisions can be made closer to the metal as they affect workers.

I was told, "You can't change too much when a project is in development. Don't worry, wait for the next title, then you can have all the ideas you want for improvement."

Wow. There's so much wrong with that. Delayed change is less likely to occur, it's less likely to fulfill the needs of the moment, and, generally, is a bad idea. Correction as errors occurs prevents smoke from becoming a fire.

Putting out fires takes away from the focus of the project.

Why improve?

Peopleware and the Mythical Man Month have numbers showing just how expensive a bug becomes in code if it's not found early and corrected. Why don't we also explore numbers for errors in the process and systems we use to govern our development?

From the outset, the goals of a healthy project are to:

Achieving these goals isn't often easy. There are obstacles that constantly fall in a team's way.

There's so much I want to say here. You don't believe in continuous improvement? But, you believe in scrum (let's face it, everyone says they're using scrum)?

Well, scrum has sprint retrospectives. If you're doing them correctly, you should be constantly identifying what's wrong not just with the software, but with the process you've been using to develop. Then, you're expected to act upon your findings (generating action items) and incorporate changes into your next sprint.

This is kaizen! You're practicing improvement?

But, you're focusing on a feature set.

Systems engineering and systems thinking now should bring it up a level. Take a step back. Look at your teams. Look at how they interact. Look at the company. Look at the companies you interact with. There has to be more to improve!

Continual iteration in software helps us understand the goals of the software, the problems, and the solutions. Continual iteration on a company level helps our company better understand the role it serves its clients, its position in the market, and how it can serve its employees.

5 Why's

I like pointing out the 5 why's. We can't blame people. I mean, we can; but, that's not necessarily solving the problem. We need to fully understand the problem before we can truly solve the root.

This is similar to programming. We can hack a fix in, which is useful as a stopgap; but, what about when E3 is over? Using a hack leads to more hacks and, eventually, bugs and failure. Finding out that a negative length is being mathematically applied because a calculation is wrong allows us to fix that calculation, removing the bug from existence, preventing it from affecting other systems, and giving us a full understanding of the issues at hand.

The 5 why's is just a system for achieving that.

A question to you

Where have you seen continuous improvement in your game development career? Has it helped? Where have you seen a lack of it? What has your experience been?

Okay, I think I've bombarded you enough for one day. I highly suggest following LeanBlog.org. Mark is going to be talking about kaizen in more detail and gemba. We, as game developers, have a duty to learn from every industry we can.

About the Author

Andrew Andreas Grapsas is a game programmer at Arkadium, Inc. developing facebook games. Previously, he was a gameplay and animations programmer at Kaos Studios|THQ, and intern systems programmer on Medal of Honor.

Andrew is actively writing and programming for various projects. You can read more at his blog aagrapsas.com. He promises to update it soon.

Follow Andrew on twitter!