I think most of us developers would agree that keeping our software as simple as possible is a noble aim. I guess there are some developers who like to make things unnecessarily complex, but I for one hope not to spend too much of my life maintaining their code. I'm sure that no reader of my blog would fall into that category. No, we're talking about "other people" now.

Anyway, simplicity. What does that actually mean? I can think of a few definitions; I'm sure there are others...

1. Fewest possible lines in your source code.

I'm sure we've all seen those pathological examples where a whole lot of meaning is crammed into a few characters. Normally these examples are in C although I've seen good ones in Ruby and Perl too.  So clearly simplest != fewest characters.

No, these things are clearly not "simple" in any practical sense. But, to some extent at least, trying to minimize lines of source code is a good idea. If you can make things clearer by removing code, do so. If removing code makes things less clear, don't do it.

2. Smallest amount of code overall.

I'm not talking about highly-optimized code necessarily. You could write few lines of source code yourself, but behind those few lines could be millions of lines of library or API code. People maintaining your code are probably affected by the complexity of code that yours calls, so it might be a good idea to give some thought to the particular calls you make and just how complex those implementations are. Of course, that has other benefits too.

3. Simplest logic.

Trying not to have too many nested levels of if/else with complicated, inter-related condition clauses. That's probably a good idea.

4. Most "obvious" code.

Is it better to have more lines of code that clearly copies values from A to B, or is it better to use some data-binding API that allows you to set up relationships between A and B, without knowing exactly when the values get copied? Me, I prefer to be in control and I'd rather suffer a few more lines of code if their meaning is explicit. Actually, Windows Forms data-binding is currently out-of-favour with me. I'll write about why in a separate post I think.

All my comments above assume that creating "simple" code is your top priority. In some cases other priorities come first and that's quite natural. Performance, security, or customisability could all lead to more complex code for example. But the goal of creating complex code for its own sake comes nowhere in the top-100 priorities of a software developer. If it's not already clear in your team, why not ask the person in charge to prioritize the various aspects that your system could exhibit...

1. Performance
2. Correctness
3. Maintainability
4. Security
5. Scalability
6. etc. etc.

...and assuming that Maintainability appears in their list, drill into that a bit further.  Do they want the code to be "simple"?  What do they mean by "simple"?