Wisdom Of Insecurity

After using and reading a number of papers on methodologies, the FearFactor? appears to be one of the most, if not the most, important factors.

Like AlistairCockburn outlines in his MethodologySpace paper, fears drive the method.

There is a good book on the subject called WisdomOfInsecurity (dated 1951!).[1]

As the author puts it:

I have always been fascinated by the law of reversed effort. Sometimes I call it the "backward law". When you try to stay on the surface of the water, you sink; but when you try to sink you float. When you hold your breath you lose it - which immediately calls to mind an ancient and much neglected saying, "Whosoever would save his soul shall lose it."

This book is an exploration of this law in relation to man's quest for psychological security, and to his efforts to find spiritual and intellectual certainty in religion and philosophy. It is written in the conviction that no theme could be more appropriate in a time when human life seems to be so peculiarly insecure and uncertain. It maintains that this insecurity is the result of trying to be secure, and that, contrariwise, salvation and sanity consist in the most radical recognition that we have no way of saving ourselves.

It was Lao-tzu who declared that those who declared that those who justify themselves do not convince, that to know truth one must get rid of knowledge, and that nothing is more powerful and creative than emptiness - from which men shrink. Here, then, my aim is to show backwards-fashion that those essential realities of religion and metaphysic are vindicated in doing without them, and manifested in being destroyed.

Alan Watts

I am currently trying to design a new IT organisation for a company and at the end, all concepts are based on nothing - the great void. This is kind of Zen. Do all designers to go this way?

In other fields (like that of LearningOrganizations from PeterSenge), the same is seen. This is AwarenessAndSensibilities? which create AttitudesAndBeliefs? which in turn create SkillsAndCapabilities?. And the loop is closed. He calls that the DeepLearningCycle? being influenced by the ImplicateOrder? "KnowingWhatNeedsToHappen?", something to be connected with QualityWithoutaName and OrderOfNature...

-- PhilippeBack

Are things said in this section same as WhatYouResistPersists? -- dl

These days I find it profitable to think of SoftwareDevelopmentAsaCooperativeGame (see also what is being informally referred to as AlistairsScumTalk [2]). In truth (ha ha), there is nothing there except a bunch of colleagues collaborating to guess the shape of this thing, the software, and roll it somehow across some finish line. All that is there are the colleagues talking together and writing code. The way you work is whatever you cook up - is this the Void you refer to? -- AlistairCockburn

To some degree, I think you just have to stop thinking and go out there and do it. You can read an awful lot of books about methodology -- even one of the very few good ones -- and still know nothing more than when you started about how to actually do anything. The way you learn whether or not a methodology is any good or not is to go out there and use it and find out. Look backwards from time to time and try to figure out what worked and what didn't. And don't think too hard about the parts you don't understand. If you don't understand it, the most likely cause is that there's nothing there but air. The second most likely cause is that you do not have a context to understand it, and for that you'll just have to wait. The least likely cause is that you are incapable of understanding it, but there are very few of these things that a developer can't understand (except human interactions, the neurons for which are lacking in many of us). I think a lot of the reason that people get away with so much air is that we are all so secretly afraid that we're the only one who doesn't get it that nobody is willing to stand up and say, "Um, I don't get it. Can you please explain it again?"

AlistairCockburn, I don't mean you -- your writing style is very understandable to me. But if I don't understand you, I hope I'll have the courage to say "Um, I don't get it."

-- WayneConrad

I think that I am doing it. I mean coding is something I do for years. In fact, my search for a (light) methodology is due to a real need, the need to have people communicate easily and deliver. In a project, I ended up with a row of binders full of design notes taken while I was designing, coding, even things I wrote before going to sleep. This was clear to me and my close developers. This was not that clear to the newcomers... But to capture the design, follow the progress, monitor the risks and the like, I was in need of something (especially when monitoring 5 to 7 projects at the same time). That was when I discovered OMT, UML, Patterns, Refactoring and... Wiki. And then AlistairCockburn's papers. That's why I enjoy Alistair's papers (CrystalClearMethodology, MethodologySpace, UseCases). They are ThingsThatWork? and in real life. I am not mapping my work to the techniques. They help me to shape my experience in a (more or less) structured way, so I can put them to use.

By the way, one thing I learned is to ask when I do not get it :-).

Indeed there is an awful lot of books on methodologies. And I agree that there is much air in there. Nevertheless, things like Catalysis are quite interesting to read to get some techniques out. Perform is not that bad (from CapGemini?) in some aspects. My way of working is trying to cover the various areas depicted by Alistair in his Big-M view. And doing it in the simplest way possible. That means KeepItLightAsPossible?. That where I see big value in XP for example. Ah yes, I also distribute copies of the Manifesto to managers and developers. I do the same with the 7 principles of Alistair.

About the void I refer to, yes somehow it fits with what you say, Alistair. After all, what matters is being happy and I noticed a great happiness growing in me when designing/writing software. There is no big reason for that. I just like it very much.

-- PhilippeBack

Re-reading what I wrote, boy, I sound pretty grumpy. Didn't mean it quite like that, to imply that you weren't doing these things. I think the references to Alan Watts really got me thinking that you were doing more belly button contemplation than I'm comfortable with, but that's not really such a bad thing. What I am really reacting to is an overdose of bad methodologies over the past few years, and your comment seemed to open the floodgate of grumpy commentary.

-- WayneConrad

I don't take it as grumpy. "And don't think too hard about the parts you don't understand. If you don't understand it, the most likely cause is that there's nothing there but air. The second most likely cause is that you do not have a context to understand it, and for that you'll just have to wait." is actually the way I feel about it, too, having been a full-time professional in it for 8-12 years now. In fact, I'm just writing an article (which I hope will get accepted in the proper Software Engineering community) in which that is my major comment, that there is "something there" that we haven't learned to articulate. It is "people". We have no words to describe what "people" is on projects. And that screws up our speaking about projects.

Also, the moment-to-moment microprocess on a project is too complicated and too individual to document or attempt to follow. It means that people are improvising all the time... and that is right, as far as I am concerned. Hence the Void, the not-knowingness that comes from looking up in confusion after having just read the dozen best-selling methodology books on the market.

Perhaps I should start studying how people teach Jazz. I know they teach it, and I know you can't do it without doing it. -- AlistairCockburn

AlistairCockburn, you made it: People. People is key. I got burned heavily to have not taken this into account. I was fired. And then thought to myself "Why? What do I have to do to create such a context? What is the lesson to learn?". I consider that I am responsible for what happens to me, in the sense that I do not try to find a ScapeGoat or someone else to blame. I learned also that the process to go through to reach an objective is more important than the objective in itself (especially when you have to do another project with the same people after!). At one time I found myself being a quite good coder, knowing nice tricks and techniques, but I felt myself like an empty shell. I had things, but I was nothing inside. This is when I moved my view of the world from "the goal is reaching objectives" to "the goal is to evolve into a network of relationships and communicate with others". An ever-changing world instead of a set of fixed shapes.

Wayne, about belly button contemplation, I consider that some questions over mankind are quite interesting to read and the Watt's prose was a big change in the way I saw things at that time.

About Jazz, yes, jazz is very interesting in that respect. Something like a project... starts ad-hoc, ends up 'in order'... Does a project "sounds good" may then be some kind of metric?

-- PhilippeBack