Software Architecture lessons from Norwegian Soccer History

Everybody who knows anything about Norwegian soccer history knows we’re like the worst soccer players on the planet individually, maybe the only ones worse are the Swedes and the Danish … 😉

Individually, it’s like we are physiologically incapable of playing the game. If you compare the average Norwegian soccer player to a Brazilian soccer player, it feels like you’re watching a Giraffe play tennis as you’re watching the Norwegian guy trying to “samba” his way through the field …

However, 25 years ago, there was this magical soccer trainer. His name was Egil “Drillo” Olsen (Google him). He broke all known soccer theory at the time, such as instead of having his players exercise on parts they were bad at, he had them exercise what they were already the best at. For instance, there was this one guy, who’s sole purpose was to shoot the ball, from one place on the field, to another place on the field. He was very good at shooting accurately and hard, but had no other skills really. Another guy’s job was to simply stay at that spot, pick down the ball from the air (his specialty), and score a goal. All other players were chosen from similar criteria, and none of these were “the best” in soccer in general. Individually, the team was arguably composed out of a bunch of “soccer retards”. However, this team humiliated many famous soccer teams, such as Brazil, Germany, England, “you name it”.

So let’s move this theory into software teams, and see if we can learn something. Let’s imagine we’re going to create a web application. OK, we know we’ll need JavaScript knowledge, so we find the best JavaScript developer in the world. We know we’ll need HTML and CSS, so we find the best CSS guy in the world. We know we’ll need C#, so we find the best C# developer in the world. However, these guys’ individual skills, become a liability to create our application. Simply because our app as a whole, doesn’t care about the brilliance of its C#, JavaScript or CSS code. Since all of these guys also are so darn special, and the most skilled in their area of expertise, they’re often also filled with vanity, and an incapacity to cut corners, in order to make their results *integrate* with the results of the guy sitting next to them. And they’ll often hold hourly long speeches about why they can’t do what they’re told to do, because of a, b or c. In fact, this problem is so common, it’s referred to as “Mythical Man Month”. If you haven’t heard of Mythical Man Month, I’ve included it below. Realise that this “theory” of software development is arguably proven scientifically, several times. It goes like this …

One man can create in on month, what two men can create in two months

Although we have known about Mythical Man Month for almost half a century, I suspect we don’t really know the reasons for it. At the least, we do NOT know how to fix it. However, I suspect Erik “Drillo” Olsen might actually have the solution for us.

The quality of your individual employee’s job is actually completely irrelevant. The only question you should be asking yourself is; “How can I integrate his results with the results of the guy sitting next to him”. This is such a universal truth, I suspect that you could literally handpick a bunch of medium skilled software developers, with the sole aim of asking how you can integrate their combined efforts, and these “mediocre” developers would far outperform a team of the same size, composed of the “best guys on the planet”. Kind of like Norway humiliated Brazil in soccer some 20 years ago …

So let’s move this on to *framework design*, which my previous article was all about. Well, the same laws applies. If you want to create a web app, you’ll need to pick a JavaScript library, so you pick the best. You’ll need to pick a CSS framework, so you pick the best. You’ll need to pick a database, so you pick the best. You’ll need to pick a server side programming language, so you pick the best. Etc, etc, etc …


Because the quality of your individual parts, is completely irrelevant, because you can’t integrate these into a “whole”, because they’re built with different philosophies, architectural design patterns, goals, etc, etc, etc. And the vanity and belief in that every single library is created “perfect”, makes its maintainers incapable of perceiving anything wrong with their tools. From their point if view, it’s already *perfect*!

I suspect this is the root of all failed software projects in fact. At least intuitively it feels like a universal truth. If you instead focus on integration from DAY 1, and cut a couple of corners if necessary on quality and performance on your individual components, the end result becomes far superior, and much more easily maintained. Simply because your different individual parts doesn’t scatter “all over the place”, and focus on their individual success. They are rather focusing on the group’s success as a whole. Hence, your framework, realises it is not existing as a bunch of single entities, but rather as a collection of entities, such that group dynamics kicks in, and decides the faith for it as a whole, and hence your ability to deliver good quality end results to your clients at deadline. So hence, an inferior software development framework measured on its individual parts’ performance, will still run in circles around the combined efforts of the “best individual parts in the world”.

In fact, this also consistently improves security too, even to the point where you’ll have to cut corners, arguably from an individual point of view reducing security. The last Efail security concern about encrypted emails for instance, was not a problem with encryption standards, it was not a problem with email clients. It was in fact a problem where you could not put the blame on any single individual component in your system. Still the security flaw was as real as daylight. I happen to have this knowledge from “the best MIME library creation expert on the planet”. This was a bug in how the encryption libraries were *integrated* into the email client! So arguably, even to the point where you’ll have to “cut corner in regards to security”, security as a whole still improves, simply by realising it’s not about the individual component’s performance. It’s about “the group” as a whole (framework), and its ability to perform its task as a whole!

Mythical Man Month … What month did you say …?

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.