Some of you might know by now that simplicity is the most important development metric for me. That’s because I have seen so many times what can happen to complex code and it isn’t nice. Complex code is harder to understand, difficult to maintain, nearly impossible to extend and downright ugly.

Complexity

Some developers tend to over-complicate a task and ends up writing too many classes to solve a simple problem. The ability to take a step back and observe the problem space before digging in to a detail is hard, but it will keep you from over-complicating matters. The more experience a developer have, the easier it becomes to find out how many steps backwards to take in order to fully understand the problem space.

Should you end up with a complex solution, then you must learn to identify it before moving on to the next task. If you are in doubt about the complexity, then it is too complex. You have to be able to say “this is a nice and simple solution” otherwise it probably isn’t.

Don’t mistake simplicity for something that only fixes simple problems, while a more complex solution is needed for complex problems. That is not the case. Simplicity can be applied to all sorts of problems no matter how complex they are. That’s because simplicity exists in the problem space or application scope and not within the problem itself.

It is absolule but subjective

Just because a problem space is relative in size doesn’t mean that simplicity is also relative. Simplicity is a constant and it is applicable to every piece of code ever written. If it was relative then each developer could define how much and thereby have an argument for writing complex code.

The problem with simplicity is that it is subjective. There are no tools that can analyze your code and tell you if is simple enough. Some tools try, but none succeed. So it’s all up to the developer to decide anyway and that is too bad. Code reviews does help a bit, but only a bit.

Know your limitations

I’ve always believed that if you cannot find a simple solution then don’t do it at all. That’s because if you cannot take a step back and get a good feeling for the problem, then you don’t understand it enough to see a simple solution – and trust me, there is always a simple solution. If you don’t understand the problem you are trying to solve, then you probably cannot solve it. It would be like saying “my car makes a strange sound, I think I will remove the engine to see if it makes it stop”. That’s not the best idea. Then it's time to ask for help understanding the problem.

About 5 years ago when the .NET Framework was released, it was the big new story and got a lot of attention by the blogosphere and technical magazines – both good and bad – and continued to do so for some years.

When .NET was released to the industry it felt like a disturbance in the force, the ground shook and developers didn’t know what to make of it. Java people quickly attacked the performance issues regarding the 1.0 release and called it a bad Java clone. People were really offended by the Framework and a hate campaign toward Microsoft was on the rise - even amongst the old Windows developers.

Internal debates

A lot of the developers that made a living by doing ASP websites or Windows applications in Visual Basic or Visual C++ felt abandoned by Microsoft, because they would stop making new versions of their preferred tool or language. They also introduced this framework that forced them to learn something completely new if they wanted to be on track. I myself had a hard time learning ASP.NET 1.0 coming from ASP3.

Furthermore, there were huge debates about the choice of which of the languages were the best, C# or VB.NET, with a lot of stupid, emotional claims of the pros and cons. This debate continued for years without really solving anything other than making us tired of it in the end. The blogosphere in general were condescending if you accidentally told anyone that you liked VB.NET over C#. It was a taboo somewhere and I felt it because I choose VB.NET back then.

It seemed that angry people were coming from everywhere and they all had some clever opinion to share about the .NET Framework.

We grew up

Whether it was because we got tired of the debates or finally came to realize how stupid it was, it somehow seems to have stopped. There are no recent articles or posts about language preferences anymore within the .NET fold. Maybe we realized that personal preferences is ok and as long we can work together no matter the language, there is no longer a need for the debate. And just maybe we all got so indoctrinated by Microsoft that we no longer raise the questions.

It seems that we’ve reached an understanding that was impossible to reach a few years back – an understanding that lets us focus on the real issues instead of the stupid, emotional ones – issues like deadlines, teamwork, project management, code quality etc.

Some didn’t

The last two years or so we can see history repeat itself. The flaming, the stupid and emotional comparisons and the urge to debate something that isn’t necessary. Dynamic language evangelists seem to have forgotten what happened just 5 years ago and is starting all over again. It could be a publicity stunt that might just work, if you are easily persuaded.

A philosopher, which name I have forgotten (probably in the heat of the stupid debates) once said:

From history we have learned, that we haven’t learned anything from history.