Last week I was Japan speaking about responsibility-driven design as part of promoting the new Japanese translation of Object Design. I gave 5 talks in three days in Osaka and Tokyo. Before I started my speaking tour, I was treated to a day of sightseeing in Kyoto accompanied by Taku Fujii, the lead translator, of my book.
I remember once wearing my mic to the bathroom. When I returned everyone knew where I had been. It was hard enough for my co-presenter to not fall on the floor laughing, let alone the 60 people attending the seminar. I had to jokingly apologize to my audience for sharing too much before we could go on with the rest of the day.
We all make mistakes.
Last week the Agile 2007 conference registration system made a big mistake. Everyone got an acceptance or rejection letter intended for someone else. Within 24 hours personal apologies had been sent out via email to people who had mentioned this snafu, and the correct notices were sent. Big embarrassing mistake handled rather nicely. Or so I thought.
But today I (and a few hundred other submitters) received an official apology letter from the conference meeting planners explaining in gory detail the technical reasons for the original glitch, how they had dutifully tested the fix before sending out the acceptance and rejection letters, and that the conference registration system folks were sorry for any confusion this had caused.
Hm. A second apology. What was with that? Stop dwelling on being so sorry.
But wait. It gets worse. The apology was sent via a list service configured to transmit all mail it received to the members of the list. So a few auto-reply out of town emails and grumpy complaints were forwarded, too. Followed by queries about how to stop the emails and replies to those queries. (At this point I was laughing, but not sending any email to the list!) These were then followed by two more apologies: one from the list maintainer and another from the chair of the Agile Alliance who put a stop to the chatter.
I get it. You are sorry. I’m sorry that you were so sorry and felt the need to give more information information. But next time I’m hoping that the volunteer conference organizers take an agile apology approach (I’ve learned this over my many years of being involved in conferences with my inevitable mistakes and recoveries). If someone complains, they deserve a personal response. But one apology is enough. And you don’t have to explain why a goof up occurred, just how it is being fixed (if that’s possible).
Agile apologies please! And for you complainers to the list: lighten up. Everyone makes mistakes.
One of my all time favorite books is Studs Terkel’s Working. In it, he captured people talking about what they do and how they feel about it. People tell amazing stories about hard work. The book is about, “ulcers as well as accidents, about shouting matches as well as fistfights, about nervous breakdowns as well as kicking the dog around.” I hope you don’t find software development so grim (I don’t ). But maybe you have an intriguing story to tell.
OOPSLA is soliciting Practitioner Reports. The submission deadline is just a short time away–March 19th. If you submit a report and it is accepted, Ralph Johnson or one on his committee will help you tell your story. There are many more interesting stories to be told and if you have one, please consider telling it at OOPSLA. Last year there was a really great story about how software objects finally made it to space in a JPL satellite through the persistence of a guy who really, really believed in the benefits of oo programming. A grad student at Portland State presented his experience exploring Traits–when he was an undergrad. I remember another report where a developer recounted his use of refactoring tools to write transformation rules to transmogrify a massive Smalltalk legacy application’s database access layer. And I recall another telling how a framework for scientific applications evolved. There are always interesting stories to tell; and OOPSLA is a place where you can tell them, whether they be about your latest adventures with web services, domain-driven design, aspects, agile or open source development, or the challenges of developing applications in distributed teams.
Last week for two days at the Kennedy School in Portland 100 people discussed agile software development at the Agile Open Northwest conference. Open spaces don’t have a set agenda; instead people propose topics around which they have a passion. That’s the beauty of an open space— the agenda is formed on the spot. We’re talking, not just listening. Conversations and sharing are key. I enjoyed Dale Emery’s session where he led us in reading Dr. Seuss’ Green Eggs and Ham and we discussed how to overcome resistence. I learned about the role of games and simulations in training and had fun playing a couple. Thanks Elisabeth! And I felt the pain in a session where we discussed how to sort out differences of opinion on a dev team.
Open spaces aren’t just someone talking and everyone else listening (although some sessions were more one-sided exchanges of information than others). The place was abuzz with conversation. As one of the hosts for the event, I was nervous about whether enough people would show up and whether they’d have enough to talk about for two days. I shouldn’t have worried. People were engaged, excited, rejuvenated, and happy but tired at the end.
Is there a secret sauce that makes an open space work? Probably no one factor is “the secret”, but there seem to be several key ingredients. First, the open space needs to be “open”. People need to be encouraged and empowered to take responsibility to make the conference what they want it to be. There is a structure into which open conversations can be fitted. At the beginning, attendees propose topics and session times which are posted on a big schedule board. People are encouraged to get what they want out of any session. It’s perfectly OK to vote with your feet and leave a session to attend another, or to flit from one to another. It’s OK to sit out and just hang out for a while (I got tired and needed a break on that second afternoon). And throughout the conference new sessions were proposed and times reshuffled.
A good facilitator is invaluable in setting the tone and expectations. Diana Larson, another conference co-host, convened the open space and ran the daily news and closing. She was fabulous. It helps if the open space has a theme or burning question to explore. For us, it was “Agile for real.” Originally, we thought it should be posed as a question. But we left it as a statement that could be interpreted as a challenge— what does it take for agile practices to really work. Get real.
A comfortable location helps. The Kennedy School had a funky charm that is hard to match in a convention center or hotel. Coffee, tea, and bottled water were available throughout the day. Breakfast, lunch and dinner were included so people didn’t have to break their stride to find nourishment. Finally (and this was really nice), there was wireless and computers were provided so people could record their session notes on the conference wiki or check on email.
While the face-to-face discussions are over, things that came out of the open space continue. The Portland XP group is being revived; an open space is being planned for the bay area; the next generation of testing frameworks is kicking off serious discussions… It may be over, but stay tuned for Agile Open Northwest 2008. This was too good to be a one time event.
I wanted to let folks know about the upcoming Agile Open Northwest Conference January 30 and 31 at the Kennedy School in Portland, Oregon. As one of the conference co-hosts, I’d like to invite you to come and converse with 100 other eager folks on agile development practices, pitfalls, problems, and challenges.
When we started creating an open space conference last fall, we didn’t know whether any one would show up. Well that’s not been a problem. So far, over 80 have signed up. Space is filling up fast. We’re limited to 100 due to the size and space restrictions at the Kennedy School.
If you aren’t familiar with how an open space works, it may seem like an unstructured event, but in actual fact it is highly structured–only that structuring happens at the conference. During the welcoming/opening of the conference, attendees are invited to post a topic they’d like to discuss. Each one and a half hour session will have the opportunity for several concurrent topics being discussed. Each day the “scheduled set of topics” can be rearranged–when new items are of interest, they get posted on the visible schedule (which is created at the conference).
Given the mix of attendees, I expect quite a range of topics to be discussed, ranging from how to manage distributed teams, to how design fits in, how certain tools support agile development, how testing and q/a fit in, how to effectively engage customers and collect reqts, etc., etc. But this is all speculation on my part because the people who attend will post topics they wish to discuss.
One highlight of our conference will be a Co-Evolution Picnic, co-hosted by the Eclipse Foundation. Ward Cunningham will launch this progressive conversation on the future of tools and methods in a participatory panel format called a “goldfish bowl”.
I look forware to meeting you there!
I’ve posted a copy of my Agile 2006 tutorial slides and notes for Skills for the Agile Designer on my website’s resources page. The tutorial was organized into skills for seeing problems, seeing and shaping solutions, and working in collaboration. In addition to introducing problem framing as a technique for identifying what questions to ask of your customer, I presented several ways for seeing and shaping your design. The last part of the tutorial covered some “soft” skills: how to recognize false arguments, handle design criticism, and how adjust to different design rhythms. So, if you want to know a bit more about red herrings, proof by ignorance, false dichotomies, shifting the goals posts, democratic fallacies, or the companion in guilt move, check out my tutorial notes.
A designer, especially one in an agile team, has to be a good communicator. Part of being a good communicator means knowing how to tell a sound from an unsound argument, and then knowing techniques for countering certain arguments. By the way, argumentation isn’t the same as shouting or having a fight. When I’m talking about argumentation, I’m talking about having a discussion on some topic. I must caution you that while recognizing faulty reasoning in illogical arguments can be useful, it isn’t always easy to counteract.
For example, changing what is being argued for in mid-debate or “shifting the goalposts” is a common argument move to avoid criticism. As soon as an arguer sees a position becoming untenable, he or she shifts the point of discussion to a related, but more easily defended one (think how a stereotypical politician never directly answers the question you ask but answers tangentially…and you understand what it means to blatantly shift the goalposts). Most co-workers aren’t so blatant. But having reasoned discussions with someone who habitually shifts goalposts may not be easy. The best you can do is politely but insistently point out their shift, once you spot it, then try to steer the conversation back to the original topic.
Knowing the names of common argument moves comes in handy. Personally, it has helped me slightly detach during the heat of a discussion (in order to think just a bit before reacting). This has been a good thing. Instead of diving into debate or getting sidetracked or frustrated by faulty reasoning I can spot it for what it is and then try to reel in the conversation if possible.
During the tutorial I presented an example of a companion in guilt move, how a teenager might point out to a parent their inconsistency in how they apply the rules: “If Joe gets to do such and such, then why can’t I?” At this point, an attendee raised his hand and said, “How did you know that my name is Joe?” That brought down the house. After the tutorial I had a long conversation with Joe who thanked me for my presentation and said that dealing people effectively on an agile team was the hard stuff. New technology and tools are easily learned, but being aware (and knowing how to effectively work with your mates in spite of their biases and or backgrounds) requires daily diligence. Thanks, Joe. I enjoyed our conversation.
I’m home for 2 weeks after spending a week at San Diego at OOPSLA and last week teaching object design. It is good to be home as I can now configure my new tablet PC and start using it. It’s bad to be home as it is raining too hard and spoiling my plans for getting my perennial garden in shape for the winter. But truth be told, the rain leaves me hunkered down inside, forcing me to write, to reflect, and start new projects.
OOPSLA this year was full of creative types: George Platts led a number of workshops and experiences; Robert Hass, past poet-laureate of the USA, gave the keynote. This was no surprise with Dick Gabriel as program chair. Dick is a man of many talents. In addition to his heavy-duty computer side—having made Lisp implementations practical being one of Dick’s early accomplishments—he is a published poet, musician, patterns instigator, Sun fellow, and scholar. A highlight for me was getting Dick to autograph his new book of poetry Drive On and then to read it on the plane ride home.
Sunday morning I attended the tutorial, “How has the arts, sports or life stimulated, inspired and informed your work in computer science?” led by George Platts. George is an artist and game master who is a well known creativity/fun instigator at software pattern conferences. As it was a Sunday morning tutorial, I expected George to drive (and me to sit and quietly soak up his words). Silly me. After showing us an incredible film of an amazing panoply of pyrotechnics, mechanical feats, oozing chemical reactions crafted to produce a Rube Goldberg-like perpetual motion machine, we sat down to discuss how art or sports stimulated or inspired our work.
Two thoughts struck me about how arts and sports have stimulated my work. In college I fenced (with a foil—don’t ever call it a sword). Much preparation went into a competition. We repeatedly practiced standard moves (all with Italian names). Only after much practice with attacks and counter-attack moves would we do practice competitions. Being a left hander gave me a distinct advantage as my body was not where it was expected to be. Lefties fencing lefties are on equal footing as we, too, are accustomed to fencing right handers. So even while I was at an advantage (being short makes for a smaller target and being a lefty makes for an unusual target) during the heat of a competition I’d forget much and just go on raw instinct. Only when moves and countermoves become kinetic memory do you get really good. I never got good as I spent too much time getting my programs to work instead of devoting energy to perfecting my fencing technique.
Bringing up this notion of practice led us to discuss what constitutes “practice” or “repetition of scales” for software developers. What do you developers or designers or analysts do over and over and over again until it becomes second nature and makes them good at what they do? Programming? Applying design patterns? Writing use cases? Learning how to ask probing questions? Well maybe. I’m not sure we software types have a clear equivalent of scales. Does repeatedly programming yet another JSP make you a better at it? Building consistency into your design makes your design better. But does it make you a better designer?
A second artful inspiration I’ve had is from Betty Edwards, author of Drawing on the Artist Within. Betty has inspired me as a teacher of design in how I try to break down design ideas and thinking for others. Betty claims that people are crappy artists because they don’t know how to see, and that by learning special ways of seeing, most of us could be able to become passable renderers of what we see. She believes everyone can be taught how to draw likenesses of what they see. I had a really bad pottery teacher in college who asked us to “feel what was in the clay and then create”. I was frustrated and created lumpy awkward pots because I lacked technique and this instructor didn’t teach any technique. As a teacher of software design I don’t like it when my students create lumpy malformed objects. I teach them a number of techniques for seeing good formations of objects—role stereotypes, a smattering of patterns, the notion of domain entities and value objects from Eric Evans’ writing, a sense of control style choices. But sometimes these ways of seeing don’t click in and my students create strange designs. Or worse yet they get frustrated and just want to know what steps to go through to create passable designs; to heck with all this technique. All I can say is that design takes practice and reflection and technique. I don’t know how to teach design as a rote process.
As a result of George’s tutorial, I got to know Henry Barager of Instantiated Software Inc. Besides being a skilled software architect, Henry’s a whiz at cryptic crosswords. Over lunch one day at OOPSLA Henry taught me about cryptic crosswords by working through one with me (Henry did most of the work but he patiently let me solve a few entries after explaining the basic idea). The key to solving a cryptic crossword entry is to figure out how to separate the word or word phrase you are solving for from the encrypting part. Then there are clues in the encrypting instructions part which may lead you to take some letters and jumble them (key words may imply that you create an anagram, wrap one word inside another, truncate a word, etc.) or not. For example: Flower came up. The answer is Rose. Rose is a flower, and “came up” is another meaning for rose. Simple, right? Well try this: Piece of technology in broken device tossed out. Give up? It is evicted (tossed out = evicted, that’s the definition. The rest of the encrypting part is this: A piece of technology is the “t”, broken device is “evice d”, device jumbled or broken).
Explaining the idea behind cryptic crosswords is fairly simple. Solving entries takes a lot of effort and getting your brain in a problem solving frame of mind. Solving them in real time as Henry does requires skill, experience, and intelligence. Teaching others how to solve them takes another kind of skill. The same goes for object design. Learning object concepts is trivial. Crafting simplistic solutions is, too. Putting together elegant designs that work for complex problems is much harder. It requires practices, reflection, as well as learning techniques from masters who shouldn’t try to solve all the hard problems for you. I wish I’d had someone who would’ve demonstrated and helped me practice good technique when I was learning to shape pottery or to draw. I was fortunate to rub shoulders with some very bright Smalltalk folks when I was learning how to think in objects. Thanks to all the folks at Tektronix and Instantiations for teaching me how to see and build object designs.
I don’t think of myself as an â€œelderâ€. But that is what Linda Rising, who led the 20th OOPSLA retrospective, labeled those who were at the first OOPSLA. I am one of five who received a perfect attendance ribbon (Allen Wirfs-Brock, Brian Foote, Ralph Johnson and Ed Gehringer are the others) for having attended all OOPSLAs. At the very first OOPSLA I felt like an outsider. I wondered how I could get involved with this conference. Excitement was in the air. Objects were the next big idea. Just exactly what could I do that would have an impact? My paper on Color Smalltalk was rejected (the reviewers’ commented that it talked too much about hardware details) so I presented it as a poster. It was good that they rejected it. Our work was premature. Three years later, when Tektronix Color Smalltalk was finally a product, I wrote a paper about the design principles and class libraries in Color Smalltalk that was accepted. This success made me believe in my writing abilityand led to my paper with Brian Wilkerson on Responsibility-Driven Design in 1990, and launched my enduring interest in design.
Thursday I had another elder moment. I was on a panel with Ed Yourdon, Larry Constantine, Grady Booch, Kent Beck, and Brian Henderson-Sellers that looked back at echoes of the past and structured design and into the future. Larry Constantine provoked us to bring theory, technique and transparent tools into all we do. Kent brought the house down by quoting from Structured Design. He noted that while Ed and Larry got a lot right, they missed out on the fact that systems need to change. Refactoring wasn’t part of Ed and Larry’s vocabulary. Ed, who has been an expert witness on software cases for the past few years, noted that there often isn’t even a shred of a plan or design or any documentation for software systems. Grady mentioned that increasing abstractions have been a big factor and challenged us to move to even further levels of abstraction. More down to earth, I spoke about how objects enabled me to think clearly, and that the power of abstraction, encapsulation, and thinking in terms of small neighborhoods of collaborating, responsible objects as a big step forward. What’s next? To me, it seems that even more effective methods and practices, powerful development and testing environments, expressive languages, patterns, and thinking tools are in our future. Innovation in our industry is a constant. Yet every once in a while it is good to reflect on what we got right and remember influences from the past. But I’m forward looking too. After every OOPSLA I come home charged with new ideas and the urge to do more, collaborate, and continue learning. What a blast!