Rebecca's Blog

Round the world in 28 days

2008-06-15T21:49:00.000-07:00

I've just returned from four weeks travel to Athens, The Netherlands, Australia (Brisbane and Sydney), and Las Vegas. It is good to be home in Sherwood sleeping in my own bed. This trip was a combination of vacation, work, and geeky holiday. I and spoke at three different conferences in three weeks. JAOO Brisbane and Sydney was an opportunity to hear Erik Meijer give a great talk about why fundamentalist functional programming languages (think Haskell) solve the problems we procedural and oo language programmers just sweep under the rug. And then I got to grill Erik on why he thinks that declaring types to include side effects so important to writing good programs. Where else does a geeky woman get to hang out and talk shop with other software geeks? I snuck in some sight seeing too. The picture is of me taking rental bike across the Brisbane Harbor on a ferry. A bike ride with Dave Thomas and Kresten Thorup was about the only sunny day we had in Brisbane. The rains came to Australia just in time for JAOO.

In Greece I saw lots of ruins, attended the annual IEEE Software planning meeting, and ate lots of Greek salads, simply prepared fish, and drink thick coffee. They call it Greek coffee, but a few years ago even the Greeks called it Turkish coffee. But one highlight I won't forget is hearing Linda Rising and her husband Karl sing "Take me out to the Ball Game" at the ampitheater at Epidaurus, Greece. They volunteered to demonstrate the phenomenal acoustics. It gave me goose bumps. Constructed in 500 BCE, the ampitheater perfectly amplifies sound from on stage to everywhere in the theater. You can whisper stage center and people in the back row can hear you perfectly. And sound is amplified back to you, too. Truly an engineering marvel, the acoustics are because of the location and how the ampitheater was carved into the rocky hillside.

I'll be sliding back into a more normal work routine, but before the magic of this wonderfult trip fades, I hope to share some thoughts and reflections and experiences over the next few days.

Lessons Learned from Architecture Reviews

2008-04-20T10:18:00.000-07:00

Last year I talked about lessons learned from architecture reviews at JAOO 2007 and Markus Voelter from Software Engineering radio interviewed me. You can listen to our conversation.

I've experienced both sides of reviewing. Early in my engineering career I presented the design of a universal linker to an external reviewer. I was scared to death that the reviewer would pick apart my design. I was relieved when my design was blessed, but annoyed when the reviewer doubted my ability to deliver on time. (I delivered, but in hindsight I could see why he and my management doubted me--as a new engineer I was working solo on a critical project...I just didn't know what I couldn't do).

These days, complex IT systems are rarely understood by a single engineer or architect. Teams come together to create complex software systems. Technical challenges can be enormous and the "tricky bits" involve the subtle interplay of business and technical design decisions. The focus is on achieving overall business objectives, not the optimal design of a single component. Yet poorly designed interfaces, sluggishly performing services, or crappily constructed components can cause enormous grief. Design still matters.

A Conversation with Dan and Allen

2008-02-19T17:39:00.000-08:00

I highly recommend this podcast interview with Dan Ingalls and Allen Wirfs-Brock (yep, we're related) on Microsoft’s Channel 9. Dan was one of the pioneers who coded the first implementation of Smalltalk at Xerox Parc…and gave us overlapping graphics windows, bitblt (that’s pronounced bit-blit) and interpreted self-supporting reflective systems that let creative types tinker with and improve upon systems while they are still running. Although Dan and Allen were involved in dynamic languages back in the early days, they still are powerful innovators and thought leaders. Dan currently works at Sun Labs where he’s brought to life the Lively Kernel. Allen is involved in programming languages at Microsoft. While Allen states that JavaScript isn’t anybody’s favorite language, if you take Dick Gabriel’s approach that worse is better, even though it isn’t a pretty language it can be a platform for innovative programming environments for distributed web-based applications.

Agile Open Northwest 2008

2008-02-19T16:55:00.000-08:00

Last year we held an open space in Portland at the Kennedy School focused around the theme, “Agile for real.” The response was so positive that we’re picking up the conversation again at the Seattle convention center March 18 and 19. I’m happy to get to renew connections with folks I met last year and excited to meet some new folks and hear their agile experiences. Attendance is limited to 100. Registration is filling fast. We’ve kept the price low ($100) so that even if your company can’t afford to send you, you might still attend. Most who’ve registered so far are from Seattle, but this is a northwest regional conference. So expect a few of us from Portland and elsewhere in the northwest to show up, too. And maybe even some folks from further away. We hope to see you there!

Challenges When Communicating Designs

2007-11-02T19:05:00.000-07:00

Tuesday evening I gave a talk about the challenges software developers face when communicating design ideas. I started by making the connection between telling others about designs and storytelling. Effective designers need to tell good stories. And the tone and means by which we communicate design ideas should vary depending on the reasons we have for telling a particular story, and our audience's background and expectations. Perhaps we need to educate newcomers or explain our design to get constructive feedback. Maybe we want to convince others to take some specific action or “buy in” to change. Regardless of motive, we need to communicate about our designs in compelling and engaging ways.

At the beginning of my talk I asked attendees to write down their most challenging communication problem. I figured it was a fair exchange: I’d get direct feedback from about their problems, and two lucky attendees would walk away a book. Looking over their feedback, I’d categorize them as

Communicating to others who are not like me
“Communicating across domains (UI design to SW) or cultures (US to India)”
“The hardest communication was when I had to present a design to a group that does not specialize in my area.”
“As an embedded software engineer, the rest of my team are hardware engineers so they have neither the training in software methods nor the software mindset.”
“Communicating technical design to non-technical people.”
“Communicating to a non technical customer.”

Getting others to appreciate the important bits
“One of the most challenging aspects of communicating a design is educating the receiver of the design on design paradigms. This is especially true when the person is not familiar with or comfortable with object oriented design/analysis.”
“As a developer working in an agile environment, I often receive partially-conceived designs, sometimes as little as a single Photoshop mock-up. It’s easy to spot short comings, but difficult to communicate them. I sometimes end up implementing a feature just to illustrate its problems.”
“I sometimes have trouble getting others to understand why a simple solution is insufficient when the other person has very limited time to understand the problem.”
“To clearly point out the subtleties and nuances of the most critical or pivotal aspects of the design—what’s really important.”

Gaining common understanding
“Vocabulary/definitions”
“Definitions [that] are not the same for the same term.”
“Just getting to a mutual understanding of the idea has been an issue for me.”

Story telling mechanics
“Communicating at the right level. What can we assume, what needs to be explicit.”
“Knowing what to put down.”
“Keeping the explanation simple. Explaining only the parts which are needed. … Pulling your imagination into paper.”

Most designers could tell far more about their designs than they should. We also could benefit from practice telling coherent stories and ensuring that the important parts get emphasized. If you have insights on how to effectively communicate design ideas or design communications challenge you’d like to share, I’d love to hear from you. Over the past year or two I’ve been working on effective design communication.

I also want to announce that I’ve put together a new one-day course, The Art of Telling Your Design Story. I’ll be teaching it publicly at OGI’s Center for Professional Development in Beaverton, Oregon, November 30th. The day before I’m offering another new course, Practical UML (if I called it Impractical UML would anyone sign up?). Design stories don’t always need formal UML notations (in fact, one of the challenges is communicating subtle ideas to non-technical folks). ButI’ve seen UML so disabused that I want to give developers some straight talk on how to effectively communicate using UML at different levels of detail (and show some nuanced design ideas effectively).

Deconstructing Frankenstein

2007-10-16T18:04:00.001-07:00

One of my favorite things I do in any architecture or design course I teach is to discuss AntiPatterns—design ideas hatched with good intentions but that prove problematic over time. We’ve all seen examples of software done badly. The purpose of an AntiPattern is to document a bad solution to a common problem, explain how people can slide into an AntiPattern, and mention ways to remedy it. The point isn’t as much to say “don’t do this” as it is to say “you probably already have this problem, you just might not have a name for it. And here is how you might’ve gotten there, here is what you might do to prevent this happening in the future, and some things you might do to fix up your design.”

A Boat Anchor is a piece of software or hardware that serves no useful purpose on the current project. Often, the BoatAnchor is a costly acquisition, which makes the purchase even more ironic. A Lava Flow is when unused blobs of code are hanging around in a system. It is characterized by the lava-like “flows” of previous developmental versions strewn about the code landscape, but now hardened into a basalt-like, immovable, generally useless mass of code (perhaps commented out, perhaps not) which no one can remember much if anything about.

Last week students at my class were incredibly inventive—they weren’t content to limit their discussion to examples of AntiPatterns that I mentioned. The new AntiPattern names are so good I want to share some of them. The first was the Frankenstein AntiPattern. It came about because “too many cooks were watching the pot.” Everyone wanted to contribute so they did, just not in any organized fashion. As requirements kept rolling in, people kept adding functionality—in a disjointed, haphazard fashion. Oh, you want two eyes? OK. And a body. That sounds good. You didn’t say you need toes. Hm. OK, we’ll bolt some on. How many do you need? Where should they go? Everybody contributed, design coherence wasn’t a goal, and the implementation just kept rolling in requirements.

One might say that good disciplined designers should’ve detected this emerging porblem and prevented it from happening. Well, projects get hectic and sometimes things slide. But what’s nice about this story is that it has a happy ending. Frankenstein was banished after a diligent designer who couldn’t with a clear conscience keep bolting on stuff and make it work said “Enough!” and worked to untangle this mess. He employed several strategies. One was refusing to take code directly from marketing—and to accept requirements and functionality via pseudo code instead of “patches”.

Another AntiPattern that was brought up was Rocky Road. It’s similar to the Lava Flow, but includes overloaded data fields and cobbled together or interpreted data fields in the mix. Not only is there dead code to stub your toes on, but there’s complicated data with overloaded, tangled encodings, too. The intentions were good—keep using the same schema but add more functionality to the software and keep encoding data in complex ways because heaven knows the data can't be redesigned. But over time this system became extremely difficult to work with. The code was complex in that it had to decode and vary functionality based on complex interpretations of the data, and the data fields grew more complex and entangled in support of new functionally. Now what’s great about this AntiPattern name is that “Rocky Road” is an ice cream flavor as well as a travel hazard. What might start out as a sweet, quick fix, can over time turn into an unnavigable development landscape. I’ve seen this situation at other companies I’ve worked at… and there is no quick fix. Someone or several people have to take the time to analyze the code and the data implications and to propose modest “safe” and agreed upon modifications. These repairs don't usually smooth out all the bumps they keep the system from totally becoming unworkable. Usually there has to be a compelling reason to make deep and significant changes (think Y2K or migration to a new database technology).

Sometimes discussing AntiPatterns can be depressing. Especially when people work in places where painful examples are in abundance, and little opportunity or incentive exists to improve things. I like hearing stories where people have been able to repair design problems and improve how systems function. Even better when these efforts are supported and encouraged by informed management. If you have any AntiPattern remediation successes, I’d love to hear about them.

Notes from my Japan Book Tour

2007-09-17T19:38:00.000-07:00

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.

Taku-san was an extremely gracious host and I really enjoyed seeing the beautiful Kyoto gardens and temples in the gentle rain. In addition to speaking, we also had time to celebrate. Wednesday evening there was a small party in Tokyo with several translators, reviewers, and the editor-in-chief.

Over dinner, one of the reviewers remarked that responsibility was an especially difficult word to translate. "To respond to" is one meaning...but that simple translation would lose the important connotation of "having an obligation". Such are the subtlies of translation. Five translators worked for over a year to translate the book. They are very proud of their work (and I am very grateful). I hope it becomes a best seller in Japan. Thursday I delivered a keynote speech on Skills for World Class Designers at the UMTP Modeling Forum. After my talk nearly 50 stood in line to buy the book and have me autograph it. Sales are off to a good start.

Giving Design Advice

2007-06-28T18:18:00.000-07:00

In an ideal work environment software designers freely ask for and offer constructive criticism and openly discuss issues. They don’t take criticism as personal affronts, and they and their managers make intelligent, informed decisions.

OK, so how do design discussions play out where you work? In my latest IEEE Software design column I discuss some effective ways to give advice as well as hurdles you may have to overcome before your advice is heeded. Being an effective critic, advisor, and design colleague isn't purely a matter of being on top of your technical game. Cognitive biases affect how people naturally (and often illogically) receive and process information. They can have a big impact on how you your advice is received and interpreted. If you want to get better at communicating suggestions to others, you should become more aware of these biases and look for ways to mitigate or avoid them. Wikipedia has a good overview of cognitive biases in how people assess risk, make decisions, and rationalize them after the fact.

To whet your appetite for this topic I’ll mention one bias that has probably bitten every programmer at least once. A confirmation bias is when a person looks for what confirms a strongly held belief while ignoring or undervaluing contradictory evidence. Have you ever found yourself unable to isolate a software bug because you insisted that your software just couldn’t work that way? Your confirmation bias might have prevented you from noticing facts that would lead you more swiftly to identifying the bug’s root cause. I like the idea presented in Debugging by Thinking by Robert Charles Metzger that taking on the different mindset of a detective, mathematician, safety expert, psychologist (one of my personal favorites), computer scientist or engineer you can get a better slant on tracking down a bug. According to the author, “Each way has an analogy, a set of assumptions that forms a worldview, and a set of techniques associated with it.” In designing as well as debugging, having a variety of worldviews for tackling a problem helps you avoid getting stuck in a rut—and pick the right strategy based on the context. One way to get around a confirmation bias is to shake yourself out of “the normal way of doing business”.

Cognitive biases aren’t good or bad. They just are. And if you work with others it helps if you can identify biases that lead you (or others) to jump to conclusions, hold onto an idea when it should probably be discarded, or ignore risks. That knowledge can help you tune your message and become aware of and avoid bias traps.

Nuances

2007-05-17T12:16:00.000-07:00

Recently I met a developer who deeply knows his problem domain. Yet when his colleagues split hairs arguing about the behaviors of concrete and abstract classes, whether to craft an interface, or even how to give them meaningful names he’s confounded. He’s a smart guy. But the nuances that object geeks just love to roll around in drive him nuts. Where’s the hard and fast, proven concrete advice for using these techniques? Enough debate and theory already!

This reminds me of another developer who sent me a lengthy email a couple of years ago, asking whether I could shed light on how to decompose problems using “behaviors” instead of functional decomposition. He copied other lengthy emails from other experts and authors—I wasn’t the first he’d asked.

I was quite impressed by how thoughtful those experts’ responses were. But they didn’t help him learn how to do behavioral decomposition. Instead of seeking out nuanced differences between object responsibilities, actions, and behaviors and what made a design object-oriented or not, he should have been studying examples of different ways to decompose the same problem. Compare, contrast, then reflect. Seeking definitions and nuanced meanings was barking up the wrong tree! At the time, I wasn’t sure I wanted to be yet another in that long chain. So I didn’t answer his email.

But these two responses by smart people got me thinking. Nuanced discussions can be infuriating if you haven’t internalized any rules of thumb about when and why to do something. If you are the person in that spot, don’t let those discussions choke your curiosity or drive you crazy. Instead, I advise you to live a while with uncertainty about the distinctions between shaded meanings or the relative strengths and weaknesses of one technique over another. Don’t try to disambiguate by thinking about what others say. Instead if you can, experiment with different solutions to meaningful problems that you have, perhaps with the help of a thoughtful colleague or guide. Then reflect on what you thought was important. Let the nuances come to you after you’ve personally wrestled with distinctions and techniques for a while. And don’t expect experts or colleagues to share the same values, use words the same way, or make the same judgment calls (when this happens the world as we know it will end).

As to what behavior means in an object-oriented context? The short answer is: the same as it does in any other. But how people use language is incredibly sloppy.
Behavior is defined as “how someone behaves” (how’s that for a circular definition in the American Heritage Dictionary?) or, more usefully, “the actions or reactions of a person or animal in response to external or internal stimuli.” Replace person or animal with software object and that definition seems to fit pretty well. But behavior also means “the manner in which something functions or operates”— a more general characterization of how something functions in a particular context. So we can talk about behavior of a dying star, a frightened mouse, or a even software objects.

It's really Wong Design....

2007-04-19T09:15:00.000-07:00

This morning I received an email from a friend whose wife is Chinese. She says says that "Wrong" is not a Chinese word and suggest it is probably someone's last name.

Then I Googled "Wrong Design Hong Kong" and found a post on the Learning Cantonese blog about Wrong Design. The Chinese Characters are "Chit gai ji wong". "Chit Gai" means design, "Ji" is a connective , and the last character is "Wong" which means "Emperor" or sometimes "King". It's also a Chinese surname.

So the correct English translation of the name of this company should be "Wong Design" if the owner is named Mr. Wong, or "King of Design". Turns out that the owner (indeed a Mr. Wong) has a fine sense of humor as well as good Chinese business sense. He wrote to the blogger:

I took the name because I was disillusioned with all the rhetoric I see
everywhere, also because the Chinese name sounds like "wrong" ('Chit Gai Ji Wong' - 'King of Design'), and also just trying desperately not to be
serious. Business is booming.

So there you have it. A designer with a sense of humor and a love of word play. How wacky is that!

Wrong Design?!

2007-04-18T17:31:00.000-07:00

On our recent vacation to Korea, Japan, and Hong Kong we delighted in the awkwardly worded pseudo-english phrases on t-shirts, jackets, school notebooks, stationery …in fact my prize souvenirs are several school notebooks. One has a drawing of a telephone on the cover and this definition: 1. N-PLURAL: Communications are the systems and processes that are used to communicate or broadcast information, especially by means of electricity or radio waves.

Another has a weathered photo of a bag of peanuts and this saying:

Pleasure of life
It is time all day’s tiredness is relived…and space is full
of cozy relaxtion and a joy of my own.
The surroundings calm down in deep
silence.
And I enjoy my own time.

I took this photo in Hong Kong. Surely the name must be a cruel joke. I showed this photo to a friend who suggested the Chinese characters might be roughly translated as “design king” or “king of designers”. If you can confirm this or know better, let me know.

When someone shouts “Wrong design!” or “That won’t work” or or “Your design stinks!” he’s being judgmental. My latest IEEE design column, Handling Design Criticism, talks about how to filter out constructive criticisms from noise…and what it takes to really get behind people’s judgments, puffy praise, and aesthetic arguments to discover the real issues.

As I was writing my column, it occurred to me that it is as important to be skilled at effectively giving criticism as it is taking it. I’ve gotten better at this over the years. No longer do I write scathing reports or repeatedly restate my objections until I wear everyone down. Maybe I’ve mellowed with age, but I think it’s more than that. I’ve learned to point out issues in ways that aren’t so confrontational and to pick my battles. Hey, if I ask you leading questions so that you come to the same conclusion as I did without a confrontation, we can both be happy! It's not a sneaky tactic, really it's not. I’m not perfect giving constructive advice and I’d like to get even better. So I’m polling friends, family, and seeing how they manage to point out design flaws without waging battles or making enemies. If you have found clever ways to offer constructive design advice, drop me a line. I’d love to hear your story.

Agile Apologies

2007-04-12T18:35:00.000-07:00

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, one 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.

Working--share your experience

2007-02-20T18:44:00.000-08:00

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.

Agile Open Northwest was for real

2007-02-09T10:46:00.000-08:00

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.

Martin Fowler is no Kent Beck

2007-02-07T08:43:00.000-08:00

I know the difference between those two....When authors make mistakes, readers notice. In my latest IEEE Software Design Column, Driven...to Discovering Your Design Values, I quoted Martin Fowler as claiming that test-driven development,

“gives you this sense of keeping just one ball in the air at once, so you can concentrate on that ball properly and do a really good job with it.”

Kent quoted Martin in his book Test Driven Development by Example.
It gets a little tricky when you cite someone quoting someone else. Originally, I had the reference to the book in line with the quote attributed to Martin (but my citation only listed the book title, not the author). My editor moved that citation to the back of my article and undstandably filled in Martin as the author. Easy mistake to make and I didn't double check the references when it was refactored. I assumed my editor would fill in the author appropriately and double check citation.

My fault. You heard it from me first. When anything is refactored, whether it is code or citations or comments, you need to check twice. Since I don't have an xUnit tool to write tests for citations and quotations, this has to be by visual inspection. I'll know better next time. Thanks Mirko and Shinobu for caring enough to email me about this mistake.

Agile Open Northwest

2007-01-17T16:11:00.000-08:00

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!

ATM Activation Update

2006-09-29T17:10:00.000-07:00

I wanted report on what happened when I actually called up to activate my really new ATM card (in case anyone cares). I phoned up the number as the sticker on the card directed me to do and after I punched in my new card number I received a message stating, "This card is already activated" and then I got disconnected.

Hm. The call I made to activate my card when I mysteriously received a "replacement" card (not a new card with a new number) obviously went through--and the operator activated my new card (even though the number I gave her was for my old card). Hm. So my new card was already activated before I received it. Someone could've stolen it out of my mailbox and used it without having to answer all those pesky questions. I think I've uncovered a security issue with how the person on the phone handled my request.

For what its worth--its those special cases that'll get you everytime.

Barely good enough doesn't cut it

2006-09-29T16:26:00.000-07:00

About a year ago Scott Ambler wrote an article stating, “One of Agile Modeling's more controversial concepts is the dictum that models and documents should be just barely good enough." Scott characterized barely good enough models as having just enough accuracy, consistency and detail to remain understandable and provide value and pointed out that barely good enough is context dependent—what’s good enough for your situation may not be barely good enough for mine.

I don’t like the words, “just barely good enough”. Even after a year, those four little words stick in my craw. I don’t scrape by on barely good enough planning or preparation in other aspects of my life. So why should that be the mantra for my modeling, design or design documentation activities? As a thought experiment, where would you mark a point on the hypothetical value per effort curve below that marks what you consider “just barely good just enough” modeling or design? Now place another mark for where you’d like to be on that value per effort curve for your current project.

I don’t want my checking account to have just barely enough money or get just barely good enough sleep. After a few weeks I’d be a walking zombie or the meanest bitch on the planet. If I allotted barely enough time to get to the airport, sooner or later I’d miss a flight. Since my local movie theatre is just 6 minutes from my door on a good traffic day, I do allot just barely enough time. Most of the time I make it to the movies. (I’m quite willing to trade off having to occasionally go to a later show against sitting through those annoying pre-movie ads.)

In most aspects of my personal and professional life I make choices about how much planning, preparation and cushion or slack I need based on my preferences, style, and the consequences of failure. When things matter I take extra care. When they don’t, well…I’m as casual as the next person. But I prefer to think that I take adequate measures most of the time—adequate and good enough. Not just barely good enough. To me this subtle shift in attitude and outlook is huge. And an appropriate one for agile developers to take.

Barely good enough thinking can too easily be used as an excuse for taking the easier, inadequate way out. Sure, we can discuss what’s “barely good enough” but that missing the point—don’t we all want to do adequate, good work, and not do things that aren’t needed? Barely good enough thinking will always make us question whether we’ve done too much. And as a consequence, any design before coding is getting a bad rap.

I propose we get rid of that barely scraping by attitude and replace it with a healthier one. I propose we start using words like “enough”, “adequate”, or “meets the project’s needs” to describe how much design we do. Or perhaps “just enough” modeling as Susan Burk described in her Practical Process talk at SD Best Practices. These words are far less edgy. But that is a good thing. Without feeling desperate, I’m hopeful people can feel safe enough to start having meaningful conversation about what’s enough given their current situation.

Scott’s edgy phrase emphasizes the point that agilists’ strive to minimize unnecessary work. Design just in time. Do just enough. Don’t go overboard. Push towards minimizing if you’ve had a tendency to over design or document. But I say do an adequate job. Meet your objectives. Maybe you need to do even more designing than you have been doing. Nothing edgy about that message, just common sense.

The “just barely good enough” message can be a real turn off to teams who come from traditions of producing high-quality, high value designs. What? You mean to be agile I should turn away from what I find to be valuable? No, you don’t.

Adequate design means you may need to sort through options and gain enough understanding before you pound out much production code. You may even need to design and build a few prototypes to understand the problem before you launch into something. That’s OK if that's what you need to do. You can be agile without having to barely scrape by. In fact, conscientious developers know that and insist on taking whatever measures they need to build the right stuff.

I have known agile teams who feel guilty about taking any time to model and explore their design options. And they feel inadequate when they find it useful to write down a simple use case to clarify a story card. Good grief! Clarity is what we're after. Others feel not clever (or edgy enough) when they need to think about their problem or sketch out a potential design before writing tests or code. I say stop feeling guilty! If writing, thinking, and talking about your design with others helps you clarify your ideas—keep it up. Most people need to think a bit before they code.

If you want to keep permanent representations of key design or architectural views in addition to their code don’t feel guilty about that either. It just means that you find value in more than simply the working code. (If you don’t, then stop it!) The right kind of adequate design documentation can go a long ways in communicating key ideas to new team members, support and operations. Your code doesn’t always speak clearly to others about your design.

At Software Development Best Practices, Scott gave a talk on agile modeling where explained that barely good enough was the point where the value per effort is maximized. His point on his hypothetical curve is way higher than where I’d mark it. I’m betting your sense of what’s barely good enough differs from Scott’s view, too. I’d label Scott’s point as “optimal” and mark just barely good enough way to the left.

I’m not sure what an ideal value/effort distribution curve looks like, and I suspect a value per effort curve will vary by project type and organization. I’m skeptical that it looks anything like the curve Scott drew (Scott, doesn’t make any claims that he’s discovered a ideal shape for this curve—only that you should find the “barely good enough point” and not overdo design). Curious about various distribution curves and their properties, I took a look on wikipedia. Nothing seemed to fit my expectations. I would suspect that the value of design gradually tails off rather than steeply declines (on most projects). Have you found the value/effort for modeling to follow a normal distribution curve or some other known distribution function? Have you it to vary by project type? If so, in what ways? Do you find that value to decay at some point (after hitting some maximal value per effort point)? Or have you found it to remain steady or keep increasing at a slower rate? I’d be interested in your thoughts.

Really, we're just trying to help

2006-08-28T16:16:00.000-07:00

Last Thursday evening I called my bank to report my bank card had been lost. I answered a bunch of questions and the person said they'd mail me my new card within five to seven business days. Boy was I surprised when a new card showed up in next day's mail. The following day a new PIN code came in another letter. I called up to activate my new card and strangely, the person on the line asked me a whole lot of questions including one that I couldn't answer--what date did I open my account? I've had my bank account so long I didn't remember. After being placed on hold and asked a few more questions that I could answer, the person said my card had been activated. Boy this was excellent service!

Except it wasn't...Sunday the ATM refused my transaction with a cryptic "your card couldn't help us" message. Today I again tried my card (maybe I'm dense),with no luck. I went inside and told the teller my new card wouldn't work. She looked me up in the computer after checking my ATM card and my ID and said that this wasn't my new card, it was my old card. It had been reported lost or stolen so I couldn't use it. All I could do is sit tight and wait a few days for my new card.

What happened? Why did my card show up early? I think I've figured this out. The last time I used my bank card I'm guessing that I left it at the machine. Thinking they'd be helpful, I suspect my bank then initiated a process to send me a "replacement" card which with same card number as my swallowed card, but requiring a new PIN.

If I had held off phoning in my lost card for one more day, that mysterious "replacement" card would have shown up and I would've been set (after I received my new PIN code in another mail). But once I reported my card as lost that nixed my old card for good. Bummer.

I have some gripes my "replacement" card's arrival. There were no clues about why it was being sent. Secondly, a separate mail came a day later advising me of a new PIN code, again, without explanation.

I can see some analyst pondering what to when a card has been left at a machine. Did they test the replacement procedure on real people (or eager phoning people like me)? How likely is it that someone might report a lost before the replacement mysteriously showed up? Why should phoning in a lost card invalidate the replacement process (I think I know the answer to that one as the original lost and replacement cards, having the same card number, aren't unique...so how can the bank tell which card I was reporting as lost?)

I would've been happier if the person who answered the phone when I called to activate my replacement had told me, "No your card isn't activated." But maybe she didn't know that it wasn't usable. Or maybe she was just being obscure to throw off the card thieff. I can only wonder. After the conversation ended, I knew my card had been activated and thought I could use it. But I couldn't.

I know my bank was trying to be helpful by sending me a magic replacement card. But after one confusing activation phone call, two unsuccessful ATM episodes, and one helpful conversation with the bank teller, I finally figured it out. I'm crossing my fingers until my new card shows up and I use it for the first time.

But Joe says....

2006-08-09T16:13:00.000-07:00

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 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.

Translating Object Design

2006-07-12T17:23:00.000-07:00

Recently I received a copy of the Chinese translation of my book, Object Design: Roles, Responsibilties and Collaborations. It took nearly three years to translate. I hope it sells well, although authors only get a mere pittance for selling translation rights (think $100 or less--and I have to split that with my co-author). So I won’t be making money even if becines a best seller in China. Creating and marketing a best selling book can be dicey as this interesting blog posting for someone in the book publishing business points out (I didn’t write this book to retire on, I wrote it to get the word out about role-based object design).

I found it fascinating to compare the English with the Chinese edition. As I thumbed through the book several features were missing that we thought essential when we originally worked with our editor (in hindsight, our requests added to the book’s cost, but probably made little difference in how well it has sold). We convinced our editor to produce a two-color book so we could annotate drawings using blue. The editors then figured out ways to incorporate blue into subsection titles, boxed in examples, etc. The Chinese edition was black and white and had no index. Margin comments had been boxed off and inserted along with the main text. That certainly made formatting a lot easier.

It was interesting to see the text sprinkled with English words and pseudo-English class names: e.g. Rebecca Wirfs-Brock, Brian Wilkerson, “Rational Unified Process”, Kay, GuessingLettersOnly, aMessageBuilder,–Michael Jackson (the UK problem frames inventor, not THE singer). The format of the Chinese edition numbered subsections, where in the English language version we did not. On the cover, our names were in a smaller font than the text, “forewards by Ivar Jacobson and John Vlissides.” I’m guessing this was to sell more books. The cover included the same cover art but the lettering and colors were much simpler. On the cover, the book’s title was in both Chinese and English. The paper is thin decreasing the thickness of the book by 50%. Printing quality wasn’t great. The translated book was 313 pages vs. 390 for the English version. I wonder whether Chinese writing is more compact or whether parts have been omitted. It is hard to tell.

I’m meeting with one of the translators of our book to Japanese at next week's Architecture and Design World. I really look forward to meeting him in person. Translators who take their job seriously ponder words and meanings. And because of the differences of words in different languages, they can uncover nuances than I ever thought about. For example, I received this query from the Japanese translator about this sentence from our book, “As we conceive our design, we must constantly consider each object’s value to its immediate neighborhood.” He asked, "Does the meaning of neighborhood in your book correspond to the definition 'objects who live near one another' or 'in a particular district or area'? If your answer is yes, could you make selection between 'live near one another' or 'in a particular district or area' because we have different Japanese words for each.”

One of my favorite books is Douglas Hofstadter’s Le Ton Beau De Marot: In Praise of the Music of Language. This book is all about the nuances of translation. Hofstadter, who also wrote the best-selling Gödel, Escher, Bach: An Eternal Golden Braid, explores the myriad constraints that must be chosen to be relaxed (or tightened) when translating, as well as the choices the translator makes to preserve the original author's context or to translate it to a more familiar one of the reader. As a vehicle to explore these ideas, he used a 500 year old French poem that he gave to many friends and colleagues to translate (and he, himself wrote dozens of translations). It’s fascinating reading. As a designer and requirements analyst, I often find myself discriminating very fine shades of meaning. There’s nothing straightforward or mechanical about this process. But to me, translating poetry seems much more challenging . And translators of technical books deserve credit and recognition for their own contributions.

Pay by the job, or pay as you go?

2006-07-10T18:05:00.000-07:00

I was intrigued by the promotion, “we charge by the job…not the hour” (and I admit the kitchen magnet advertisement glued to my phone book cover caught my eye). Even though I had been thoroughly satisfied with my previous plumbers who had a pay-as-you-go model, I was intrigued with this seemingly more informed, one price upfront approach. Who wants to get into a job and find out that the cost will be five times what you expected? So I called up this plumbing company and made an appointment to repair my split hose on my instant hot machine and my fridge’s ice maker.

Within two minutes of the plumber arriving, I knew I had made a mistake. The plumber charged 48.50 USD to just show up. (That was OK as I had been apprised of that policy when I scheduled the appointment). But after shining his flashlight under the sink for a couple of seconds, the plumber delivered this instant analysis: “We don’t repair instant hot units. We don’t carry parts to do repairs on appliances as there are so many brands and models. Yes, I can see that the hose is split (I had already made that diagnosis and had told them that when scheduling my appointment). The best I can offer you is a new instant hot unit installed for $695 plus $40 extra assembly fee because you have other appliances under the sink that are in the way that I’ll have to work around.” He continued, “Since we don’t repair appliances, if your fridge ice maker stopped working all of a sudden and there is no dripping water from a broken line, all I can do is charge you a $90 discovery fee to pull your fridge out from the wall and inspect the plumbing connection. Perhaps there’s a kink in the line. But if I don’t find anything, I can’t do any more as I can’t see where the line goes from the sink to the fridge. ” Hm, so how could he troubleshoot the plumbing from under the sink to the fridge? He wasn’t even offering me an end-to-end diagnosis.

I was extremely frustrated by his seemingly flawed diagnosis proposal and big-ticket component replacement offer. Pay as you go had seemed good in theory—but in practice it seemed a sham. The plumber quoted big repair $$ when I wanted confidence of a reasoned approach. Why couldn’t he repair a simple hose? What use was a quick look behind the fridge? It’s not like I had moved my built-in fridge since it was installed 7 years ago. He hadn’t even checked whether the water line was on (It was on. I had fiddled with it before he arrived, just to make sure).

This plumber wasn’t willing or equipped to do the little things that would maximize my satisfaction and minimize cost. He wouldn’t make minor repairs. And big ticket items or obvious diagnoses seemed all he had to offer. I paid $48.50 and sent him on his way.

I explored how repair my instant hot hose with handier friends and family, and then repaired it by installing a clamp purchased for $0.79 at The Home Depot. I plan on calling the fridge repairman because he’ll be able to perform an end-to-end diagnosis and can repair my fridge if that’s where the problem lies. Next time I’ll make sure the plumber can work by the hour and is willing to troubleshoot by the hour and make minor repairs.

What’s this story have to do with software? Well consider how you decide to get pay for software to be repaired, extended, or upgraded. At a first blush, a fixed bid contract might seem reasonable (or a fixed time estimate from your development team). But “quote one price for the whole shebang” arrangements can lead to padded numbers and the inability for creative wiggle room for making quick fixes or simpler solutions. On the other hand, with time-and-materials projects, you can ask upfront, “Well, how long does it take you to do a typical project like mine?” A developer might reasonably be expected to give a ballpark estimate based on prior experiences (and can tell you how glitches will be communicated and worked through). And if the team is following an agile approach, they'll deliver working software in small increments, keeping visible records of how long tasks take vs. initially estimated. If it turns out that a job is simpler or more complex than expected, with a pay-as-you-go approach, a customer get deeply involved in decision-making and can renegotiate priorities. Sure, there’s a risk ofpaying lots of money for junk or, even worse, unfinished software. But with frequent, open communications, problems can be spotted and approaches mutually agreed upon before laying out a big investment.

Bicycles, bicycles...

2006-06-15T15:44:00.000-07:00

I recently returned from working in Germany. One thing that struck me was that people routinely rode bicycles. Old people, young people, middle-aged folks, people with little dogs in front baskets. I live near Portland, Oregon, which is considered one of the most bike friendly cities in the U.S. But we don’t come close to being a bicycle city. For the most part, daily bike riders are typified in Portland by young hip 20-somethings who bike across the Willamette River to work in downtown Portland. While there are bike paths and bridge sidewalks that encourage cycling, once you get downtown, riding is a scarier proposition—weaving in and among street traffic. And bike lanes, if present, are skinny and dangerous—unlike the sidewalk bike lanes in Germany that are integral to the landscape.

Perhaps one strong motivator for biking in Germany is that gasoline costs over 1.39 euros per litre (that’s roughly 7.50 US dollars/gallon). However it appeared that people weren’t just biking for economic reasons. People seemed to enjoy fresh air and exercise. Biking was as easy as walking (and walking was easy, too)… a pleasant, natural thing to do. It may save euros, but it is an accepted way to get around town. Many people just popped on their bikes to get around town. And German bikes weren’t fancy schmancy either. Just practical and utilitarian.

Biking in the U.S. is somewhat higher ceremony. Strap on that safety helmet, squeeze into those padded shorts, and don a neon shirt so you can be seen by distracted drivers. In fact, in the U.S. you’re considered a bad parent if you don’t make your kid strap on a safety helmet, even if she is riding in the cul-de-sac.

Bob Martin was telling me of his recent stay in Munich where he daily would ride a “yellow bike” to and from work. When you needed a bike, you just phoned the company and they’d tell you where the nearest bike was located and give you an access code. When you were done, you phoned up the company and left your locked bicycle wherever you stopped. Only after I left the country did I find out that where I worked the company had a fleet of bicycles available—all you had to do was ask—for out of town employees and consultants.

Today I got a flyer in the mail about the Portland Bridge Pedal. Annually they close down the bridges for a day and cyclists get the run of the city. Kids, old folks, and many people in spandex go for a 6-,8-, or 10-bridge ride on a Sunday in August. Lots of fun and a chance to ride bikes where only cars normally go. I may do this bike ride again this year simply for the rush of riding with thousands of others. But it isn’t practical. It’s an event.

Which leads me to ponder—what will it take for people to adopt agile development practices on a wide scale? Agile development practices are definitely gaining traction. Witness the nearly one hundred experience report proposals we received for the upcoming Agile 2006 conference.

One thing that I suspect confounds agility’s acceptance is its definition. Is it XP, Scrum? If it isn’t, is it TDD? What about DSDM or FDD, Crystal, or the latest Agile UP or MSF? I am throwing alphabet soup at you to make a point. There are many different agile brands out there. The most recognized is XP—Kent Beck’s set of programming practices. Others fit alongside or complement his disciplined set of programming practices—Scrum is a management/teamwork practice. You can do XP and Scrum. You can also test first then develop—so you can TDD+XP+Scrum. You can also do Scrum and not follow all XP practices. Are you still agile? You are if your focus is on delivering incremental value.

But there are other flavors of development processes and practices out there that address other concerns while weaving in agile practices and values. Hence I’m in the camp that doesn’t think AUP is an oxymoron. If you are familiar with the unified process (UP) and like it, you may want a lighter process with a more agile twist. Try AUP. But I want to make this point: Agility isn’t just a brand. Branded, well-recognized agile practices stand among a plethora of other ideas and practices for developing and delivering software value (my own favorite practices to weave into the mix are Responsibility-Driven Design principles, and recently I coached a team writing agile use cases).

Most people doing agile development typically adopt a set of brand name practices targeted towards a specific need-and decide they should be doing XP or XP and Scrum. But they shouldn’t get complacent. Agility is all about ongoing learning, adaptation and improvement and delivering incremental value. Agility in the raw, unadapted and exactly as published-doesn’t always neatly fit into a company’s culture. At Agile 2006, Kelly Weyrauch from Medtronic, will be presenting the report “What Are We Arguing About? A Framework for Defining Agile in our Organization.”

He’s on to something. At Medtronic they explained agility in terms of its principles, practices, and benefits—and recognized that different people need to hear different things. At their company, the Agile Manifesto was viewed as inflammatory. So Kelly and a small band of co-workers explained agile practices in ways that reinforced and complemented their company’s vision and mission. They defused the anxiety some had about the “radical” agile practices that wouldn’t work at Medtronic by explaining agile practices and values in ways that didn’t collide with their existing corporate values. And they still don’t mention that manifesto. Hm. Being a change agent can be difficult if the climate isn’t amenable to change. But if it is, bring the agile message along in a way that strengthens your company’s core values. Sounds a lot easier than changing Portland into a bike city.

Workarounds vs workthroughs

2006-04-19T18:50:00.000-07:00

Today I had dental implant surgery. The procedure typically takes an hour. I don't want to go into great, gory detail, but an implant is a titanium tooth root substitute that is inserted into the jawbone after drilling a hole for the implant. The first part of the procedure involves drilling a hole or more precisely, a narrow hole is drilled, then through a succession of six drilling with successively larger drill bits, the hole is widened. Screwing in the implant then completes the procedure.

When the drill machine was powered on in a pre-surgery test, it would work for a couple of seconds then halt with an ERR 04 code (drill overheat fault) on the LED display. The nurse informed me that the machine had just started acting up, but they needed it to fail more frequently so they could give enough information to the repair technicians. Well today was their lucky (and my unlucky) day. After some experimentation and repeated faults, the staff figured out that if they carefully cycled the power and waited long enough, chances are the drill would restart and work for a while. Waiting long enough seemed to clear the fault most of the time. Keeping a foot on the foot pedal and smoothly operating the drill seemed to prevent it from faulting with an ERR 09 (foot pedal fault). They informed the surgeon and he and they experimented with the operation of the drill for several minutes before starting the procedure.

Even though I might have preferred to reschedule my implant, the team went ahead (without conferring with me). What was I thinking??? What would've happened if after the third drilling, the machine stopped functioning? Oh, I shouldn't forget to mention that a technician was charged with recycling the machine whenever it failed, cuing the surgeon when to restart drilling.

OK, admit it. I'm sure you've operated some machinery which occasionally fails. We all are familiar with rebooting computers to clean things up. And I've been driving around my 11 year old Volvo for several months now, trying to diagnose why it occasionally won't start (I've finally figured out that if I switch on the ignition while jiggling the shift lever that I can always get it to restartÃ…now that I know how to reliably correct the problem my mechanic says he can easily isolate what's broken and needs fixing).

I started out my software career as an evaluation engineer. From experience, I know that until you find a way to reliably cause a fault, it is difficult to report a bug that anyone is willing to listen to. Intermittent, apparently random failures are the worst kind. Only when you can reliably produce a failure can you even attempt to isolate the problem. Long-term garbage collection bugs or slow memory leaks are really nasty. But golly! When end users encounter intermittent software failures they typically plunge ahead looking for workarounds. Rarely do users want to isolate a problem if they can find a workaround. They're on task, and not particularly interested in troubleshooting software. When a physical device acts up, people typically act the same way. In hindsight, I probably should've halted the procedure before it startedÃ…and scheduled my implant for another day. But they (and I) didn't want to. I was goal oriented. I'll be damned if I wanted to go in twice!! And they seemed confident that they could finish the procedure and seemed unconcerned about the intermittent drill malfunction. (I'm wondering what their backup plan was). Maybe today I really was lucky because in spite of faults, there weren't catastrophic failures.

But back to considering device faults. I've always wanted the ability to manually override a device's fault response behavior when I suspect a faulty sensor. Or at least have a way of running self diagnostics'or something instead of being forced to "jigger a solution". Cycling power seems like such a hack. What if the faulty device doesn't restart and I'm in the middle of an important task? What if I am willing to take the risk to keep operating the device because the consequences of it not restarting are worse than continuing on with a suspected faulty fault? Shouldn't a person be allowed to be in the decision loop in this case? Devices shouldn't just shut off with an ERR code. I'd much prefer a user interface where I'm allowed to initiate a workthrough (e.g. ignoring a suspected fault) instead of being forced to initiate a potentially problematic workaround (cycling power). The faults and fault lights on my car's dashboard work this way (I caproceedde to ignore them at my own peril). Perhaps if the drill had really been overheated, a workthough should've been prevented. But then the determined surgeon would've just cycled power anyway. I'm probably not going to change how people design devices by raising these issues. But I'd be interested in reactions to the idea of designing to allow for workthroughs instead of forcing workarounds.

Can you really estimate complexity with use cases?

2006-04-18T17:44:00.000-07:00

I visited with some folks last week who failed to get as much leverage from writing use cases as they'd hoped. In the spirit of being more agile, at the same time they adopted use cases, they also streamlined their other traditional development practices. So they didn't gather and analyze other requirements as thoroughly as they had in the past. Their use cases were high level (sometimes these are called essential use cases) and lacked technical details or detailed descriptions of process variations or complex information that needed to be managed by the system. But their problem domain is complex and varied, prickly, and downright difficult to implement in a straightforward way (and use cases written at this level of detail failed to reveal this complexity). Because of the level of detail, they found it difficult to use these use cases to estimate the work involved to implement them. In short, these use cases didn't live up to their expectations.

Were these folks hoodwinked by use case zealots with an agile bent? In Writing Effective Use Cases, Alistair Cockburn illustrates a "hub-and-spoke" model of requirements. A figure in his book puts use cases in the center of a "requirements wheel" with other requirements being spokes. Cockburn states that, "people seem to consider use cases to be the central element of the requirements or even the central element of the project's development process."

Putting use cases in the center of all requirements can lull folks into believing that if they have limited time (or if they are trying to "go agile") they'll get a bigger payoff by only focusing on the center. And indeed, if you adopt this view of "use cases as center", it's easy to discount other requirements perspectives as being less important. If you only have so much time, why not focus on the center and hope the rest will somehow fall into place? If you're adopting agile practices, why not rely upon open communications between customers (or product owners or analysts) and the development team to fill in the details? Isn't this enough? Maybe, maybe not. Don't expect to get early accurate estimates by looking only at essential use cases. You'd be just as well off reading tea leaves.

Cockburn proposes that, "use cases create value when they are named as user goals and collected into a list that announces what the system will do, revealing the scope of a system and its purpose." He goes on to state that, "an initial list of goals will be examined by user representatives, executives, expert developers, and project managers, who will estimate the cost and complexity of the system starting from it." But if the real complexities aren't revealed by essential use cases, naive estimates based on them are bound to be inaccurate. The fault isn't with use cases. It's in the hidden complexity (or perhaps naive optimism or dismissal of suspected complexity). A lot of special case handling and a deep, complex information model makes high-level use cases descriptions a deceptive tool for estimation. That is unless everyone on the project team is brutally honest about them as just being a touchpoint for further discussion and investigation. If the devil is in the details, the only way to make reasonable estimates is to figure out some of those details and then extrapolate estimates based on what is found. So domain experts that know those details had better be involved in estimating complexity. And if technical details are going introduce complexity, estimates that don't take those into account will also be flawed. Realistically, better estimates can be had if you implement a few core use cases (those that are mutually agreed upon as being representative and prove out the complexities of the system) and extrapolate from there. But if details aren't explained or if you don't perform some prototyping in order to make better estimates, you won't discover the real complexities until you are further along in development.

I'm sure there are other reasons for their disappointment with use cases but one big reason was a misguided belief that high-level use cases provide answers instead of just being a good vehicle for exploring and integrating other requirements. In my view, use cases can certainly link to other requirements, but they just represent a usage view of a system. One important requirement for many systems, but not the only one. If they are a center, they are just one of many "centers" and sources of requirements.