Make It Run, Make It Right II

Complexity Management

I was mobbing with a team at Gusto yesterday, tidying some code in preparation for introducing a feature flag. Or were we introducing a feature flag and then tidying? Our progress ground to a halt.

Mixing the two is a common I’m not sure I can call it a mistake exactly but yeah it doesn’t work so well. Here’s the problem.

My pea-sized brain can’t deal with much complexity at once. This put at a disadvantage compared to my college classmates who could write whole programs in their heads. I had to tape together techniques allowing me to awkwardly deal with one bit of complexity at a time.

Over time, complexity partitioning started giving me advantages. As the programs we wrote became more complex, I could still handle one bit of complexity at a time while they struggled to:

“Make it run, make it right, make it fast” as my Pappy taught me is one of those complexity partitioning strategies. We had a new test we wanted to pass. Getting it to pass would require us to pass a new parameter several levels down. Make it run, make it right says boo hoo, get the test passing and only then worry about beauty and symmetry.

Make it run? That’s easy. Once it’s running make it right? That’s easy. Easy is the zero of programming. 2 easies is still an easy. Somehow we think our job as programmers should be hard. Sometimes it is, but mostly not. Hard problems, confusion, uncertainty are signs we may benefit from a new approach.

Keep an index card by your keyboard today. Make a mark every time you don’t know what to do next or you don’t know whether the tests will pass or you think of a new test that will likely fail. Create a game—5 marks and you get a coffee, 25 marks and you take a nap. Play with the thresholds and the activities. Let me know how it goes.