Edward De Bono, in his great little book, simply titled "Simplicity", says,
"Dealing with complexity is an inefficient and unnecessary waste of time, attention, and mental energy. There is never any justification for things being complex when they could be simple".
In our profession we are plagued by complexity. A computer professional specializing in Java today has to decide which part of Java to specialize in. The Java EE specs are now hefty documents - aside from the many implementations. The Java EE Tutorial is 1262 pages (I remember when it was about 300). The table of contents is 24 pages. The document is 38 chapters. Some of the specs referred to are: EJB, Servlets, JSP, JSTL, JSF, JMS, JTS, JTA, JAXP, JAX-WS, JAXB, StAX, SAAJ, JAXR, JCA, JDBC, JPA, JNDI, JAAS. Give yourself a self-test, how many of these acronyms do you know? and how well do you know the specs they are referring to? How well does that help you design Java enterprise applications? How long do you need to study the tutorial?
The above paragraphs describes our technology - our tools. If our technology is that complex, how will that affect our approaches to design? Design approaches, patterns, and frameworks now have several schools of thought (EJB/No EJB, IoC, Containers/No Containers,Aspects/No Aspects, PoJos only, Model Driven, Use Case Driven, Test Driven, RUP, Agile, XP), etc. Database access alone is becoming a specialty.
How do we cope with the increasing complexity? The only answer is to consciously seek simplicity - as a value and as a goal - and to systematically apply simplicity tests to proposed ideas and solutions.
The very first thing to do about simplicity is to decide if simplicity is something you value. If you think that complexity is inevitable, insurmountable, or unavoidable, then you will not value simplicity and will dismiss it as simple-mindedness in the face of inherently complex world. If you value complexity for complexity's sake (some people do for reasons that have more to do with status, psychology, and politics than with design), you will also see value in opposing simplicity.
I will assume that we all value simplicity, and will leave the debate of "simplicity vs complexity as desirable values" for a forum topic.
Once you've accepted simplicity as a value, I think the starting point would be to simplify your language. The way you express your thoughts, in speaking and in writing, reflects strongly whether you value simplicity over complexity.
One of the basics of expression is sentence structure - the grammatical construction of sentences. We have simple sentences and compound sentences. If you find you prefer compound sentences to simple, long sentences to short, indirect sentences to direct, obscure sentences to clear, then it would be hard to move on to simplicity of thought and of design.
This leads me to one of the best books I ever read, and the only book that remained from my Freshman year in college (and that was a loooooooooooong time ago!), is the little classic by Strunk and White, "The Elements of Style". One of a few books I read and re-read constantly.
Here are a few nuggets from that little book (every page, and sentence in that book is valuable):
- Choose a suitable design and hold to it
- Omit needless words
- Keep related words together
- Revise and rewrite
- Do not overwrite
- Do not overstate
- Be clear
- Do not take short cuts at the cost of clarity
- Prefer the standard to the offbeat
I chose these writing guidelines because they are not only pertinent to writing, but extendable to software design. You can paraphrase them directly and apply them to software:
- Choose a suitable design and hold to it (no need to paraphrase!)
But here is a paraphrase from the details of the guideline: "In some cases the best design is no design. But in most cases planning must be a deliberate prelude. The first principle of composition, therefore, is to foresee or determine the shape of what is to come and to pursue that shape." This is a great definition of what design is: to foresee, or determine, the shape of what is to come.
- Omit needless constructs (classes, objects, methods, and variables - minimality is valuable)
- Keep related constructs together (usually called cohesion)
- Revise and re-code (refactor)
- Do not overwrite (do not over engineer)
- Do not overstate (use minimal constructs)
- Be clear (intent-revealing code)
- Do not take short cuts (avoid early optimization)
- Prefer the standard (follow standard practices, prefer that to "cool", clever, stuff).
The spirit of that little book is all about simplicity. And simplicity of expression has to be the starting point.
- An additional take away point from this quick reading of Strunk and White, is a working definition of simplicity, and a simple test for simplicity - so to speak. Simple is clear, minimal, and standard. Questions to pose for a design, or an idea, then are: is it clear, is it minimal, and is it standard?
Side note: A great deal of difficulty can arise when introducing new ideas by what I call "definitional issues". Discussions of meanings of words, and great debates about semantics, may ensue and railroad the discussion into an academic definitional argument. That could easily happen, particularly with fundamental concepts like simplicity. We must take great pains to avoid the semantics trap. When faced with definitional issues, we should opt for operational or working definitions - not abstract dictionary definitions. As engineers, and practitioners, we are more inclined to follow that path than academicians, and we would be much better off in this discussion than they would. In this working definition of simplicity, the word "standard" can introduce definitional difficulties. I suggest that it be interpreted in its weak sense of "agreed upon", not in its strong sense of a formal standard from a standards body.
There is much, much more to simplicity. And again, as De Bono says, "simplicity is not easy".
In future blogs I will go more into the writings of Edward DeBono and dive a little deeper into simplicity.
Recent Comments