# The Right Little Thing: Manage Complexity

Code Complete 2 is a book that I think every programmer should read. And, atypically for this industry, I doubt very many people will disagree with me.

There’s one particular quote, from chapter 5 (page 78 in my edition) that I think is worth buying the book just to have:

Managing complexity is the most important technical topic in software development. In my view, it’s so important that Software’s Primary Technical Imperative has to be managing complexity.

Let’s start with a trivial example: comparing numbers. I recently read an interesting question on StackOverflow about why certain number comparisons in Python are slower than others. The accepted answer contains a link to the Python interpreter’s source code.

The Python interpreter is written in C. Take a look at that code for a second. Notice that you have to scroll down several times to get through a method whose only job is determining which of two numbers is larger. Yikes. (By the way, if you want to improve your understanding of floating point versus integer representation of numbers in a computer, go read through that code for a few minutes.)

The code has all kinds of different cases. The first is very easy to understand: Two numbers were passed in, and their signs don’t match. (One is positive and the other is negative.) Negative numbers are always smaller than positive numbers, so we’re done. Hurray! Of course, if someone, for example, wants to compare two numbers that have the same sign, we’ll have to use the rest of that code.

Now, we’re going to take a look at code, written in Python, that compares two numbers:

`bigger = a > b`

There we go. If a is greater than b, “bigger” will be true. We’re done. Why was that so easy?

It was so easy because the engineers who built the Python interpreter did a really good job of hiding complexity. It turns out, comparing numbers, where either number could be an integer (and of variable bit length) and either number could be a floating point number, is hard and has lots of edge cases. But those engineers hid that complexity from us; our code just works.

So what are the characteristics of this masterful code by the makers of Python? It does one job, and the people who employ it don’t need to know (or care) how that one job is done.

So the next time you write a method, especially if you’re writing a method that someone else is going to call, see how much complexity you can hide from them.

Think of your method as a pizza place. To sell a pizza, you need to know what kind of pizza, where it’s being delivered, and you need to get paid. There you go. Someone calls you, tells you an address, some toppings, and gives you some money, and then, as far as they care pizza just appears. If the people who call your pizza restaurant are telling you how many employees should be working that shift, or what temperature your oven needs to be at, you’re doing it wrong. Hide that complexity from your customers – they don’t know or care.

Till next week, happy learning.

-Will