Lifelong Learning

Design By Contract in Java, Great Software, and Sloganeering CTOs

In the not too distant past, I was tasked to research and try to make concrete a corporate CTO's vision of software engineers adopting DBC, which the CTO seemed to passionately believe in. The company uses Java as the primary platform, with a great deal of C++ (in reality C) in legacy code. Since most of the literature on DBC is in Eiffel, part of the task was to attempt to find implementations and approaches suitable for Java. I was part of a Java platform group, so I did not concern myself much with C and C++.

DBC is a little bit of a strange animal. Once you learn it and see its power, you become passionate about it. But adopting it and making it part of your daily practices is an altogether a different ball game - if your language, development environment, and production environment don't support DBC, as the case is with Eiffel. I will try to explain this in as few words as possible. I hope it will come through.

The essence of DBC is, of course, Design and Contracts - that much should be glaringly obvious from the D and the C in the acronym. Being able to write contracts for a class, or methods of a class, helps you design it. That is the main theme. You design by writing contracts. DBC is a design methodology.  The contracts are not the end. They are the means to better design. More robust (more reliable and less error prone) design is really the goal. Higher quality software, in other words, is the ultimate goal.

The process of writing contracts is deceptively simple: for a method, specify the preconditions under which it is legal to call the method, specify the postconditions that must hold after the method returns, and specify conditions that must hold all the time for the class (invariants).  This is much easier said than done - simply because programmers don't think that way. Mathematicians think that way. Programmers seek the goal of a working program - not a provably correct program. They hope to achieve correctness and reliability by demonstrating them through testing.  Many of the goals of DBC can be achieved by testing. Testing is complementary, not contradictory, to the goals of DBC. It is just a different process and a different mental model.

An example should illustrate. Lets take the Stack class. We all have an intuitive feel for what a stack should do and what rules of behavior it must exhibit. We can have a mental model of a stack of dishes in a restaurant implemented via a spring-loaded mechanism inside a cylinder. A stack starts out empty. You push one dish on it, then a second dish, then a third, up to its capacity -say 20 dishes. Then the physical mechanism will not allow more dishes to be stacked on top. When you need a dish, only the one on top is physically reachable. So you reach and pop one dish off the top, the dish below it, pushed up by the spring, then becomes the top of the stack ready for another pop. Once the stack is empty, it is physically impossible to try to pop a dish. There aren't any available on top and this is obvious by inspection.

A software stack is similar, except since it is a conceptual construct first, and then a software construct second, we don't have available to us the physical things we take for granted with a real-life object. So an implementer of the stack has an intuitive feel for needing a push(), a pop(), and is-empty(), and is-full() operations. He also has the intuition that you cannot pop an empty stack and you cannot push onto a full stack. He implements the push and the pop, and tests anything that is likely to fail - and moves on to bigger things. Because, in the course of a programming day, there are many more tasks much more difficult, complex, and demanding than a stack.

Using DBC to specify, even before thinking about implementations, is where the challenge of DBC lies. We need a specification that defines contracts so that the specification is complete and allows the implementer to provide a robust implementation - without constraining the implementation.

The thought process for specifying a stack with DBC goes something like this: I need a push(), and pop() operations for the stack to be useful - that much is obvious from the needed functionality perspective.

Now we need some contracts. Some are obvious: lets say we have a count and a capacity attributes. A class invariant is that  count >= 0 and count <= capacity. This holds for all instances, at all times. For push(), a precondition is that stack be not full (i.e. count < capacity). Simple enough. A precondition says that it is illegal to call push() when the the stack is full (at capacity). The word illegal means that the push operation will be prevented from being called. It will not ever be allowed to be called, with invalid preconditions. It should be quite clear that the push() method itself cannot be the one checking on the precondition, because if the precondition is false, it will not be called.  We will get back to this point when we examine the issue of the sloganeering CTO a little further on. In the contract specification for push(), we simply note the pre-condition that stack must not be full - in the understanding that this is a directive to the environment not to allow a method to be called when its precondition is false. That is the meaning of "illegal".

Now we have to think about the post-condition. Writing post-conditions is hard because you must specify the future state of the class as a result of the execution of the method. That is not always easy to specify. It is at a level of difficulty equal to writing the implementation. That is why I think many Java programmers are  unlikely to use DBC. For the push operation, the post-conditions are that the new top of the stack must contain the item just pushed, and the item that was previously at the top, must now be the item second from the top. You see now that the notions of "previously at" requires the examination of the state just prior to the execution of the method, and comparing it with the state just after the execution. The mechanism for specifying postconditions must have an expression language that has that notion. Eiffel has the "old" keyword for that purpose, which Java, of course, does not.  Now the issue of making assertions about the position of the item below the current top gets into a discussion of how much about the "internals" of the stack do we expose. Debate is likely to flare up that we cannot be examining positions of items, because the stack model is concerned only with the item on top, or is it? This is what writing postconditions leads to - a healthy debate about the essence of the class - what is internal, what is visible. Again, I don't think many Java programmers will take to that kind of thinking. It will slow their coding down.

Now consider the post-conditions for the pop operation. The pop operation must return the item that was on top, and the item that was below it must become the current top. So the notion of what is currently on top, what previously was on top, and what was below top, all have to find expressions in the expression language and the queries on the state of the class. This is again easier done with tests than with writing pre-conditions. But now you are back to mixing specification with implementation, which Java programmers do all the time, as they circle through test code and implementation code. They "do" the contracts through tests, instead of specifying them. Two problems with that: 1) the tests are not part of the specification, so they are likely not to be read. There is no expectation that the tests constitute part of the specification. That is too much of an overloading of their function. 2). tests make assertions on implementations, so each implementation must have its own set of tests - which greatly increases the workload of writing assertions to assess quality and completeness of specifications. These are serious problems - serious but subtle and likely to be missed and dismissed.

My thoughts at the end of my research phase was to try to address all these difficulties in bringing DBC to the world of Java. As seen from the above discussion there were many issues, many of them at the heart of Java best practices. How will we get Java programmers to specify before they implement? How do we capture specifications so that the implementer is still free to choose the implementation? How do we implement the notion that "it is illegal" to call a method when its pre-condition is false? Clearly this is a role for the runtime environment - contract checking must be done in the environment, not in the code. But we cannot change the Java compiler (not yet). We can however, enhance the runtime environment, by, say AOP. We can add aspects that check contracts. We can fine tune contract checking by providing runtime attributes to the contract checking aspects. Allowing contracts to be specified in interfaces and checkable through aspects will provide the best of possible worlds for the Java developer.  The expression language for writing contracts can be provided by simple annotations. There are several Java open source implementations that provide exactly that mechanism of enabling DBC in Java. The task was simply one of education and raising awareness about DBC as a best  practice. We would have to show how DBC is complementary to other best practices, like Test First, or Test Driven.

Back to the sloganeering CTO. I had a session with our CTO, who was now sloganeering about "Outrageously Great Software", an obvious, and unabashed rip-off of Steve Jobs's "Insanely Great" software. I wanted to discuss how the two slogans are, in fact, almost one and the same. DBC allows us very high quality software that meets its stated specifications, and great software is software that meets its specifications, does not fail, and delights its customers. Very closely aligned goals. Half an hour into the meeting with the CTO, who has cultivated the image of being almost a god at the company, he proceeded to tell me that outrageously great was anything like the iPhone. I thought, oh, all we have to do is worship Steve Jobs here and our practices are blessed. Ok, not too bad. But I need a little bit more specificity and concreteness. We all know how wonderful iPhone is, but what exactly are the engineering practices that will lead us to that engineering nirvana? The CTO proceed to expound on DBC. All you have to do, he advised, is "assert out early". Huh? He proceeded to then show me a 10,000 line C file (which he asserted was C++). It had one function after the other, just checking its parameters for being zero or null. Essentially he had boiled down DBC to, "if not pre-condition, then error". That is it. All the issues that I went over about the design process for coming up with pre-conditions, post-conditions, and invariants are not addressed. The issue of how contract checking is done, and by whom, is simply disposed of by making each function just check its parameters, and "assert out early". Nothing about post-conditions, and the need to reason at least about the state the object is left in, and how it relates to the previous state before the execution of the method. The notion of a contract was reduced to function parameters being not null. The anticipated design process that would have lead to a healthy reasoning and debate about what features a class should have, what features it should expose, and why simply vanished. The greatest benefit of DBC, the design methodology, was dismissed for the benefit of "assert out early". Pretty damned stunning trivialization of a very promising design method - coming from a CTO. I was actually hoping to instill an "interface driven design" methodology, through DBC. Where engineers focused on interfaces and minimzed talk about implementation. This would have the benefit of improving communcation among all the stakeholders of a development effort. If everyone focused on interfaces with their clients, then developers can make businss clients focus on clarity of interfaces, i.e., better business requirements, testers would make their clients, the developers, focus on interfaces, and their tests. I.e. everyone would know his contracts, and everyone is clear on his client's expectations. There is much, much more to DBC than "assert out early"!

The stunning part about this experience for me, is that the CTO then reported to my management, who are under him, that "Nabil does not get it". To his mind, I did not get DBC, because I thought it was more than "assert out early", and it required more at design time, more at implementation time, and more at runtime. He also declared that "AOP was not ready for production use yet" at our company.

I hope none of you have similar experiences, or work for sloganeering CTOs. My biggest sadness from this story, is that we were prevented from achieving great software, by a leader who preached great software, but never did articulate what you needed to do to achieve it - actually articulated a caricature of what was needed, and dismissed serious efforts at a meaningful translation of vapid sloagans into reality.  Of course, he moved on to another company, where his slogans now sound fresh and inspiring. It is a lot easier to talk like Steve Jobs. It is much harder to achieve what Steve Jobs does achieve, through real inspiration of what his engineers do.
    

Learning a Second Language - What Does it Take?

According to Robert J. Blake, in Brave New Digital Classroom

"SLA (second language acquisition), the process of learning another language other than your mother tongue (L1), is both an intensive and time-consuming activity.  After years of experience in training field agents, the Foreign Service Institute (FSI) estimates that anywhere from 700 to 1,320 hours of full-time instruction are needed to reach a level of high fluency.  More specifically, the time committment for learning a Romance language minimally approaches 20 weeks of intensive, full-time study at 30 hours per week, for a grand total of 600 hours, while for other languages, such as Russian and Chinese, the ideal exposure can exceed 44 weeks at 30 hours per week, or 1,320 hours. In stark contrast to these calculations, most university students spend on average only 150 hours per academic year actively studying a second language (10 weeks at 5 hours per week for three quarters = 150 total hourse). Upon graduation from college, students of whatever second language just barely reach the FSI's lowest threshold requirements for achieving proficiency, that of the Romance languages. For students studying a non-Romance language at the university level, four years of second language study are not sufficient to obtain functional proficiency."

Now I know, why after 2.5 years of studying Spanish on my own, through CDs and Internet, and some travel, I still can't understand CNN en Español, movies, and telenovelas! Over the 2.5 years, I have barely accumulated 300 hours. I still need another 300 hours to achieve fluency. That's both disappointing and comforting. I now know where I am, and what I need to do to get where I want to be. But hopefully, the second 300 hours will not take another 2.5 years. Maybe 150 days, six months, or at most a year.

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.

Asking for LinkedIn Endorsment

There is a good way and not so good a way to ask for a LinkedIn endorsement. The obvious, and not so good way, is to simply shoot out an email requesting the endorsement, with the prepared text from LinkedIn.

A much more effective way is to do two things (both, not one or the other):

1. Write an endorsement first. Give before you take.  If you know the person well enough to request an endorsement, then you know them well enough to write an endorsement for them. If you're not sure how to write an endorsement, read my post on Writing a LinkedIn Endorsement.

2. Help the person in the writing task - particularly if the relationship is not recent, and you've worked with the person years ago. Even if the relationship is recent or current, you want the endorsement to focus on some things and to de-emphasize other things, and you want it to be either general, suitable for many purposes, or specific, suitable for a specific purpose that is important to you at this time. You don't have to write your  own endorsement, but help the writer get started. It is always easier to revise  than to write from scratch - the dreaded blank page. So send your friend a basic skeleton of the endorsement you're looking for along the following lines:

    Can you endorse me? I am thinking of running for President of the USA (or maybe something slightly less ambitious, like I am making the transition to academia as professor of computer science), and I think it would help me if you can say a few words about my abilities and qualities relevant to that kind of position.

     As you know, we worked together on projects, x, y, and z, and we collaborated on tasks a, b, and c.  We have worked together for X years on the XXX team.  While on the XXX team I accomplished this, that, and the other, and I was instrumental in achieving xxxx and yyyy that contributed to the success of the team.

The above is similar to writing a resume paragraph. List the work and your accomplishments for that period.

Your friend, if she knows you well, and agrees with the basic facts of your narrative, will then have enough to go on and add her bit by describing your general and specific qualities:

       Xxx is a gentelman and a scholar. He's more intelligent than Einstein,  a better writer than Hemingway, and a better technical innovator than Steve Jobs, etc., etc.

These two rules should help when you are asked for an endorsement. What you should respond with, if you find that it is hard for one reason or another, to respond quickly, is to simply send the link to this post! You can then add, "I observe Nabil's Rules for LinkedIn Endorsements".  First, endorse me, and I'll be happy to return the favor. Second, send me a skeleton, along the lines Nabil suggests, to get me started.  You may find that you won't have to write that endorsement after all.  This response, in many cases, would make people just go away. There are people who are so averse to writing that they will not write that endorsement for you. Many people just want to take, they don't want to give. Sad but true.

Writing a LinkedIn Endorsement

Seems like a few people have a block when it comes to writing a paragraph or two to endorse a friend on LinkedIn. I guess there may be some psychological forces at play here, but I don't want to venture into pop psychology. I will approach this as a writing task that some seem to fear.

Of course, engineers are notorious for their hatred of "documentation". And here they are asked to "document" their opinion of a colleague and publish it to a small audience of 16 million people, and have it attached to their profile.

First, a very simple principle. Honesty is of the utmost importance. It must be avoided at all costs (as Linda Radnor says - not sure of her name - Vegas comedian ). Not really. Your endorsement must be honest, factual, and accurate. But there is some subtlety to be noted here. Feelings intrude! You may say to yourself: he's a good professional, but I don't like him! He is blah, blah and not blah, blah. Last year he did blah and said blah, blah which upset me.

That's where professionalism comes in.You can work with someone as professionals. You don't have to like them to endorse them! You are a professional, that's the meaning of professionalism. You just write a factual review documenting how you knew the person. You don't need to get into personal feelings and relationship issues.

Ok. Now that we got the "honesty" issue out of the way, how do we proceed? Isn't it amazing, many of us develop supremely complex products, write thousands of lines of code, and produce prodigious architecture and design documents, yet we freeze when it comes to this simple task of endorsing a colleague.

Here is a proposed, simple method:

1. Get the facts down. How do you know this person? How long have you known him/her? In what capacity? What projects did you work on together? What where his contributions? What were his good qualities (ignore bad qualities and bad situations or confrontations - not relevant to the task at hand). So here you have the basic facts. Just the facts, Ma'am!:

I have known Zultan for X years. We worked together on Blibity Blip project and Blobity Blop framework. Zultan brought knowledge of blips, blops, and frombozing to the team. His knowledge of blips and blops, and frombozing was amazing. He is the most knowledgeable person I have met in this area. In addition to knowing about blips and blops, Zultan has extensive experience in weaving blips into blops, bla bla. Facts, facts, projects, tasks. This should be a simple matter of making a list. A list you can abstract from.

2. Write about general abilities, and general team/collaboration characteristics: intelligence, hard work, problem solving ability, perceptiveness, ability to quickly narrow down options, etc. etc. Collabortion, sharing knowledge, helpfulness to others, jumping in, etc. Attributes you have noticed that Zultan shines in. Try to suppress your thoughts that sometimes he can be an ass, or a know-it-all, or whatever other negatives! Leave all negatives out. You can think them, and even have them in your draft. But they stay out of the endorsement, and they don't stop you from completing it. Again, you don't have to love the person, or even like them, as long as you respect, value, and can honestly endorse their work and work-related personal attributes. Stay professional.

3. Write a general endorsing blurb, that does endorse, and not leave the write up in a wishy-washy non committal place. "I would love to work with Hephzebah again". "It would be a pleasure to work with her again". Resist the negative thoughts about, "I never want to work with this ... again, if I can help it".

If you still find you have a block, go back to college and take a course on remedial English - you are hopeless. An easier course of action would be to call your colleague and politely say, "sorry, can't do this, my grandmother died , our entire neighborhood does not have electricity, or my camel is having a baby - or any other equally lame excuse you can muster to hide the fact that you can't write a paragraph! Another, equally lame thing to do, is to resort to an "endorsement generator". Yes, you can write an endorsement with one click, followed by Ctrl-C, Ctrl-V. Google that.

My rule of etiquette for LinkedIn endorsements is to return the favor in under 24 hours. I try to do it within hours, of receiving the notice. If someone endorses you, and you don't return the favor, you are rude. If they ask you explicitly for an endorsement, and you ignore them for days, or weeks, then you are beyond rude. You clearly don't want the person to be in your contacts list. The honest thing to do is to remove them and break off the connection. I remove people like that from my contacts list. That's the LinkeIn acid test. If someone won't give you an endorsement when you ask for it, what point is there in having them as a contact?

Writing for Programmers

Many programmers don't like to write. They think of it as the dreaded "documentation". They just want to write code. But what is writing code? It is a form of writing. I maintain that good programmers are good writers. The problem is that writing that is not coding does not appeal to them. But if you approach a writing task like you do a programming task, you'll notice a definite rise in the quality of your writing (to match the quality of your code). I am sure you'll challenge someone to the death if they dare imply that your code is not the greatest!

So what ideas can we bring to writing from the world of programming?

1. Test Driven Writing. If your coding can be test driven, why not "test drive" your writing? The "unit"
test for a written paragraph is your eyes and ears. Does it sound right? Does it look write? The "acceptance" test for a written piece, is someone else's eyes and ears.

2. Refactoring. You develop code by successive little refactorings till you are pleased with it, have removed all the redundancies, and "it works". Why not "refactor" your writing until "it works"? Look at your sentences and paragraphs and ask, "does this smell right"? In refactoring we go by "code smells". We have a catalog of things that "smell bad", and we attempt to remove them. Do the same with your English prose. Writers have practiced refactoring for centuries. They call it "editing".

If you're a fan of pair programming, there is a parallel there too. But if you're a solo developer, you'll be a solo writer also.So we'll leave pairing aside.

Some resources that can help with the writing task:

- BUGS in writing, A Guide to Debugging Your Prose. A delightful book by Lyn Dupre.

Follows the theme that writing may contain bugs, just like coding. Her main premise is, "the simplest way to improve your writing is to learn to avoid a limited set of common errors". Her main intent, as she states in a "Read Me" (instead of a Forward!), is "My intention is to convey to you the basic principles of good writing, and thus help you to develop ear ....". That is a key skill, "Ear" - a sensitivity to what good prose sounds like. Not different from detecting bad smells in code. The author develops a series of examples and presents them in a BUGS system: Bad, Ugly, Good, and Splendid. A Bad construction contains obvious mistakes and would be embarrassing. An Ugly construction is technically correct, but is not acceptable for one reason or other - well, it is just ugly. A Good construction is acceptable and correct, and would be fine - but you will want to do better. A Splendid construction demonstrates an improvement over a given good solution. The author's contention is that, "once you have developed ear, you will be able to tell without hesitation what constitutes correct syntax, style, and semantics, and will be equipped to communicate effectively with your fellow humans".

- Technically - Write! By Ron S. Blicq.

Good manual for technical writing. A little dated by now, but still a very helpful guide to technical writing with focus, brevity, and clarity. It goes over various forms of technical writing (technical correspondence, informal reports, formal reports, technical description, scientific papers, technical papers, etc.). It has a good section on technical speaking (briefing, papers, meetings, etc.).

- Line by Line - How to Edit Your Own Writing. By Claire Cook.

A good manual on editing.

- The Elements of Style, William Strunk, and E.B. White.

Strunk and White is the granddaddy of style manuals. A masterpiece of concise writing itself. A little book that is a must have, if you're serious about your writing.

Writing to Learn

Writing is a great way to learn (whatever subject you're interested in), and of course, to learn to write well. I used to do a lot of "private writing" and just tuck it away in the file system. I don't have much patience with the editorial and publishing process. Blogging gives me a chance to resurrect what otherwise would be dead pieces. And there is no editorial process!

I highly recommend writing-to-learn, the process, even if you don't blog, or publish. I recommend William Zinsser's book of the same title. Even if you don' blog, try "private writing". It sharpens your knowledge, sharpens your thinking, and you'll have a ready inventory of writings, should you decide later to blog or publish.

Nonsense

Nonsense. Red Herrings, Straw men, and Sacred Cows: How We Abuse Logic in Our Everyday Language. By Robert J. Gula.

From the forward to the book: "Robert John Gula had a relatively short life of forty-seven years. But he wrote or co-wrote seventeen books ranging from Mythology: Greek and Roman to Precision: A Reference Handbook for Writers., and taught Latin, Greek, algebra, geometry, chemistry, English composition, and logic at the Groton School, one of the best secondary schools in America."

Bob Gula described why he wrote Nonsense, a handbook of verbal logic. "Nonsense came about because of my frustration in seeing how people, even highly intelligent people, are often simply unable to communicate when in a group. Having seen many meetings and discussions that floundered, I began to wonder why. That wonder led to a course on informal logic, and that course led to Nonsense."

Nonsense was intended to be the best compilation and study of verbal logical fallacies available anywhere, and it is that and more. On one level, it is a handbook of ways that people deceive themselves and others. On another level, it is a short course in nonmathematical logical thinking, a form of thinking that all of us use and often abuse everyday.

Great little book!

Lateral Thinking

Many of Edward De Bono's ideas are a natural fit with the customer-focused, consultative approach.

Check out lateral thinking (as opposed to linear, or vertical thinking).