Lifelong Learning

The Triumph of Complexity

Alan Greenspan's testimony to congress on Oct 23, 2008, has been amply dissected. Many people, including the congressional questioners, were downright hostile, and eager to place blame for the financial meltdown at Greenspan's feet. You can read tons of such analysis all over the web.

What struck me most listening to Greenspan was his humility, and honesty.  Many people would not make the admissions he made. That his lifelong philosophy was flawed, although he would admit to only partially flawed.

The statement that struck me most, and seems to have escaped most analysts, was his astounding admission that, "If all those extraordinarily capable people were unable to foresee the development of this critical problem ... we have to ask ourselves: Why is that? And the answer is that we're not smart enough as people.  We just cannot see events that far in advance". 

Now this is the man that had just finished talking about the Nobel prize being awarded for the discovery of pricing models. He has also talked about how competent and smart the economic modelers and forecasters at the Federal Reserve were. What he fundamentally said was that we were defeated by complexity. When the top minds in the financial world are "not smart enough", that is not lack of brain power, or education. It is the sheer scale of the complexity. This is a lesson the world better heed. Complexity can almost literally destroy us. Global complexity of the financial system is a topic that will be dealt with in the years to come by the best financial minds in the world, if we are to avoid a repeat of the tsunami that Greenspan thinks is a once in a hundred years event.

Complexity in our profession, system development and IT, can destroy systems, and destroy hopes of completing systems, and managing their development and operation.

A very conscious effort to slay the complexity monster, and a relentless focus on simplicity must be the concern of everyone in our profession. What Greenspan's testimony illustrates is that conquering complexity must at the forefront of all the managers of our economy, and our world.

My Favorite Quotes

Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. Henry Ford.

Successful conversation will take you very far. Badfinger.

You can't always get what you want. But if you try sometime, you might find, you get what you need. Mick Jagger.

Great minds discuss ideas. Average minds discuss events. Small minds discuss people. Eleanor Roosevelt.

Simplifying and simplicity are never simple matters.  Hans Hofmann.

Simplicity and communication have a wonderful mutually supporting relationship. Kent Beck.

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.  Alan Perlis.

One person's simple is another person's complex. Kent Beck.

What is simplicity? Delete everything that doesn't have a purpose. Kent Beck.

The principle of economy requires that representations of structure contain no more than the necessary elements. Noam Chomsky.

Minimalism derives from a need for simplification. Noam Chomsky.

Lets not combine ignorance with inaudibility. Speak up! Mrs. Cook, my freshman English Professor

Dealing with complexity is an unnecessary waste of time, attention, and mental energy. Edward de Bono.

There is never any justification for things being complex when they could be simple. Edward de Bono.

If you put something simply, you are at the mercy of those who understand neither the subject nor simplicity. Edward de Bono.

It is only when you have a headache that not having a headache is such a very high value. Edward de Bono.

Outside of art, complexity for the sake of complexity has no value whatsover. Edward de Bono.

There is a huge overlap between creativity and simplification. Edward de Bono.

Simplicity is not easy. Edward de Bono.

There is no natural tendency towards simplicity. Edward de Bono.

Simplicity needs a determined effort - it does not just happen. Edward de Bono.

There is a natural tendency for systems to increase in complexity over time. Edward de Bono.

Creativity is the description of a result. Lateral thinking is the description of a process. One can only admire a result, but one can learn to use a process. Edward de Bono.

Complexity sells better. Edsgar Dijkstra.

Elegance is not a dispensable luxury but a factor that decides between success and failure. Edsgar Dijkstra.

Simplicity is prerequisite for reliability. Edsgar Dijkstra.

The lurking suspicion that something could be simplified is the world's richest source of rewarding challenges. Edsgar Dijkstra.

Lets not let the facts bother us. One of my computer science professors at GA Tech.

All models are wrong. Some models are useful.- Bruce Eckel.

A genius is a talented person who has done all his homework. Thomas Edison.

The ability to simplify means to eliminate the unnecessary so that the necessary may speak. Hans Hofmann.

A good programming language helps programmers write good programs. No programming language will pervent its users from writing bad programs. Kees Koster.

Simplicity is the ultimate sophistication. Leonardo da Vinci.

Making the simple complicated is commonplace. Making the complicated simple, that's creativity. Charles Mingus.

Communication is a thought process, not the production of sound waves. Michel Thomas.

Don't get sidetracked by the sound waves.  Michel Thomas.

All generalizations are false, including this one. Mark Twain.

Most problems in computer science can be resolved by another level of indirection. David Wheeler.

People seem to misinterpret complexity as sophistication. Niklaus Wirth.

Simplicity vs Simplemindedness

To illustrate the difference between simplicity and simplemindedness, I'll use the example of learning a new language (we can generalize later and look at learning a new subject, say AOP,  design patterns, or SOA - anything that is not trivial and totally new to you - how do you approach the task simply but not simplemindedly).

How would you proceed in a simple, but not simplistic, fashion? The differences between simple and simplistic are not always obvious. A simplistic approach appears to be simple, but it would fail to accomplish the goal of acquiring the new knowledge, resulting in frustration and abandonment of the original goal. Many people quit learning a new language because most learning and teaching techniques are either simplistic or too complex.

If you believe in simplicity you would follow the simplest approach that could possibly work, as the XP proponents say. One simple approach could be (and different people would chose different approaches, there is no "one right way"), to use the so-called "learn the way children learn approach".

At first glance, it sounds attractive. Children absorb the sounds, words, sentences, and grammar, without going through structured series of lessons. They just do it! So lets emulate that.

One company that follows this approach is RosettaStone. They have a web site that teaches over 30 languages using that exact methodology. It appears very attractive, particularly because they use the same approach for all the languages, and there is no geometric explosion of language pairs. You teach a Chinese person French the same way you teach it to an American. No Chinese, or English is used! Only the target language (French) is used.

I gave it a spin to learn Spanish. There was a lot I liked. You learn mainly through pictures. There is no translation at all. There are no grammar lessons. You see the picture, hear it read aloud, figure out the meaning from the picture and start learning sentence patterns quite quickly.

After a couple of months of trying that I found that I wasn't making much progress. So I tried to analyze where the method failed me. I realized quickly that I could parrot some sentences, but I couldn't construct any new ones. I also discovered, that part of the "simplification" was omitting parts of the grammar they considered "difficult", like, the past tense! They had tens of sentences with the perfect tenses, so you could say, the equivalent of, "I have eaten", but you can't say, "I ate". You can say, "why haven't you called me", but you can't say, "why didn't you call me". That is fine, if you are concerned only about what you say! But if someone else says, "what did you eat last night", you wouldn't understand them, because the past tense does not exist at RosettaStone. The past tense! It is too complex!

Now that, in a nutshell, is simplification without simplicity. Totally vacuous, pointless, and counter productive.

Drilling down a bit deeper in the method, I discovered that the whole course is a set of 8400 sentences, each one illustrated with a picture. That's it. No grammar, no rules of any sort. Exactly like a child learns. But I am not a child, and I don't have 5 years to reach a stage where I can just do baby talk! In a year or so, I would like to be able to read a newspaper, listen to network news, read Don Quixote De La Mancha in the original, and converse with educated people.

I tried some of the other languages, like Arabic, Hebrew, Hindi, Chinese, and Korean. The method totally fails, because it does not use a transcription system at all. The original script is used (and your knowledge of it is assumed!). So to learn Arabic you have to, somehow, acquire the knowledge of the Arabic script outside or RosettaStone. Same for Hindi, Hebrew, Chinese, and the other non-Roman Alphabet languages. Apparently it was too hard to go this far on the simplicity-for-the-user scale. They would have to invent one a transcription scheme for each of the language. For Arabic, inventive teens have come with a Roman Alphabet scheme that is awesome, to help them text message and to IM. Probably something like that exists in Hindi and Chinese.

So my assessment of the RosettaStone method was that its simplicity is really simple mindedness. Not only that, but where it really was needed (a transcription system that equalized all the languages) it totally failed and went back to the original complexity.

So I decided to start over (one of the rules of simplicity). I sketched out a program for learning Spanish, that, to me, was simple, but not simple minded. It has several phases, it was layered, modular, and incremental.

Here's my method in a nutshell. The following steps apply to Roman Alphabet based languages. To learn a non-Roman Alphabet language like Hindi, or Hebrew, I would have to add a step to locate a Roman Alpha pet transcription scheme as step 0. If I can't find it, I wouldn't embark on learning that language.

1. An exploratory phase. Listen to Spanish radio, watch Spanish TV, get a Spanish magazine, or newspaper. Get a feel for the sounds, words, and letters of the language. Very quickly assess if you like the language or not and size up the task ahead.  Spanish would appear much less daunting than Hebrew, or Hindi. At least the letters are recognizable, and you can even attempt to read the words, as if they were English words.

2. Ear training phase. Get some CDs for "learning in your car". Listen to the sounds of the new language. Acquire basic phrases (maybe a few dozen phrases). Good morning, Good evening, Hello, How are you?, My name is, What is your name, Please repeat, I did not understand, You are speaking too fast, What does that xxx mean in English, How do you say yyy in Spanish, etc. At this stage you don't want to dive into anything more complex (like grammar, or writing).

3. Basic vocabulary phase: Acquire a basic vocabulary of maybe a few hundred words, and a few more phrases. Again ignoring grammar. Build a basic facility with the language based on rote memorization.

4. Grammar phase. After finishing the previous phases, with a minimal investment of time, you would realize whether you want to go forward or not. I could not continue with Hindi or Hebrew. I realized how much investment of time that would require! This is a decision point. To go forward you can't just keep memorizing phrases, the number of possible phrases in a language is infinite. You need to learn how to construct sentences correctly. And that requires grammar. There is no avoiding it. Speaking and writing requires generating new sentences from words based on the rules of correct construction. Even for understanding you need the parsing skill. But for speaking and writing you need the generative skill that you can get only from grammar. You don't want native speakers to laugh every time  you speak! This is the hardest phase of learning a new language. You just have to hunker down and do it. Learn the rules. Apply the rules.

5. Listening Skills phase. After acquiring basic vocabulary and grammar, you will still find that it is hard to watch Spanish TV, and to listen to CNN in Spanish. You still need several thousand words of vocabulary - probably 5000. What is the simplest way to acquire them? How do you pick the 5000 words you need? Best way is to find a list arranged by frequency of use. You then approach it in an incremental manner: 1st 100, 2nd 200, 3rd 300, etc. Since the order is by frequency of use, you are learning the first 100 most used words, then the first 200 most used words, etc. A simple approach that would be simpleminded is to just and read the dictionary and learn words alphabetically. You may learn 5000 words, but they won't be the 5000 most people use! Another simpleminded approach is to learn cognates just because they are simple. Cognates are words that look the same (or almost the same) and mean the same, but sound different (like color), or all words ending in "tion", can be similar but end in "cion". 

6. Writing Phase   At this stage you can chat and probably write email, and you can try your hand at composing simple passages.

7. Speaking Phase   By speaking I mean engaging in a dialog, not "pass the salt please", or "where is the nearest bank", or "I would like fries with that".

I leave the speaking to the end, because it is the phase that integrates all the others.

The rules of simplicity come in handy when trying to learn something new.

Simplicity - Why Is It So Hard?

There is a quote by Einstein that I often read. It goes like this, "Everything should be made as simple as possible, but not simpler."

I have never understood this quote. What can be simpler than "as simple as possible"? What is beyond that? How do you know when you've hit rock bottom in simplicity so that you won't attempt to go simpler - which Einstein doesn't want you to do? I felt somewhat stupid every time I saw that quote. It is very popular with writers on simplicity. That did not bother me much. For one thing, I know I'm no Einstein, and I know very few people who are. Actually the exact number I know is an integer less than 1. For another, I don't like to see quotes by Einstein. I find them show-offish, and I feel their purpose is to indicate how smart the writer is.

I finally got a glimpse as to what Einstein may have meant when I started reading De Bono. Now I understand the difference between simplicity and simple-mindedness. We need simplicity, but we need to guard against sliding into simple-mindedness. That is the crux of why achieving simplicity is so hard, and achieving simple-mindedness is, well, so simple.

To illustrate I will use my trials and tribulations over the last year of trying to learn Spanish. I could use similar stories of my difficulties over the last year with a crop of new ideas (to me they were) like AOP (Aspect Oriented Programming), TDD (Test Driven Design), or ROC (Recovery Oriented Computing), but I want to keep this light-hearted, so I'll leave the other heftier topics as an exercise for the reader, or for another day.

When I started looking into learning Spanish, I found a ton of resources: books, audio CDs, DVDs, and web sites, online dictionaries, online magazines, online grammar and dictionary sites, online translation sites, translation utilities for windows, etc. Many many of them. It is quite overwhelming just to go through what a decent Google search reveals about learning resources. All claiming to be simple, of course.

Since my guideline was, "as simple as possible". I downloaded a couple of learning resources. It was a lot of fun to learn the first twenty phrases and the first 100 words, and to learn how to say, good morning, good afternoon, how are you, and where is the bathroom. That, I could say, was "simple". I also tried several "learn in your car" CDs. I felt that I knew some Spanish. Then I tried to watch Spanish TV. Not a word! Couldn't understand the news, the commercials, or the soaps with all these lovely Latin ladies that wake up in the morning with full make up and their hair perfectly done!

So I thought, for phase II, let me try something a little less simple, but still billed as simple. I tried Rossettastone.com. Rosettastone teaches about 40 languages in an approach that is advertised as the simplest, the easiest. It uses only the target language. You learn Spanish in Spanish, and Arabic in Arabic. The basic philosophy is to learn as a child learned his native language. So they use pictures of things and situations to teach everything. No translation.No grammar. You find you learn pretty fast. After a couple of months I found I knew several hundred phrases and I could point out many objects - vegetables, animals, or minerals. I could compose sentences. Then I attempted my first Spanish conversation with a native speaker. I did very well with the simple things. I could say, "you're doing a good job", and "How are things going?". Then one day I wanted to say, "I called yesterday, and left a message". "Why didn't you call me back"?.

I suddenly discovered that, part of the "simplification" of the Rosettastone method is not to teach the past tense! They only teach you the present tense, and the "simpler" tenses - for example the perfect, instead of the past tense, because it has a simple formula, or pattern. "I have called". "I have eaten", instead of "I called", or "I ate". In their method you cannot say, "I called", and "I ate". That's fine, if you only converse with other Rosettastone students! The first time someone says, in Spanish, "why didn't you call me", you will have no idea what they have said. He's supposed to say only, "why haven't you called me". Then I began to understand clearly the difference between simple and simple-minded. This approach is not simple, it is moronically simple-minded. They achieve simplicity by teaching a subset of the language that, to their mind, constitutes "Spanish".

I had to stop to define what I mean when I said, "I know Spanish". That is to say, I needed to be clearer on my objectives. That is a very general life-lesson, but seeking simplicity forces us to face it. If you don't know what your objective is, you can't know what "simple" means! Simplicity is with respect to a given objective. If your objective is to learn 100 phrases so you can travel to Acapulco and order food in Spanish and find where the bank is, then the Rosettastone method is simple, and is adequate. But if your objective is to watch news in Spanish and be able to read a newspaper, enjoy a book, or a non-trivial conversation with a Spanish speaker, then Rosettastone and other "simple" methods are not adequate.

Whether a solution is simple or simple-minded depends on the other values sought in our project, and our overall objective. The subtle point here, and where the difficulty lies, is how do you know, when you don't know Spanish (or AOP, or ROC, or XXX), what constitutes "simple"?. You can easily be fooled by clever "marketers", and I'm using that term in a general sense for anyone promoting a simple solution.

How can we tell the difference before we invest time and money? Unfortunately that's the hard part. For you to know the difference between the simple and the simple-minded you need to know both the subject and simplicity. That is far from easy, or simple! Only after I dove into an in-depth study of Spanish grammar, did I realize how simple-minded the Rosettastone approach is.

I had a similar journey with AOP and TDD. Both disarmingly seemingly simple topics. But it is easy to slide into simplemindedness and to do things that are moronically simple in both. I hear many people claim they are doing TDD, or XP. A very cursory examination reveals they're doing nothing of the sort.They have no clue as to what TDD, or XP is. They have no clue what "simple" means.

I now fully understand that only people with the deepest and widest knowledge of a subject, and of simplicity, can, and should be allowed, to propose simple solutions. Those whose knowledge of both the subject and simplicity, is limited will come up with simple-minded schemes that they label as simple, but prove inadequate, frustrating, and wasteful of time and money.

Now I have a healthy respect for simplicity and a healthy skepticism towards anyone that bandies around claims of simplicity. I have tests for simplicity that I apply to try to uncover if a solution is simple or simple-minded.

There is also a related concept that De Bono talks about, but I don't have room to get into now. That is the concept of "complexity shift". Complexity shift is the second reason that simplicity is so hard. In another posting I hope to be able to return to it.

The Ten Rules of Simplicity

From Simplicity, by Edward De Bono

Rule 1. You need to put a very high value on simplicity.

Very few people put a high value on simplicity. They put some value on simplicity, but usually this is a "second-order" value. An operation must be effective, or an operation must save money. If that operation can also be simple, that would be nice. Simplicity is not often treated as a prime objective. If you do not put a high value on simplicity, then simplicity is unlikely to just happen.

Rule 2. You must be determined to seek simplicity.

Simplicity is not a peripheral luxury that is "added on". You must be motivated and determined to make an active effort to make things simpler. It is necessary to invest time, thinking energy, design effort, and money to make things more simple.

Rule 3. You need to understand the matter very well.

If you are seeking to understand a process you need to know that process very well. If you do not, then the results of your efforts will be simplistic rather than simple. True simplicity comes from thorough understanding.  Simplicity without understanding is worthless.

Rule 4. You need to design alternatives and possibilities.

The first idea to come to mind is very unlikely to be the best. That is why it is important to go on thinking and to produce further possibilities. The design process needs creativity and lateral thinking. It is not a matter of designing "the right way". It is more a matter of designing alternatives and possibilities.

Rule 5. You need to challenge and discard existing elements.

Everything needs to be challenged. Everything needs to justify its continued existence. Systems have a natural tendency to grow more complicated. Things that were needed at one time may no longer be needed.

Rule 6. You need to be prepared to start over again.

It is easier to modify an existing structure in order to make it simpler. Sometimes, however, you need to be able to start from the beginning. This is more difficult, more expensive, and less likely to be acceptable. So you need to show the benefits of the suggested new design, and why modification would never achieve the same benefits.

Rule 7. You need to use concepts.

If you are not using concepts, then you are working with detail. Concepts are the way the human mind simplifies the world. It is the precise purpose of concepts to be general, vague, and blurry.

Rule 8. You may need to break things down into smaller units.

Complex systems work best when there are sub-systems each of which has simpler organization.

Rule 9. You need to be prepared to trade off other values for simplicity.

You may need to tradeoff comprehensiveness for simplicity.  You may need to tradeoff perfection for practical simplicity.

Rule 10. You need to know for whose sake the simplicity is being designed.

Seeking simplicity may mean a "complexity shift". Making things simple for the customer, may make it much harder for the operator, or the developer.

         

Notes:

Rule 10 is what makes achieving simplicity very hard. The issue of "complexity shift" is subtle and will interfere very quickly with achieving simplicity, because we get mired into the questions of "simplicity for whom"?, and we have to be careful who the complexity  gets thrust upon, when complexity shift occurs, and it will occur - you cannot just will complexity away.  If we decide to make our goal, "simplicity for the user", then the rule becomes recursive, and essentially achieving simplicity proves in practice to be recursive. Each system has an end user, but it also has "other" users: the operator is a user, the tester is a user, other systems are users. A system is also composed of subsystems, which in turn are composed from components. Each subsystem and each component has a "user", which is usually another component.  This is an aspect of system construction that makes us realize the value of test driven development. We always design, and build, from a "user's" perspective. The test being our "user representative" at each stage of the process..

Another aspect of simplicity that makes it very hard, is distinguishing simplicity from simple-mindedness. It is very easy to propose and implement simplistic solutions that will be "easy", but not really simple, they would simply fail to achieve the objectives of the system. That  is also a subtle topic and needs further investigation. The other ten rules are self-explanatory and should not be very hard to live with.

On Simplicity - A Starting Point

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.