The Pitfalls of Software Complexity, Part [NaN]

Let’s say you’re writing code to print out three 3D shapes: a cube, a cylinder and a cone. You test it. Each one takes a few minutes to print, all look good. Ship it! A few days later, you get a bug report. Once every so often, a rounded cube comes out.

Well, you know more or less where to look. The problem must be in the cube code, right? You find the issue, fix it, go home. Leave the program printing cubes all night. The next morning look fine and sharp. You build a nice stack of cubes in your cubicle, all is good again.

A week later you get a change request: now objects need to come out in three sizes: small, medium and large. No problem, you implement it. Now you can produce nine different objects. Everything works fine, the customer is happy. Obviously the next thing they want is colors. Oh, and densities. Let’s say you compromise on providing four colors: blue, red, yellow, black. And density can be 1 to 5. Fantastic, now your code can create 3 x 3 x 4 x 5 = 180 different objects. It could be a large yellow cylinder of density 5, or a small black cube of density 2. Lots of things!

A couple of weeks go by. Your manager comes in with a puzzled look on his face, and tells you that some people have been reporting donut shaped objects once in a while. Sometimes they are green. Out of hundreds of thousands of objects printed the vast majority have been fine, but there are at least twenty of these (mostly green but sometimes orange) donuts out there. Of course you cannot reproduce this bug, because it would take you weeks of nonstop printing to encounter one of these cases on average. You have to dive into the code.

You start finding some weird edge cases. Sometimes a cylinder could become a donut, but only if the density happens to be in a certain range. But green? What’s up with that? How do densities change colors?

After two weeks and -14 pots of coffee [uint8_t coffee_pot_counter treated as signed] you think you’ve found the issue but you can’t be 100% sure. You test as much as you can, after one thousand prints no weird objects show up. Of course that doesn’t mean much. By the time you’re reading to ship what you believe is the fix, there is a new feature request: multicolor patterns!

You ragequit. A new guy gets your job. He looks at your code and has no idea what’s going on. He starts rewriting it from scratch.

A new requirement comes in. Now the customer wants different materials. And also a “shape morph feature.” Your ex-manager and your replacement can’t agree on how to implement the feature, or what exactly it should do, so they have a conference call with the client. The client says “well, the math is super simple. Take two shapes, for every cubic pixel in the intersection compute the average of the properties of the two and print that!”

In the meantime, you went off and started your own company. You now print exactly one object: a ball. It’s orange, and it has a unique texture. Customers love it; it’s happy, it’s fun. You sell a million of them. Some people want different colors and sizes, you say no. Some of them buy yours as is anyway, some wait for your former employer’s announcement of a bug-free orange ball any day now.

Do not taunt happy fun software complexity!

Leave a Reply

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