31 May 07 - 13:23Nil nisi bonum

"Nil nisi bonum" is the abbreviated form of a Latin saying, sometimes translated as: "Do not speak badly of those who are dead".

The funny thing is that this translation is itself a violation of a broader "nil nisi bonum" principle, which could be stated as: "focus on the positive". The Latin saying is perhaps better translated as: "Speak kindly of the dead (or not at all)". The parenthetical clause is redundant, we can leave it out altogether.

"Speak kindly" is a lot more efficient than "do not speak badly". There are many ways one could speak of the dead, other than badly: with indifference; in detail; in outline; in prose, in poetry; and so on. This is true of more than just dead people. In general, the things we don't like, don't want, won't tolerate vastly outnumber the things we do like, do want, do find acceptable. To enumerate them all would be a huge waste of time. And to name, for instance, only one thing we don't like - that is just getting started on the enumeration.

So, we communicate more efficiently by saying what we like, what we want, what we prefer, how we'd change things for the better, and so on.

I've been given this advice before by several people, in different forms. For instance, in a conversation with a friend about where I wanted my consulting career to lead, I'd started one explanation with something like "I don't want to be an employee, I really don't like the situation this puts me in", and so on. The reply was "What is it that you *do* want ?" Early on I resisted this advice. To me it smacked of "positive thinking", that is, a mostly motivational thing, like a manager announcing a layoff by saying "the good news is that we'll manage to keep a few people on".

After a while and some practice, it did start to sink in. The point is not to be "positive", as in always all nice and happy, rather to be "constructive", even when a situation is clearly bad. In the previous paragraph the manager's statement is positive, but also besides the point. The positive statements I'd want to hear in such a situation are things like: "Here is how we plan to do right by those of you who are going to be fired."

In discussing a software design, you might come out with a first statement: "I don't like this design." Better, more effective, is to say "This and that is wrong with this design." Better still is to say "I can see where you're coming from with this design, and it does solve the stated problem; we can make it more abstract by renaming this bit, more encapsulated by moving that method, more cohesive by segregating these few classes in a separate cluster." Or more briefly: "Yah, that will do the job, only make it more MVC, y'know ?"

The disturbing thing is that it takes other people to listen to what you're saying and point out negative statements, then coax out of you a formulation that actually adds something to the conversation, that moves it forward. Without an observer I was quite unaware of the way I framed my observations and attempts at solutions. With some help it turns out to make a difference, in terms of being more effective at giving people critical feedback, finding solutions in sticky situations, and so on. And after a while you internalize the habit, and "catch" negative formulations before they're out. (Oh, so you censor yourself, you might ask; how can that be good. Well, no more so than if you have a habit of choosing your words carefully before speaking - of chewing a bit over the first thing that comes to your mind - a good thing, yes ?)

Listening is such a great habit in general. Listening to others, listening to yourself. More than a habit; more accurately, "listening" is an umbrella term for a whole array of techniques and models; a subdivision of an even larger umbrella term, "paying attention". Techniques that turn out to be very, very effective... and very, very hard to acquire. What makes them hard is that resolve is not enough. You can wake up in the morning, determined to listen more closely. To actually do it, though, you need specific techniques and models, and it's usually other people who provide them; if you could come up with them on your own, you already would have.

Perhaps that's more a statement about me than a general truth; there might be people who are better at introspection than I am, and who do "pull themselves by their own bootstraps" in this regard. Me, I get by with a little help from my friends... (You know who you are; thanks !)

- default - one comment / No trackbacks - § ¶

31 May 07 - 00:47The insurance point of view

For a long time I've been wondering if one could make a business of insuring software projects.

OK, I suppose you've stopped laughing now. Consider a few facts. When I was writing about the parallels between Terry Gilliam's Don Quichote and software project failures, I came across a particular type of insurance contract: what the movie industry calls a "completion bond", "completion insurance" or "completion guarantee".

Completion guarantees generally apply to independent productions, who arrange funding from various sources - banks, public funds, and so on. If the movie production runs into technical trouble, the insurer will pay out money as required to complete the film - or they will have to reimburse the funders if the movie can't be salvaged at all. Providing completion guarantees turn out to be a nosy business. The insurer will look at every aspect of the production, cast, crew, screenplay, location... They will also expect regular reports from the production showing how the movie is progressing against its schedule. The cost of a completion guarantee seems to be a few percent of the total budget, usually less than 5%.

If nothing else, transposing completion guarantees to software development makes for an interesting thought experiment. Like a software project, a movie rarely starts with extremely detailed specifications. The screenplay comes closest to a spec; but at a typical 100 pages in length, it is only a bare outline of all the detailed decisions that will be necessary for shooting - from costumes to camera angles to catering, and so on. And even though movie scripts are revised and revised before production starts (i.e. before a completion guarantor sees them), they are often revised quite a lot after, too.

So, suppose you are in the business of insuring software project completion. Your job is not to make sure the project's funding comes through: if the project's sponsors cut funding, you are off the hook. Your job is not to make sure the end users love the software: after all, a film can be completed and bomb in the box office. Your job is to see the project go live, providing any extra money necessary to make that happen: funding a protracted beta testing phase to work out the bugs, hiring replacement coders, analysts, or project managers if part of the team leaves, and so on. If the project can't go live, you have to reimburse the project sponsors.

The flip side of the coin is that you have extensive powers of oversight over the project. Of course you don't particularly want to be involved in the day-to-day management, or in any creative decisions; that's not your job either. Your job is to assess, before and during, how likely the project is to complete, given the team, the project manager, the process, the technology, and so on. Any decision about the overall plan is subject to your approval. You can see a rough specification - maybe a list of use cases or user stories would come close to the level of detail in a movie script. (A huge difference is that there are standard expectations and even a standard physical format for movie scripts ! No such thing in our profession.)

What would be the items of first importance on which you would base your decision to provide completion insurance, or decline to do so ?

My hunch is that some of the things we get excited about - TDD, UML, MDA - would barely be on your radar. I could be wrong, but I suppose two of the important things would be story and people. By "people" I mean the project manager, product owner, developers, testers... You'd want to see the CVs of the key people involved in keeping things moving. I'm fairly sure "story", in the sense of what the project is meant to achieve for the business, whether it seems to be a serious bid at creating business value, whether its sponsors are truly committed to its success, would also be a major factor. I'm less sure that details of method or process would be investigated in any great detail, though the overall strategy could make a difference.

This is not to say that TDD, and so on, aren't important. To you as one of the people on the team they may be very important. They may be some of the skills which have earned you the sort of reputation which makes guarantors go, "Oh, if this guy (or gal) is on the team, I'll sleep easier about this project."

Story and people first (I can't decide in what order), process a distant third and a broad outline of process at that; that's what I think I'd look at if my business was completion insurance for software projects. I could change my mind about that; the point is that taking this view is a good way to review what we think is important about running software projects. So, what do you think ? What would you look at ?

- default - six comments / No trackbacks - § ¶