Quality, Batch Size, and “Crush the Castle”

I was playing "Crush the Castle," today - my first break after a long period of virtually continuous work - and I noticed something. I think there is a lesson that can be applied to life and to software development. Check out the following castle...

If you play it, you will probably conclude that it is indestructible. However, it can be defeated but only if you do things just so. So what's the trick?

First and foremost, you will never defeat this castle unless you are patient. It is going to take time; probably at least two-hundred fifty hits. Of course, for most of you, this makes the destructibility of the castle basically theoretical. Who has the time to fire that many shots?

You have to deliver a large number of direct hits to key parts of the castle. There are no shortcuts (that I could find). The cost of missing is greater than the value of a direct hit so you have to be mostly right.

Why is it so Hard to Beat?

There are many reasons. The ones that make it look so hard to beat are the fact that was built with the forces of the game in mind and the enormous volume of material between where your munitions land and the target.

In fact, these are not the true problems. When you hit the structure with bombs, it is perturbed if ever so slightly. If size and strength were the problem, then time and pressure would be the solution.

Yet, while time and pressure are necessary to solve the problem, they are not sufficient. Precision is also required… but why?

The castle is set up to “heal” every time it changes. If you score a “hit” – a blow to one of the weaker parts of the castle – then the structure change a little in your favor. If you miss – hitting too far away from a weak point – the castle gets a lot stronger.

This is because when you widen a gap, you are pushing up against gravity but, when you miss, you are pushing downward, toward gravity. The forces are literally set up against you.

The more you weaken a weak point, the easier it is to score a hit. A good ten hits in a row are enough to make it easier to score a hit than a miss.

Analogy to Software Development

The structure of this castle is, essentially, a system set up to keep you from completing a job. It has a design which is self-perpetuating. That is: the design is set up to repel attempts to change the design.

The king in the center represents what little value there is in the system. You do want to hit that target but you have to go through a bunch of extra steps to get there.

Does this remind you of anything? To me, it is reminiscent of a legacy system.

Batch Size

Your first reaction might be (as mine was) “Oh shit! There’s a lot of material to clear, I’d better use three bombs.” That won’t work, though. The extra two bombs defocus your shots – they remove precision and make accuracy impossible.

If you watch closely, there will be times when you can see two bombs close together adding a little value each, and then the third one completely undoing what they did. In fact, I’ve found that, two sets of bombs delivered with perfect aim and luck can have everything they’ve accomplished erased by one errant bomb in the third volley.

A steady stream of bombs placed exactly where you need them, on the other hand, will give you a much better chance of clearing a beam and, ultimately, a layer.

There is a lesson in batch size, here. The lack of focus causes rework. Small focused jobs delivering understood value do more than big ones. In this case you even get more value if the smaller batches take just as long as the bigger ones. I believe this to be the case in software development as well.

Quality

Bad quality discourages the introduction of good. Good quality discourages the introduction of bad. It is hard to widen a gap more than a little bit to begin with. The wider the gap gets, though, the less work it becomes to widen it further. The more gaps you create, in general, the easier it is to get to the kind. At some point adding quality – widening gaps – is easier than removing it.

Eventually, you reach “critical mass.” The coupling in the system becomes weak enough that changing the structure is easy. Then it’s just a matter of chipping away at it until you unbalance the pressures enough that the system collapses the way you want it.

On the other hand, if you do too much of the wrong kind of damage, the structure will collapse in another way. The new form of the castle will be chaotic. It will be easy to change it but hard to do so in a controlled way. The only way to win the game from that point will be to hammer on the pile of rubble until you shift it around enough to cause a beam to hit the target hard enough to kill it.

The point here is that you can evolve the structure toward a goal (high beams gone, low beams present, midway support beam disturbed enough to yield). You can also hammer the system until it becomes even harder to change and only luck can get you the value. This is a great analogy for quality.

Move in Small Increments toward Quality and Value

The takeaway, here, should be that when you are coding, you move away from bad code and toward good code. You do it in a disciplined way and you do it even if it is painful. Most importantly, you do it in little steps rather than big ones.

If you see an opportunity to make a big, positive change with a small, focused effort, by all means take it.

…but under no circumstances should you move without knowing where you are headed and for no reason should you commit to a “grand design” with a large investment, rather than committing to a big goal and getting there with incremental investments.