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.
- Comprehensibility
- Ease of implementation
- Extensibility
- Usability
- Maintainability
- Transparency
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?
Interesting post about a theme that catch me.
For the theory about quality have a look at the "metaphysic of quality" founded by Robert Persig and his book "Zen and the art of motorcycle maintenance" is a must read.
I infer the more general concept of quality from the "aesthetics" concept you use.
Your last sentence is typically what is found in Pirsig's book : "great art is recognized all over the world as great art" but the Pirsig's toughts about this is why ?
I also make a comparaison with UML diagram that you can found aesthetics (easy to read, with a correct layout, with meaningful nouns, etc)
Forgot the links in my previous post :
Metaphysic of quality
Robert Pirsig's website
First, do we have to have the whole post in the feed? Especially when it has this level of navel gazing. A feed description should be shortish. Not an essay.
Second, I think you've got Ockham's Razor wrong. The razor states that you should not unnecessarily complicate things. If things need to be complicated, then they need to be complicated.
A CTO I once worked for was fond of saying "hey, it's not rocket science" to which I would respond "no, it's much more complicated than that". And it was.
Third, in general Java people do seem to look for the most complicated solution. But I think that's cultural. Look at some of the stuff that Sun do with Java and you can see the complexity. I was involved with the Servlet API expert group and Sun forced complexity (in the form of schemas for deployment descriptors) on us.
In general, I think that simplicity comes from reduced choices. Therefore, there is always a trade-off between simplicity and flexibility. I would say that the most common case of unnecessary complexity comes from trying to make your code too flexible. Make it do one thing well, code it to the immediate needs of the problem you are trying to solve, and make it more flexible (and therefore complex) when the need arises.
I'm a Mac fan, and that's always been the core essence of the Mac: Give the user fewer choices, which increases simplicity and decreases flexibility. If the few choices that you offer will cover 80-90% of users requirements, and you do that with half the number of choices, then in my opinion that's a win.
From the standpoint of an end-user of an API, I'd say that it quite simply boils down to the number of classes, and to a lesser extent the number of methods, that there are in the API. If I'm using the API, I'd like to see a list of classes that I can view in my browser without scrolling, some example code in an overview.html or package doc showing the most common use cases, and a reasonable number of methods in the class.
I agree with Jesse. In my projects, I design for flexibility based on the immediate requirements. If i know of a future requirement that needs to be addressed, I usually document it (UML or sketch it up) but unless its a real need I don't implement it.
I also think complexity is inevitable in certain projects - you cannot and shouldn't simplify your domain to the point where its an incorrect and/or incomplete representation of the requirement. As a software developer I enjoy solving complex problems - the challenge is managing that complexity in a way so the solution is functionally adequate, flexible (subjective, based on the requirements/problem domain), and maintainable.
Jeremie - Thanks for the links. I'll check them out.
Nic - I referred to Occams Razor used for evaluating the likeliness of an explanation of a phenomenon. Your remark on Java culture and complexity is definitely food for thought, don't you think?
Jesse, Vijay - Good point. I like the notion you propose and I try to code as you do. The question is: how do you know, that you have accomplished your goals?
Norbert,
Let me provide a real-world scenario: currently i am working on the redesign/rearchitecture of a big module in our inhouse content management solution. There are a lot of design changes/improvements/refactorings that can be done and the complexity is challenging. To make things intersting, our portal environment where the content solution is currently heavily leveraged is migrating from Microsoft to J2EE platform. Of course, the business clients wouldn't be willing to live with no new functionality while we patiently redesign our current solution. So my challenge is to provide new functionality, improve existing codebase, as well as ensure a smooth integration with a new platform in a tight deadline.
What i usually do is come with a list of design objectives and categorize them as business driver, tech driver, customer/User driver. I also do a simple high/medium/low priority for these. In that sense I have identified design improvements/flexibility needs based on what's the high priority drivers. I know the plan for our project for the next year so i am making the redesigns along with delivering new functionality. Refactor which one first? well, that's determined by various factors that i listed above. In my case I am redesigning the publishing module - since this has big implications for the portal and it will also provide a solid platform for addressing new requirements. As we redesign this, the team gets ideas on fixing/creating/improving classes/code and we simply document them at this point. I think there is a tradeoff in deciding where to invest for design flexibility - and that decision if driven by business needs and is aligned with the overall technical direction that the team or division is headed towards. If the tradeoffs are managed effectively, I would think the key goals of the project are getting accomplished.
re: Norbert, complex problems require complex solutions, I have yet in my career to find a problem worth solving that was easily solve by very simple code. If you are doing it in Java, I'm going to assume that there is a very good reason, it is a problem that requires this level of complexity.
"Simplicity" as a concept is much abused. I've found that the concept of "simplicity" is often used as an abstract critique of code by someone not intimately familiar with the problem being solved. Complexify freely..
re: Nic F., What the hell does a deployment descriptor schema have to do with the complexity of the servlet API. You could've maybe come up with some concrete criticisms like, the Servlet API isn't really extensible, and I hate the fact that we're tied to a single-file XML descriptor.
Also, Nic, the complexity of Java solutions is a function of the fact that simpler problems are best solved by simpler technologies. If your system can survive the several assumptions made by Rail, then it probably shouldn't be using J2EE.
Vijay -- What you describe sounds like a development process with which you want to ensure high quality code. If you and your people can execute this plan well, you will end up with a well managed project and hopefully great code. What I like to find out is whether or not it's possible to infer from an existing code base to the quality of that code and the simplicity (actually, quality, as Jeremie suggested) of the solution it provides with respect to the criteria mentioned in my post. Of course, there may be more.
Tim -- I agree with the notion that complex problems require complex solutions. Also, the abuse of the term simplicity rings a bell... Let me rephrase the question: If you are convinced that the software you produce is the best way to map the complexity of the problem to the way it is handled in the system, what is the most powerful argument, that would solidify your claim? (My guess is that you would differentiate your argument depending on whom you are talking to. In the end is there a common denominator?)
Norbert,
Simplicity is in the eye of the beholder...
I would focus more on the comment "not straight-forward". More than likely, they are commenting that the mapping between the requirements and how you implement the requirements requires them to comprehend "something else"...
For example, you may be using something like Hibernate to get information out of a database. This now requires a maintainer to understand Hibernate before your solution makes sense... and they might consider your solution "not straight-forward" even though the code that you wrote was very "clean".
Just something to consider.
Most of the time, developers seem to think that a complex problem should need a complex solution. It is however, possible to come up with a simple solution, if we are open minded and think out-of-box. For example, Ruby-on-Rails uses some conventions to set things up where as most Java based frameworks use XML configuration files. The latter is a maintenance nightmare, but you can still see them in use in such frameworks as Struts, Hibernate and Spring. In other words, it is possible to simplify things; we must be determined to do that.
Peace.
This discussion reminds me of two Extreme Programming practices: Do the simplest thing that could possibly work and you aren't gonna need it. Quite a bit more discussion at those pages if you are interested in the topic.
Ryan -- I like Ward Cunningham: Simple is easy to reason about. This does not take the context of the beholder in account, as John and I mentioned, but still it's a pretty good observation. A friend of mine whom I talked about this topic, came up as well with Einstein's phrase about simple solutions -- which has obviously found its way into XP. The YAGNI principle sounds fair, because I use IntelliJ, but for my DBA friends, it's another story...
I guess, in the end, we will not get around that the simplicity of a solution will always be subjectively judged and cannot be reduced to objective criteria. In a sad way, it makes sense.