⋮    ⋮    ⋮  

You Don’t Know Jack! How Software Gets Developed Part I


Complexity: What does it mean?

Complexity: What does it mean?

There’s no real agreed definition for what makes something complex, but I read a good example which I liked once so I’ll lift it and use it here. A car key is simple (thinking the basic old style keys) and it’s pretty straightforward to understand in principle how it works. The car itself that it operates is complicated. Could you figure out how the whole thing works? Probably, but it would take a long time and a lot of effort (assuming you’re not already a mechanic!). The traffic that the car drives in is complex. Can you model it and predict some level of how it works? Probably, but would you ever get a 100% prediction hit rate? Unlikely, regardless of how long you studied for.

Software ranges from simple to complex and sometimes even beyond complexity into chaos (although everyone tries to avoid that!). Your typical hello world program that is usually one of the first things aspiring developers learn in the language of their choice is simple. Unfortunately it never really stays that simple and things can get complex very quickly.

Controlling complexity is important. The more complicated something gets, the harder it becomes to change or fix it later, particularly if the person who made the particular piece of code has since forgotten the why and how of something they did or in the worst case has left the company and somebody else needs to unpick what they’ve done with no documentation. Complexity in coding is important, I remember developers getting chewed out for breaching the company guidelines on our chosen code complexity measurement scale. If you’re interested in learning more about code complexity measurement, there’s a lot of subject matter on it, so feel free to google. 🙂

But complexity isn’t purely important in terms of code itself, it’s also important in other areas. Imagine if you’re one person by yourself writing a program. Even if the program itself is something relatively complicated, the process itself is pretty simple. Maybe you write down what you want your software to do, what functions it needs to have, you write your code, you test it, you refine it etc. But most of the knowledge for what you’re doing rests with you and you alone. Maybe even on just your one computer. Very little complexity to manage there. How about if you add another person into the mix? So now two of you coding away on the same thing? Well now you need to communicate with each other and make sure that the way one of you is doing something will work with the way the other person is doing their piece. That makes things more complicated. You have to coordinate with another person or things are unlikely to work. What about if the program isn’t supposed to work in isolation on a computer but needs to work with other computers running the same program? Now you guys need to coordinate the communication between the computers running the program you’re writing, what network protocol will it use? How fast will it need to be? Does the data communicated need to be guaranteed or not? How much bandwidth will you or your client have available? Where will the multiple computers be located and does latency matter? How much data will they need to store? If it’s not too much maybe you can store it in files, if more then maybe you need a database. Oh but hold on, if the program is a success then maybe in version 2 you want to have the ability to use a database even though it’s quicker and cheaper to do it all in files for version 1. Hmm, this is getting pretty complicated for two people, maybe we’d better get some more people working on this. But wait, I live in the middle of nowhere and nobody else besides us around here is good at this stuff, maybe I know a person who would be great to work on this but they live somewhere else, so now I need to coordinate with someone who is somewhere else. How will they have access to the source code on our computer here? How will we secure it? How will we make sure the three of us are writing code that will work with the other two people’s code?


And this is just with 3 people! Now, imagine scaling this up to hundreds, thousands, more! Complexity is everywhere. Luckily, there are a lot of tools to help us manage complexity. We have code repositories, leased lines, automated testing software, network protocols, firewalls and routers, multicast and IP addresses and ports, telephones, teamspeak and skype, spell checkers, code complexity checkers. The list goes on and on. Millions of things to help us deal with complexity. These days though, there are so many tools to help us deal with complexity, that the abundance of tools have in themselves become complex. That’s why we need IT technicians, database administrators, network and system administrators, devops, telephone engineers, I’ve lost count of how many different Microsoft, Cisco, Sun, Red Hat etc certifications there are. Specialists who deal with complexity in a given subject area.

So, we get it. There’s a lot of complexity and we need to manage it. And to a certain extent, that’s what coding is about. It’s about trying to make something complex which can be easily interacted with by people.

There’s a good saying from a game I love which is slightly relevant at this juncture: “All scientific advancement due to intelligence overcoming, compensating for limitations. Can’t carry a load, so invent wheel. Can’t catch food, so invent spear”. Humanity has the intelligence to create tools which have helped us evolve faster than genetic evolution which other species rely on and which we relied on historically. This is all the same thing, we’ve just moved on from needing to invent wheels to needing to invent methods of transferring data from one location to another via microwave for speed to make more of a thing we invented called money, which allows us to get more things which resolve complexity or give us enjoyment etc. Interested to see how many people can name the game without searching, let me know in the comments! No prizes, only kudos.

Stay tuned for Part II next week where we’ll examine complexity and its relevance to crowdfunded software development!