The Codist

"Make everything as simple as possible, but not simpler."

"Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."

These are two of my favorite quotes (attributed to Albert Einstein), and have always inspired me over my career in programming. The longer I've worked on projects in this industry the more a clear, simple approach to coding and architecture appeals to me. Sadly the tendency to overcomplicate things (and defend them as necessary) seems to be the more common approach.

I think programmers in general, if they are smart and observant, prefer a simple, understandable, approach to architecture, api's, coding and design. Unfortunately what appeals to us doesn't always appeal to those we work for, or to vendors who prefer to sell complex systems to companies with more money than sense. Many vendors make more money selling consulting and configuration services than from the actual products (ERP system for example are notorious). Simple makes no money.

J2EE for example, was never a simple environment to work with, and got even more complex over the years. Writing JSPs, even with helper frameworks like Struts, still requires way too much configuration and over time becomes unreadable. I remember the first time I wrote an EJB when J2EE first came out I had to write something like 18 separate files. Eventually tools made this somewhat easier but I always rejected using EJBs if possible since they were too much useless work, and had way too many limitations for the pain. At least with EJB3 a simple thought crept into someone's mind.

Lately I have been investigating CMS systems for a customer. There are hundreds of open source and closed-source systems out there. Yet almost all of them were either difficult to set up, hard to customize (building templates), had poor UI (one had so many buttons on the screen I got dizzy) or had so many options I couldn't find the few I needed. Only one I tried (of the open source variety) was rather pleasant to use but lacked some features (CMS Made Simple). I only tried about a dozen of the more popular ones, so I can't say there isn't a more perfect one out there. But the primary issue with most of them is that the were an agglomeration of cool feature on top of cool feature. Basically they forgot quote #1 and fulfilled quote #2.

Now saying I like simple doesn't mean I like useless or powerless functionality. Einstein's famous equation doesn't look like much but it changed the world. He (and those his work was based on) took a lot of time to come up with how to express the concept in this compact form. The trouble with a lot of software that I have seen is that the architects, designers and coders either don't or can't take the time (or aren't imaginative or experienced enough) to understand how to create something that does the job with a minimum of complexity. Sometimes the tools or frameworks or environments we are forced to work in or with don't make it possible. That's a sad thing.

Sometimes what we are working on is complicated to understand, code and create. My argument is not to simplify the requirements for what we are doing but to find the simplest, most effective way to implement them. It's not that I want to write code so simple my mother could understand it; I want to find the minimum of complexity (the "not simpler" clause).

So what does this mean in a practical world? Use languages, tools, frameworks, and create environments, methodologies and plans that let us create software without complexity, and reject or avoid those that make it more complex. One of the benefits of Ruby On Rails for example is to allow rapid development without a lot of extra work. Although I don't use that (yet) I try to find ways with Java to achieve the same benefits. I avoid Java frameworks with too many XML configurations or attributions or way too many options. For example I prefer iBatis to Hibernate, avoid most of Spring outside the core, hate JSP/Struts with a passion, prefer REST to SOAP, and use Jetty instead of Tomcat/Weblogic/Websphere/JBoss if at all possible. It's not that any of these are necessarily unusable or that one can't do an excellent job with them; I make choices based on how simple I can design with them, code them, debug them and understand what I have done months later. If you work on a team with a mixed set of good, bad, and indifferent programmers complexity is a guarantee of failure.

If you work in a complex environment, and your management isn't willing to accept that things are too complex due to your language, tools, systems and methodology, then go somewhere else. Making things simpler (but not too simple) takes time, it takes a lot of work, and it takes discipline to know when to stop. These are hard concepts to convey to managers who are under pressure to deliver. Often decisions that led to a complex environment are historical and simplifying is a tough option. That's the sad part of our industry; often the things that would improve our productivity, ability to deliver quality results, and ultimately save money are the last things we get to do. Taking the time to put together a simpler solution seems to be a tough sell. But it reminds me of the old commercial "you can pay me now, or pay me more later".