Do What You Say Say What You Do

Just some quotes (though I do not have the exact sources of them, can anybody help?)

The best way to predict the future is to give a promise and then to carry it out. (Hannah Arendt)

(compared to "The best way to predict the future is to invent it." (AlanKay) )

To say what you do and to do what you say. (motto of Lionel Jospin)

"Do what you say, say what you do" is a common one sentence formulation of ISO9000 (IsoNineThousand)

I would also submit that "Do What You Say, Say What You Do" is the central benefit of well-executed XP. Business and management have honest, reasonable expectations (contrast the usual tendency of IT, especially consultants, to promise the world in a hundred days and then, inevitably, fail to deliver). Likewise, development has reasonable and understandable direction from business and management, rather than vague intentions and unreasonable demands.

I would like to add one more similar expression : Say What You Mean,Mean What You Say

See also: WikiPagesAboutSayWhatYouDo

I've recently been on a Let's look into this mode and so when I saw this page, I said to myself "Self, How do I get to the point of saying anything?" I then reflected upon Let's look into this, and said to myself, "Self, You look into what you hear others say before you make it your own saying". That is to say, you "Test" what is said. You put your investigative hat on (which ever that is (WhiteHat?), and to satisfy yourself with the truth or substance of what was said, so that when you say it, you will have more than just anothers word for it. That takes care of the saying part of the page title, now what about the "Do" part? In the simplest form, doing is repeating. Repeating a procedure, method or action that you most generally have "Done" before. But most often your doing is not the repeating by rote of some behavior or series of actions using the same resources and applying them to the same object. The object changes, the series of actions for one object never perfectly fits another, so you must change them. You become aware of how these changes are received and adapt either the method, or the object, or both.

Apply this to some saying and some doing you are presently involved in. Does this make sense? Can one ever really Do what they say and say what they do, until it is done? This is particularly applicable to new things, unproven and adapted actions. It seems that before you can SayWhatYouDo?, you must do something first. In other words: DoSomething?, If it works, RememberWhatYouDid?, if you find that you have done it three times or more, then you might get to the point of being able to Say what you have done. It is only then that DoWhatYouSaySayWhatYouDo can become a pattern for you and others to incorporate in their Doing and Saying.

One of the most often repeated errors of new methodologists is overspecifying a procedure. That is, describing what they believe in good faith to be good practice, with too many steps and constraints. This generates procedures that are very hard to follow and are thus abandoned unless an auditor visit is approaching. In extreme cases, these procedures can hinder the team ability to provide good service to customers to the point that a complete quality initiative had to be scrapped for the survival of the company (I have seen this, but I am not at liberty to provide specifics).

Thus I agree with what's in the section above: You must first do and remember what you do (which works) and then say what you do. The problem is that most projects are different, so people do different things. Coming up with a general description of what is done will lead you to: - An incomplete process description - An overly restrictive process description - A process description with many conditionals and optional things

Of these, the first one is probably the best to put in practice, but will be regarded as poor by an ISO 9000 auditor or CMMI appraiser. The second is the one that leads to lots of ProcessCynicism, that is doing things for the process' sake as opposed to the product or customer's sake. The third one would require a huge investment in process definition, not practical in most situations.