Simplicity or not at all

Apr 21, 2007

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.

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included
Comments (11)

Comments (11) -

Dan Atkinson
Dan Atkinson United Kingdom
4/22/2007 1:47:35 PM #

For every person who shows a bit of code in ten lines, there's another who can do it in five, and a Python-er who gloats about the fact that they can do it in one.

At the end of the day, all three solutions are acceptable and I think saying "do it as simple as possible or don't do it at all" isn't the right way to go about it.

For example, there are times at work when I have to knock something together within an hour or two and I don't have time to take a step back, get out my pens and draw some nice diagrams! Even more so, I don't have the ability to turn around and say "no, I can't do it without making it simple". If I did, I'd sound like a perfectionist prat! Smile

So... I'm not sure your argument is completely weatherproof, unless you have plenty of time and the carnal knowledge of the language you're working in.

Mads Kristensen
Mads Kristensen Denmark
4/22/2007 2:20:47 PM #

When you are new to something, it can be difficult to understand the problem before trying to solve it. That's natural. That's the only time it is acceptable to write complex code in my opinion. If you do it otherwise, it is because you don't understand the problem fully. And if you don't understand the problem, you might just end up breaking more things than you fix. Simplicity has nothing to do with the number of code lines, but with the code itself.

Dan
Dan Spain
4/22/2007 5:06:03 PM #

It's a good moment to write this post after giving the community a good example with BlogEngine.NET.
Anyway, I read in some blog something like this: "Keep the simple things simple and make the difficult ones possible".
If you have to deal with over-engineered legacy code in your job, code that works, and you have to modify it I suppose the logic of simplicity is not to modify the core.

The nice thing about your blog engine is how easy you added ajax support for comments, you don't have to deal with four or five levels of indirection for saving a dumb comment.

Mads Kristensen
Mads Kristensen Denmark
4/22/2007 6:24:15 PM #

Dan, I would lie if I told you that all my code is simple. It's not. I try to keep it simple and go to great length to do so, but there are times when I don't for different reasons. Legacy being one of them because I'm too lazy when it comes to that. But everytime my code isn't simple I feel bad about it.

Denny Ferrassoli
Denny Ferrassoli United States
4/22/2007 6:44:03 PM #

I've always loved Albert Einstein's quote: "Everything should be made as simple as possible, but not simpler."

Dan Atkinson
Dan Atkinson United Kingdom
4/23/2007 7:06:52 AM #

I don't about that quote. That would be like saying make a leap, but don't take steps toward your goal. You can only make it as simple as you know how to. Someone might come along and suggest another, much simpler way. The only way we learn how to do things simpler is to do them the best way we know, and find out an easier/better method later on (or having those brainwaves in the middle of a restaurant like I do!).

Not only that, but languages (C# and .NET in general) are a moving goal at any rate and making something simple in one version might be obsolete/deprecated in another. Lets throw generics out there as a great example.

Andrew Sazonov
Andrew Sazonov Ukraine
4/23/2007 3:06:05 PM #

Oh, it seems that this is just another formulation of Occam's razor - "entities should not be multiplied beyond necessity" but applied to software development.

But actually, there are another principle: "keep things things simple as practical, but not simpler"
However, it's often that demand for simplicity omits the last part - "not simpler".  

I think that the problem of simplicity should be considered not as some separate and independent issue, but rather related to particular tasks. For example, simplicity is absolutely good.

But what if you write some reusable code or library? Which choice should be made by developer if simplicity limits possible usages or future extensions of the library?

Jesper
Jesper Denmark
4/23/2007 3:41:39 PM #

I'm with Andrew here. Simplicity should be a priority, but you should never loose sight of the problem you are solving. Will extra simplicity help? And simplicity doesn't come for free. It takes time and work and could cost performance and ease-of-use.

Mads Kristensen
Mads Kristensen Denmark
4/23/2007 3:47:25 PM #

Andrew and Jesper, simplicity does not limit anything otherwise you don't understand the problem space fully. When I code, I think of simplicity as being an independant issue, just the way as is TDD for others. You can choose not to, but I believe it is too important to think of as a related thing to a particular task.

TweeZz
TweeZz
4/24/2007 4:26:36 AM #

Writing readable code. Haacked made a post about it yesterday:
haacked.com/.../...aking-its-intentions-clear.aspx

I'm testing in the meantime if the counting is already fixed Mads ;)

<html>
<html> Costa Rica
4/24/2007 9:28:37 PM #

sd <html> checking

Comments are closed

About the author

Mads Kristensen

Mads Kristensen
Program Manager at the Microsoft Web Platform team and founder of BlogEngine.NET.

More...

Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.