26 March 05 - 15:32A definition of risk
I'm thinking about risk management quite a bit these days. What is risk ? Webster's says "the possibility of a loss".
That is extremely vague, but it points in the right direction. "Possible" serves as a reminder that risk is about future events. What is in the past is not a possibility - it's a certainty; something has or has not happened. "Possibility" also puts us close to "probability" - future events are uncertain, and that uncertainty can sometimes be dealt with in statistical terms.
Not all risks have causes in the future; we may be at risk as a consequence of something we are doing now - for instance, smoking two packs a day. The future consequences of risk are uncertain, but the causes can be in the present and well known. In fact, most risk stems from predictable causes - it is the outcomes (the "loss" part of the dictionary definition) that are uncertain, and often (unpleasantly) surprising. The smoker knows that the cancer sticks will kill him - he doesn't know
when, and who knows what might happen before that. That's the difference between risk and self-destruction.
Not all risks are related to undesirable outcomes. That is what the term "loss" suggests and it may be the common case, but there are exceptions. What is in principle desirable may turn out to be a risk; for instance, a vendor of a new product may run a risk that the product will be so popular that demand will vastly outstrip production, leaving the vendor unable to satisfy its public and destroying its reputation. (Apple regularly faces problems of this type, for instance.)
Finally, consider the possibility of being ticketed for some minor traffic offence - that has some significant probability if you live in a city, and paying a ticket fine is undesirable, but the amount of a ticket fine is small enough compared to our incomes or financial reserves that many of us probably don't regard it as a risk, but merely an annoyance. By comparison, the amounts involved in a lawsuit (say, if your driving kills someone) do count as a risk.
The definition of risk that I offer is therefore as follows: "Risk consists of future consequences, arising from present causes or foreseeable events, which - if they materalize - will exceed our normal capacities for coping."
What do you think ?
- Management -
-
§ ¶
25 March 05 - 00:48Code it twice
Have you ever lost a significant chunk of code to carelessness or accident, and had to rewrite it from scratch ?
Earlier this year, I conducted an informal survey of my colleagues on the french XP mailing list. (A biased sample - this post is in part to continue the survey with a slightly larger sample.) The consensus seems to be that when that happens,
- Rewriting the code takes much less time than the first time around
- Rewriting the code is a lot easier than the first time around
- The rewritten code is better factored, more readable than that lost
Consensus is very strong on the first two points, less so on the last.
I've been wondering what to make of this regularity. It has to mean something, but what ?
I suspect that whenever we code something, we also learn something, and that repetition might reinforce the learning.
I'm wondering if people who do "up front design" (by which I mean something like work out the problem, algorithm, and so on on paper, then code more or less mechanically from their design) have similar or differing experiences.
I'm wondering, too, what might happen if we made a systematic habit of throwing away our first attempt at coding any given chunk of functionality, and made a habit of only committing rewrites to CVS. Would the increased quality offset the drop in productivity ?
I suspect that most programmers would respond with strong negative feelings to the suggestion of deliberately throwing away code - perhaps an impassioned reaction, more than a reasoned one. How would
you react ?
Some of us, I suppose, have more frequent opportunities to write the same code over and over. The
Dojo is where I'm finding my own opportunities for multi-coding. I suppose there are others - teachers, trainers, people who demo frameworks or APIs, I don't know who else... If you know something about it, please email me or comment here.
- Software Development -
-
§ ¶
23 March 05 - 15:03Wear the White Belt
No matter how adept you are with the guitar already, wearing the white belt here means you have agreed to set aside all knowledge and preconceptions and open your mind to learning as though for the first time. [...] Students here receive one belt and one belt only: the white belt. Those who put in the time, training, and effort will find their belt getting so soiled that eventually it turns black of its own accord.
A small quote from the excellent
Zen Guitar by Philip Toshio Sudo. It's all I can do to refrain from quoting more, in fact I could quote nearly the whole book.
Ostensibly about playing guitar, Sudo's small but dense book conveys an approach to learning and life, permeated with much more pragmatism and down-to-earth feeling for the topic than the title suggests. It fits perfectly alongside George Leonard's
Mastery as a reflection on what we gain from learning anything, be it guitar, martial arts, or programming. There's also a
Web site.
- The Universe And Everything -
-
§ ¶
21 March 05 - 00:17Design is intent - not
Bob Martin started an interesting discussion back on comp.object, on one common rebuttal to the idea that "
the source code is the design". The rebuttal runs along the lines of, "design is intent, whereas code is implementation". (This seems to be the same distinction as "what vs how".)
The etymologies of "intent" and "design" are fairly transparent; "intent" is from "intendere (arcum)", to aim as with a bow; "design" has as one of its roots "signare", to make a mark.
This suggests that designs are the visible traces of our intentions - code certainly fits that definition, but no more so than other things. (And design is
not intent.)
If I go back to the image of "aiming an arrow", which underlies "intent", I observe that I'm always aiming an arrow
at something. Once I fire the arrow, presumably what interests me is whether I
hit whatever I was aiming at ?
Isn't that where "design" comes into play ? If I'm smart enough, I can come up with the idea of firing ahead of where I see my target rather than directly at it, so that the target catches up with my arrow. Taking the etymology quite literally, if I'm aiming at a moving target, I can draw a line in the sand at where my arrow is currently pointing, and prolong that line in my mind's eye.
That line in the sand is "design". It might have value, for instance in adjusting our aim for the next arrow. It might also have value in adjusting our aim
before we fire the arrow - visualizing the arrow's path helps us decide that we won't in fact hit the target.
If I go back to programming with that thought, what I get is that the code is the design, and the UML is the design, and the scribbles on the back of envelopes are the design. Design is by-product. Some by-products we keep around, because they let us improve our aim.
What people mean by THE design seems to be something else. It seems to be something more permanent, more "essential" than a by-product. I don't see what that is, and in this discussion neither "intent" nor "design" seem to be casting any better light on what it is.
I suspect, but don't know for sure, that what matters is identifying the target (a.k.a. "requirements") and that what people mean by THE design - that permanent essence, which cannot possibly be the code - is an illusion, something they think must exist but actually doesn't.
I suspect, not that code is rather like design - but that designs are rather like code, a mere matter of implementation.
- Software Development -
-
§ ¶
10 March 05 - 17:42Agile Education in Jeopardy
There's one important limiting factor to the level of quality that the software industry can be expected to provide, and that is the quality of education given to people entering the industry.
There exist "traditional" approaches to the instruction of present and future software developers in the skills of their trade. My own degree in "computer science" is from one such traditional institution, but I obtained it through an
untraditional process: in recognition for professional experience. I'm largely an autodidact, and I think for a reason - the traditional approach is not very well suited to the nature of software development. That is why I've been interested in "alternative" approaches to teaching software development, such as Richard Gabriel's
Master of Fine Arts in software. I also like to keep tabs on individual teachers who have a different "take" on teaching software development, as
Eugene does, and I've started an education initiative of my own, the
Coder's Dojo.
I have been dismayed lately to hear about the demise, or impending demise, of several such initiatives. Some seem to be due to purely financial causes: apparently the Arizona State University "
Software Factory" (unfortunate name, but interesting approach) will be closing its doors for lack of "a business model that provides high enough return to the university".
More alarming, the
SDA (Software Development Apprenticeship) program at New Mexico Highlands University seems in danger of being shut down even though, as far as I can tell, it makes sense in both pedagogical and financial terms. NMHU students have few other opportunities like SDA available to them locally; the program has been a critical career opportunity for a number of them. Pam Rostal, a friend and an instructor in the program, characterizes the reasons cited to terminate the program as "unfathomable". She has chronicled some of the events surrounding the termination in her
SDA blog.
How can you help ? Writing an email to the President of NMHU (at
president_office@nmhu.edu) will provide an indication of support for the SDA program in the industry at large. Writing to the
Governor of New Mexico or the university's
Board of Regents would also help. If you do, please copy
the SDA people (softwareApprentice@nmhu.edu) on your correspondence.
- Software Development -
-
§ ¶
01 March 05 - 18:57[grid::retrospectives] Questions and stories
So, here I am in sunny Phoenix, Arizona, sitting in wonder among the participants at the 4th annual
Retrospective Facilitator's Gathering (that Wiki is empty right now, but will soon be filling up).
Esther Derby is here, among other friends and colleagues who blog. She's suggested starting a gridblog on retrospectives - and I found myself with a few minutes before lunch...
The first "official" session of the Gathering, which is run as an Open Space conference, was convened by Linda Rising and was about one of the questions that form the structure of the retrospective inquiry - "What puzzles us". Further notes on that session later, but I had one thought during the session that I want to record here.
The "puzzles" question is important, it directs the attention of participants at a retrospective to aspects of their project that they might not consider under the headings "What worked well" and "What to do differently". We spent some time examining what makes for useful, powerful questions, and what role asking questions plays in eliciting and maybe resolving puzzles.
A retrospective is about telling the story of the project. The thought that struck me was - once you start telling a story, the story generates questions; "what happened next", "why did this person do that", "what did you see at that moment", and so on. But in an important sense the questions generate the story - drawing people's attention to things that you ask questions about is how the story comes into being.
There's a parlor game that involves asking someone to step out of the room, while someone in the group describes a dream she's had. Then when the person comes back into the room, he asks yes-or-no questions about the dream, in order to piece together the story. The trick to the game is this: there's no actual dreamer - what the group does is the following: if the inquirer asks a question such that the last letter of the last word in the question is in the first half of the alphabet, the group answers "Yes". If the letter is in the latter half of the alphabet, the group answers "No". What happens is that the inquirer "invents" the dream himself through the questions he asks...
When I say that the story creates the questions and the questions create the story, I mean it in that sense - although of course in the case of a project there's "real" events that happened. But to what extent the story remains "invented" or "shaped" by the questions we facilitators ask is... an interesting question.
- Management -
-
§ ¶
