<< Extending Authentication on Facebook SDK | No Code-Behind for MVVM >>

Complexity that rules us all

Posted by SondreB on May 20, 2010
84 comments

Complexity is the number one cause [1] of failures on IT-projects. It’s probably the number one reason for any type of project failure. Failed projects and bad software makes our customers and users unhappy.

What are the reason we initiate IT-projects? It’s all about reducing complex problems to meaningful tasks that can be completed by humans.

Law of Software

Let’s focus on software development and what value software have for the users. Building software is what I and thousands of others are doing every single day, and we’re not exactly becoming better at what we’re doing, we’re actually only able to successfully complete aprox. 30% [2] of the projects that are initiated.

According to David S. Platt’s 3 Laws of Software, the software we build have zero value in and of itself. It doesn’t matter how technically good your code is, the only individual who cares are you and your own mother.

Platt’s 3 Law of Software [3] says the following:

1. Your software has zero value in and of itself. Only value it ever has is how it enhances the happiness of the user.

2. Software can increase users’ happiness in one of two ways. It can help a user accomplish a task that she wants done or it can give the user pleasure. Example: Outlook helps you read and write emails, HALO on the Xbox gives you pleasure and fun.

3. The users should not think about your computer program. At all. Ever.

(Click the link above to read the full law, I’ve just included the highlights)

What is writing software?

Writing software is the undertaking of understanding any arbitrary complex problem and writing software instructions to solve those complex problems.

The goal of writing software should be to reduce complex problems to simple tasks. Simple tasks that humans can initiate, often without requiring much need for thinking. The less the user is required to think, the happier and more productive they will be.

Thinking simple

When you have a complex problem you want to solve, what do we tend to use as mechanisms to solve them? It’s obviously not thinking in simple terms, this is pretty obvious when you look at the software we’re building.

As our understanding of a complex problem increases (as we work out the details of a software design), we can’t seem to be able to come up with simple solutions, we often take this route of thinking: Complex problems requires complex solutions.

This is wrong, and it’s the root cause of so many software project failures.

We need to start thinking simple. We need to figure out how we can reduce the complex details of a design, until we have an design and architecture that is as simple as possible and still delivers the value for our users.

Our goal should be: Least complex architecture possible [4].

There are many reasons why something ends up being complex, one important factor is the amount of functionality we put into our software. According to Robert L. Glass [5] in his book Facts and Fallacies of Software Engineering, the fact is as following, 25% increase in functionality increases complexity by 100%.

Next time you are faced with a complex problem that someone wants to be solved using software, start by thinking about the users and how you can increase their happiness. Then start reducing the initial complex solution of the complex problem, into the most simple solution you can which still achieves the goal: Making your users happy!