On the last two projects I have worked on, some people have attributed my contributions with “too complex”, “too difficult” and “not straightforward”. Since then I have been trying to determine whether or not that is true and how to tell the difference. After reading Kurt Cagles Thoughts on Complexity I did some researching and found that commonly people think about complexity and how to manage it best. However, if simplicity is the conceptual inverse of complexity, shouldn’t we be concerned about designing simple solutions rather than managing complexity? The problem is, as Kurt pointed out, someone has to pay the price, since it is impossible to eliminate complexity — it is just moved within the system. Hence, abstraction is often the most popular way of hiding complexity.
In many cases that’s fine. Design Patterns provide us with many powerful ways to overcome complex solutions, however they also require a necessary level of understanding that is needed to really grasp what is going on. How many managers consider an implementation of Design Patterns simple?
So, I came up with the following list of criteria for simple solutions.
- Ease of implementation
These criteria are in part contradictory. Obviously, an easy implementation (aka, a hack) will mostly be very hard to extend. And we are not even talking about comprehending what has been done.
There is more. The simplicity of a solution is determined by many factors and has to be evaluated in different contexts. The context of the developer, the user, the manager, the press and all the different levels of education and experience that these groups possess. User does not equal user.
But. Wait. Why bother about simple solutions anyway? Well, giving a nod to the principle of Occams Razor, I’d contend that the simplest solution is most likely the overall best solution. Now, how do we tell the complex solution from the simple solution? Code metrics? Code reviews, plain and simple? User reports? Management evalutation? Automated tests?
You tell me, since I really haven’t found an answer that does little more than transform the problem into somthing that I can grasp immediately. That is aesthetics. I am not kidding. If I look at code and find it aesthetically satisfying, chances are it’s stable, easy to understand, transparent to use and my guess is that the person who wrote it had some fun doing it. I know, that if I look at my code and this applies (especially after some time) then it works pretty well. Hmm. It works the other way, too, when I cannot believe what I was thinking… Also, the inverse is not necessarily true. Meaning, very ugly code could be extremely potent, useful and stable.
In fact, there are people who believe that there no correlation whatsoever between great software and its underlying source code. Look at The unseen impact on ease of use on system/code architecture by Scott Berkun (whom I like to read by the way, but I disagree on this particular point). An example for aesthetically pleasing and thus, possibly, great code could be PicoContainer.
To sum it up, great art is recognized all over the world as great art. Does the same count for code?