John Topley’s Weblog

Do the best programmers know how to Keep It Simple, Stupid? Is simplicity itself a desirable goal? I didn't used to subscribe to the idea that simple was always best. I thought that sometimes complexity was the only answer. After a year spent learning Java enterprise programming, I'm beginning to change my mind.

I think I'm suffering from J2EE fatigue. It's characterised by an inability to comprehend the myriad of XML configuration files, some of which override others, and by a weary indifference to whatever new open source whizz-bang designed to simplify J2EE development is.

I came into the programming game by writing desktop applications using Delphi and Visual Basic. Sometimes I even called the Windows API directly! Quite often, actually. However, J2EE is a whole leap upwards in complexity and I'm not just talking about the straight programming either. Sure, there are the thousands of classes that form the Sun Microsystems' J2EE specification (easy to see how one might re-invent the wheel out of ignorance). There's also a whole plethora of design patterns over and above the regular Gang of Four pattern catalogue. In J2EE-land you're a nobody unless you know your Struts from your Hibernate, your JUnit from your JBoss or your Ant from your Maven. Reading TheServerSide, you might be forgiven for forgetting that most of this stuff can safely be ignored and that you really should just concentrate on the job at hand.

“Computer science is the discipline that believes all problems can be solved with one more layer of indirection.”

Dennis DeBruler

I'm no longer entirely convinced about the need to hide the database tier behind layers of abstraction and indirection. After all, how often do companies change their enterprise database? Once every five years? Every ten years? Fifteen years? By that time the rest of the code will almost certainly need to be rewritten anyway. A lot of modern development seems to be taking the time to go the extra mile initially and put code in that will make change less painful later on. Having to change and maintain the code is almost inevitable, but who can predict what form it will take? One of the philosophies behind Extreme Programming is that you should build as little as you can get away with and try not to anticipate and incorporate future enhancements.

“…there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies”.

C.A.R. Hoare, The 1980 ACM Turing Award Lecture

Weren't object-oriented programming, design patterns and frameworks supposed to make life simpler for the poor sod writing the code? Sometimes it seems that there's so much to think about and remember that the opposite seems true. I doubt that very few of us program as those who came before us did. Today, most of us use frameworks and classes created by people far cleverer than we are.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when when you write it, how will you ever debug it?”

Kernighan and Plaugher, The Elements of Programming Style

There are some encouraging signs that things are changing for the better. I read today that Microsoft are aiming to reduce the Windows API set from the 76,000 APIs in Win32 to 8,000 .NET APIs in Windows Longhorn. Being nice shiny new .NET APIs, they should have some semblance of cohesion and consistency to them, so that knowledge gained can be gainfully exploited elsewhere. Let's hope so.

Over on the other side of the dividing line between good and evil—I won't tell you which is which—Sun are making encouraging noises about simplifying J2EE development, which I welcome. That's in the future. Today, I'm still not sure where I stand on keeping it simple, stupid. I do think I've found a guiding principle though:

“Things should be made as simple as possible, but no simpler.”

Albert Einstein