Basically, the blog authors said that the number of bugs in a system grows sublinearly with the size of the system itself. There’s no proof for this but it’s the same conclusion I’ve reached with the experience I’ve accumulated so far. This is my explanation for the phenomenon:
Say you have a small software system – for a viable example, think about a prototype, or a shell script you made to take care of trivial stuff. It is very likely that most, if not all, of its parts are not set in stone: if you ever need to add a new feature or to change the behavior of an existing one you will likely have to modify a high percentage of the existing code.
Now think about a bigger system – it might be the prototype from the previous example that now has grown to a complete product. You need to add a feature to that system. If you’ve done things the right way, it’s very unlikely that you will have to modify big parts of the system: chance is, your software’s internals will have grown some sort of API, internal DSL, call it what you want, so all you need to to is either to extend or integrate with it. Also, with time, the bugs in your system’s core will be likely found and eradicated.
Supposing that if you don’t touch it, it won’t break, the part of your system prone to bugs will be the “surface” (2πx), which grows slower than the total area (πx²).