Rebecca's Blog

This blog has moved

2010-04-13T16:43:00.000-07:00

This blog is now located at http://rebeccawbblog.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://rebeccawbblog.blogspot.com/feeds/posts/default.

Draw a Tree

2009-10-26T16:31:00.000-07:00

I often use a short, icebreaker to introduce design storytelling in talks and classes. I hand out an index card and ask people to draw a tree in 60 seconds. I’ve adapted this from Thiagi’s 99 second Draw a Tree exercise. I ask attendees to draw a tree, any old tree, and to be sure to autograph it as there will be a prize. At the conclusion of the exercise I pick someone at random to receive a small gift or book.

I have collected hundreds of drawings, some are very beautiful. Rarely I get drawings of bamboo.

Invariably one nerd who wants to win the prize and show off his computer geekiness draws a directed graph. After all, he doesn’t know the criteria I'll use to choose a winner (none, it is a random drawing).

But most draw physical trees.

I get canonical tree shapes: mainly deciduous trees, with and without leaves, and a few conifers.

After I've collected the drawings, I ask how many drew roots and if so, why? If not, why not? Invariably, as Thiagi observes, most do not include roots, but some include roots or hints of root structures.

When asked why they didn’t draw any roots, invariably the answers is, “Because I drew what I can see. No need to show what’s below ground.” When asked why they included roots, those who did answer, “Because trees have roots.” Some software folks are very detailed and want to show everything. I’ve even received trees with tree parts labeled.

And there is my hook into the art of design storytelling. It depends upon your audience and the goal for telling your story whether you should include roots or not. There’s no “right” answer. Depending upon what your audience already knows and what you want to focus on, it is perfectly OK to leave out certain details.

The art of effectively drawing or describing any aspect of a software design, is to knowing what to leave out. It’s just as important to know what to omit as it is to know what to include. There’s always more detail. Effective design storytelling leaves out unessential details so that the important stuff can get emphasized.

Design For Test

2009-08-13T09:04:00.000-07:00

It sounds straightforward. Write your test code first, then write code to pass that test. Don't write an inch of code without writing a test first. That is what test-driven development (TDD) is about: Use tests to drive out the design and implementation. Rinse and repeat. Repeat many times a day.

I know a number of top notch developers who are masters at their craft. Yet they don't daily program in a pedal-to-the-metal test-first-only write-the-barest-amount-of-code-to pass the test style. Yet they value testing. Testing, to them, is integral to programming. I asked a few of my programmer buddies who value testing what does it mean to design for test (I have my ideas, but I don't make my daily living writing production code)...even if they aren't TDD followers.

And the bottom line is this: code that is designed for test must continually be tested (not necessarily at the speed of a TDDer). If you want to make testing feasible, you often need to make code-under-test easy to isolate from its production environment, tunable, and measurable. Not easy stuff. Just like design flexibility, testing doesn't come for free. It's part of a disciplined development process.

Read more about Design For Test in my latest IEEE Design Column.

I'd like to hear your reactions...

The Value of Design Documentation

2009-06-15T09:55:00.000-07:00

Recently I asked students to tell me what kinds of requirements they start with and what (if any) design documents do they produce.

Several students said that they produced documentation just because it was part of their development process. As a consequence, they felt that the documents were rarely read, were hard to keep up to date with the real code, and were expensive to generate.

I know that everyone isn't free to change their process...but if something is expensive to do and doesn't add value, especially in this economic climate: look for a better, less expensive alternative.

My advice f is to keep the precision at a low enough level that you don't have to keep updating it with every small change. Last year I helped one client develop a 2 page high-level view of the architecture for IT applications. On the first page was a component diagram. On the back was a high-level statement of each components' responsibilities. While during development they produced other docs, these high-level overviews were intended to orient people who were going to maintain these applications. They were pleased when this high-level view was well-received by those developers.

Simply because a tool lets you reverse-engineer an implementation into detailed class or sequence diagrams doesn't mean you should create lots of implementation-level diagrams. On another project where we used TogetherJ, we pruned sequence diagrams (to omit detail) so that business analysts could understand the basic flow w/o having to know everything. These edited diagrams didn't end up in any permanent design document. Instead they helped explain our working prototype.

To be effective design documents have to communicate valued information to its intended audience. So if you find yourself creating documents that aren't useful...well, think about suggesting cost cutting and process improvement ideas to your team and management. This is the right economic climate to suggest such positive changes.

Sustainable Design

2009-06-08T08:12:00.000-07:00

In my most recent IEEE Column, Creating Sustainable Designs, I explore what it means to create software that can be maintained without too many growing pains. I have been intrigued by Christopher Alexander's writings, particularly the first two volumes of the Nature of Order where he explains the properties of designed (or architected) things which have life and processes for creating life.

It is just as important to look at process of creating good software as it is to consider what properties make software habitable for those who have to maintain it and keep it alive. While I appreciate process (and I think the agile community has given us a lot to consider) I am more keenly interested in exploring what makes complex software "living".

Alexander identifies these properties (or qualities) of living things: levels of scale, strong centers, boundaries, alternating repetition, positive space, good shape, local symmetries, deep interlock and ambiguity, contrast, gradients, roughness, echoes, the void, simplicity and inner calm, and non separateness.

It can be easy picking to draw certain connections between certain "good" software design properties and Alexander's list. For example, good shape, as others have pointed out can be a matter even as simple as properly indented a method. Or it can be more profound than that--leading you to break up a method into substeps and invoke helper methods, just to keep every step at a similar level of abstraction. I'm only giving you a taste to see whether you are interested in exploring these ideas further.

If you are, read my column, and also take a look at the C++ Report article by Jim Coplien on Space: The Final Frontier, which introduces Alexander's notion of centers and how they relate to software structure, and peruse several very good blog entries by Regis Medina.

And if you are interested in exploring these ideas further, perhaps by taking a deep look into working code or frameworks or software that you consider to be particularly alive (or not)... let me know. I am considering finding a venue where software developers and designers and philosophers could concretely explore Alexander's properties more thoroughly. I am not just satisfied to make those simple, easy connections and call it good. I want to challenge our best designs and see whether Alexander's properties really do apply (or if we have some other properties that are more relevant).

Open Spaces aren't for everyone

2009-03-02T16:25:00.000-08:00

I just moderated the comments for my blog and found yet another comment on my posting about Agile Open Northwest 2008 from an anonymous poster about how crappy an experience Agile Open Northwest 2009 was for him (or her). The unconference format was particularly maddening to anonymous who,

"kept looking for something seriously implementable...we've gone to other tech-conferences and club meetings that were seriously more useful."

According to anonymous,

"I think people there [at conferences or meetings with published speakers] have way more credibility to lose, so are better accountable, [have] better presentations, handouts, websites, references."

Open spaces aren't for everyone. If you are bored with repetitive topics or leaders of a session, it is up to you to contribute to the quality of that session (or to go somewhere else). The very first AONW conference was attended by several with folks that have published lots of books and are well-known speakers. And a few of them led a some great sessions (see my earlier blog posts on Dale Emery's talk). But there were other great sessions that just happened, led by ordinary folks, too. Last year, in Seattle, again, there were well-known folks hosting sessions. And we got one complaint that year that too many "experts" seemed to hog center stage. You can't please everyone.

And this year, we had well-known folks like James Shore, Ward Cunningham, and Arlo Belshee lead several sessions. Ward graciously even asked whether it was appropriate to talk about some new wiki ideas before he proposed his session. Ward didn't want to appear too commercial as he is now working for AboutUs, a wiki-making business.

As a conference co-host, I don't try to host any session, because the open space is something I want to foster, not crowd in to or dominate. Whenever I attend a session I do my utmost to make it worth my while. That's one reason why I ask questions of other people and the session facilitator. I am as active as I feel comfortable with, without trying to fill all the open space. Sometimes the best conclusions and ideas happen after a conversation starts to founder...and people regroup and bring it on track.

This year, I found it just as valuable, having conversations with random folks I met in passing and in the hall as I did attending sessions. Yet I had to work at making those connections. And each day I went home tired, yet happy and filled with ideas.

Next year I might try something new and introduce a couple of sessions on topics I've been itching to talk about. But only a couple. I want to have plenty of time to find out what others are interested in, too.

I'm sorry anonymous didn't enjoy the AONW open space. If the sessions anonymous attended were boring or repetitive or poorly led, well... that is what might happen. If you want to go hear experts speaking on a topic, then go to a conference, not an unconference. And if you want to be guaranteed a particular topic, then by all means attend a user group meeting or free talk. But if you want to bravely explore your ideas with others, then an open space unconference might be for you.

What Drives Design?

2009-01-28T20:25:00.000-08:00

Last fall, I gave a keynote at OOPSLA titled What Drives Design? You can view my presentation, thanks to a podcast recorded by InfoQ. I was slightly chagrined to read the one comment on the site:

Funny, I thought that requirements are the main driving for for the design. [The] author made me feel like I was blind all these years...Kidding aside, all these forces [the] author mentions are secondary forces, while requirements should be the primary and the commanding force.

My first reaction is, well duh! I was trying to get behind that to an explanation of our design roots and current practices. Requirements may constrain what are valid solutions, but the choices you make as you design and implement a solution are wrapped up in your design values, aesthetics, practices, and development rhythms. As the person who coined the meme, "xxx-driven" that is used to characterize various driven practices (think Respsibility-Driven Design or RDD, TDD, BDD, AMDD, FDD, etc.) I presented a brief history lesson about how certain software design practices came into being, what values are associated with them, and how these values might conflict or co-exist.

I also challenged the software community to stop being so blindly "driven" and take a closer look at why they follow certain practices. Of course requirements should drive design. But what then drives the way you approach your work? I believe that from time to time it's good to pause to reflect on what you value (and what you think makes a design solution good) before integrating new techniques and practices to improve your work.

If you watch my talk, I'd love to hear about what you value and thoughts on how you approach design.

Three in a Row

2008-11-03T14:05:00.000-08:00

I just got home from a 3-in-a-row conference marathon. First I went to the Patterns of Programming Language Conference, or PLoP in Nashville, where our paper Dynamic Factory, co-authored with Leon Welicki and Joe Yoder, was shepherded in a writers' workshop. This was my first PLoP where I actually had fun. Our writers workshop group was a sharp group and gave everyone excellent feedback. The first time I had a paper workshopped at PLoP a couple of years ago I was disappointed about the quality of the feedback. Speaking with more seasoned patterns conference attendees, I learned that workshopping is hard work--and not always does it work out well. It takes a combination of a skilled workshop leader, workshop attendees who've critically read their papers, and a good mix of insight and discussion. Sometimes, even with the best intentions a workshop doesn't deliver good feedback to every paper. When everything comes together the results are amazing.

Then it was on to OOPSLA where 750 geeky souls met to discuss programming languages, design, practice, and what the next sw trends might be. At OOPSLA I presented a keynote, What Drives Design? that I'd spent the last five weeks working one. I talked about the main ideas behind Responsibility-Driven Design (the first, "driven" method) and then compared and contrasted several different design methods. For the record, I characterized TDD as "design between the keystrokes" and Feature Driven Development as "Design first, program next." Truth be told there is a lot of design that happens when people practice TDD. But refactoring isn't the same as initial design ideating. It still begs the question, when do you do an initial design (if ever)? Is it always at the keyboard? Scott Amber, with Agile Model Driven Development interjects a "model when you need to" front end to TDD practices. Not specifying what you should model, but giving people the framework to plug in non-programming design efforts when they think they need them.

Last week I was SD Best Practices in Boston--the consummate conference for those seeking technical trends and practical advice. I presented my tutorial,The Art of Telling Your Design Story, and a talk on Giving and Taking Design Criticism. At the conference I enjoyed hearing Neal Ford take a swipe at the inefficiencies/unnecessary clutter of implementing design patterns in traditional (read non-dynamic) languages. Neal is a compelling speaker. At the end of his talk I was convinced that Ruby doesn't have anything ovr Smalltalk. Neal confirmed my thoughts about Smalltalk. Still, I plan on taking a deep dive into Ruby this winter.

I'm somewhat concerned when DSL makers tack on behaviors to any class of thing in order to have a fluent language. While that may work in the short run, I'm betting meta-programming tricks and behavior hacks to basic classes won't scale. Call me a traditionalist, but I remember the clutter of extra behavior tacked on to Objects, Integers and Strings causing real problems in Smalltalk. It wasn't considered good practice then...and I'm not sure I'd make the same "fluent language" trade offs Neal wood. Still, his talk got me thinking.

I also enjoyed hearing Rick Brenner's Organizational Politics for Those Who Hate Politics. While I don't have office politics to contend with in my own business, I do encounter lots in my clients. SD Best Practices is a conference where you can blend geek topics with management or professional development topics and come away feeling well-rounded.

At OOPSLA I gave a keynote, What Drives Design?

Software Design and Development is Fun???!

2008-09-18T17:33:00.000-07:00

A twitter between my daughter and a friend:

@jordanwb Are you related to Rebecca Wirfs-Brock? Her name was mentioned in my Software Design and Development class.
This class isn't any fun.
@thismax that's my mom! I'll let her know you guys are talking about her. 02:16 PM September 16, 2008

Software development can be fun when people collegially work towards solving a design problem. Last week I visited a client and helped them understand and apply responsibility-driven design principles and practices to the design of software components and subsystems. By far, the most rewarding activity during the week was a workshop where designers paired off and solved a common design problem. Sharing design ideas and initial solutions was fun. Reworking their designs to cover more cases was fun. And taking good ideas from others and melding them into a better solution was an unexpected benefit of all this sharing. One key to the success of this workshop was that a real problem was chosen that didn’t have a pre-existing owner or preferred solution. It was a problem without territorial boundaries and/or clashing vested interests. So design teams were genuinely open to constructive criticism from others. And the small teams could go much faster working in pairs than working in a larger group.

Collegial, thoughtful, reflective, not-too-detailed-at-first designs. Highly productive. And fun. Now why aren’t more design efforts like that? The best design and development experiences in my career have been where I've worked on small, tight teams. There was mutual respect, a common goal, pride in our work, and a healthy dose of reality: let’s think about the problem a bit, then prove our ideas by implementing them. We may have had disagreements, but we found a way to discuss and weigh options without getting bogged down or wedded to any particular solution. Collaborating was fun under those circumstances. I can remember some not so fun times too: people fighting over style instead of substance, working too hard but not too smart, and clashing egos preventing us from finding any common ground. That wasn’t fun. It was a grind. Even though those projects may have successfully completed, the thought at their end was 'finally!' instead of 'yay, we did it!'

More twitter:

Coding 'till almost 4am... am I acting like a stereotypical programmer now? On the upside, I implemented the Hill Cypher, and feel badass. 12:48 AM September 11

Getting things done at 4 a.m. can be fun, too. Nothing like a sense of real accomplishment after a long haul programming effort. But it can get old fast. Especially if you're not a grad student and you're working solo on a design effort without the support and encouragement from your team mates.

Design Hygiene

2008-08-20T19:02:00.000-07:00

Without ongoing attention to design hygiene, design integrity is bound to deteriorate over time. My latest IEEE design column, Enabling Change, briefly examines what it takes to keep a code base ready to absorb new design changes.

At the very least you should leave code as clean as it was before you made a change (if not better). One credo that Scott Bain extols in his new book, Emergent Design, is whenever you touch the code "do no harm". Do what you know to be best at the time (given the constraints you are under). Scott is a realist, but I like his stance on when to fight for one particular design approach over another, too. When you think it will be really difficult to refactor/cleanup the design later due to a poor design decision that is on the verge of being made now, argue for what you think now is a better solution.

But even with good intentions and experience, we need to refactor and rework our code as we refine our design ideas--and learn from the code. Yep, we should refactor. Continually. But we don't always do so. Emerson Murphy-Hill, a Ph.D. student at Portland State and Andrew Black, a professor at Portland State wrote an intriguing paper, Refactoring Tools: Fitness for Purpose, that also appears in the upcoming issue of IEEE Software. They explain why in practice refactoring tools aren't used as much as they should be and propose some principles that characterize successful regularly used refactoring tools. They also distinguish between "floss refactorings"--those which should be done a regular ongoing basis during programming in order to avoid more pain later on-- from "root canal" refactorings. They found that refactoring tools could be better designed and point out some that are better designed for daily use than others.

Junk faxes, print cartridges and canceling-oh my!

2008-08-19T16:07:00.000-07:00

Because two colored ink cartridges are empty (cyan and yellow), my black and white faxes have been piling up in my machine’s buffer. My fax-printer-scanner insisted on having non-empty color cartridges installed. But when there are no color print jobs that doesn't make technical sense. I suspect other considerations drove this design decision. Print cartridges are where the money is. From a business sense it makes dollars and cents to insist that all cartridges are installed and in good working order before allowing the user to print anything.

But even more annoying was the difficultly I had stopping my printer from printing a month’s worth of buffered faxes! Glancing quickly at the buttons on my Brother MFC-885CW I noticed one labeled Clear/Back and another Stop/Exit. I pushed the Clear/Back button a couple of times to no avail, then decided I’d just let the faxes print. (Mild curiosity led me to receive 3 fax ads for discount health care, 3 for vacation deals in Cancun, an invitation to the Presidential Who’s Who among business and professional achievers, and a Neo-Tech stock market news report.)

There will always be competing values and design goals. Business and users’ goals don’t always match. An ethical usability designer should point out these conflicts and not let them slide. I know that might be pushing it, but someone should have strongly questioned whether it is better to demand all cartridges be installed or not.

But usability concerns don’t stop at defining how to accomplish some task or what constraints exist on initiating one. How to start, stop, pause, quit, and retry should be considered, too. Clear/Back and Stop/Exit? How confusing! I wanted to clear the print buffer and stop all printing. But perhaps I should have stopped printing first. But then what? What I wanted was to stop all printing and clear my printer's internal buffer all in one easy to do action (I don’t read manuals when faced with an exception in real time). Maybe pressing Stop/Exit would’ve accomplished that. I’m not sure. If I remember, next time I’ll try that.

But what if I wanted to stop one fax job, but continue printing the others. Hm, maybe that Fax Preview button on the other side of the print console could come in handy. Grr. There isn’t just one path through an exceptional case that a user might want to pursue. They all need to be carefully considered. And too many buttons with small and potentially confusing labels don’t help me accomplish an emergency action in a hurry. I think Brother could do better by displaying alternate flow options on the console during printing (did I mention there is a display console on my printer?), but I’d have to get “trained” to look there. Since I don’t stand by my printer and watch it work enough to notice what kinds of informative messages it displays, it might’ve been telling me what my options are, and I just didn’t notice. Now that's a tough problem to tackle. Not sure how to avoid frustrating inattentive users who don't know to look for advice on how to logically push that missing big red cancel button. (I'll take a closer look the next time my printer prints a fax to see whether it tells me anything).

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.

Agile Podcasts

2006-02-23T19:23:00.000-08:00

At Agile 2005 I met Bob Payne during an open space discussion about growing an online agile community. Bob didn’t just talk. He helped make it happen by recording interesting conversations and turning them into podcasts. You can download them from Agile Toolkit. For those of you new to podcasts, you don't have to have an iPod to listen in. I click on any podcast link in my browser, for instance, and the mp3 file plays after it downloads. Some highlights: Ward Cunningham and Rick Mugridge on Fit; Todd Little on the Agile Project Leadership Network; Mary Poppendieck on Lean; Lynn Miller, Jeff Patton and myself on User-Centered Design. Dave Astels, Scott Ambler, Bob Martin, Arlo Belshee, Nancy Van Shooenderwoert, Mike Hill, Esther Derby, Diana Larson, and Pollyanna Pixton round out the list. Bob’s planning on recording conversations and conference events at Agile 2006. Thanks, Bob!

Just Enough Structured Analysis

2006-02-23T19:20:00.000-08:00

Today I happened upon a notable source. Ed Yourdon is writing once again about structured analysis. According to Ed,

“This is an update, condensation, and pragmatic revision of my 1989 tome, Modern Structured Analysis, which is still employed by malicious professors to torture innocent students in universities around the world… the decision to update the material, and to rewrite what was probably far too ponderous a tome (672 pages) even in the days when people actually had enough time to read books printed on dead trees…[is based on the fact that] today, we’re too busy to spend much time thinking about anything, and we’re also far too busy to read more than a couple hundred pages of the bare essentials on any topic. What we want is “just enough ... ”

Ed plans on completing his book in 2007. There are a handful of chapters available now including one on Data Flow Diagrams and another on Process Specifications (which shows many different ways to represent what’s going inside a bubble on a data flow diagram). At OOPSLA last year I had the pleasure of hearing stories from Ed including how he’d been recently asked, “Aren’t you dead?” Ed’s very much alive. I’m not sure when I’ll next create any of these models, but I want to know about them from the source.

False Dichotomies and Forced Divisions

2006-02-10T10:56:00.000-08:00

Last week I received an email with this tagline:

“Replacing an on-site customer with some use cases is about as effective
as replacing a hug from your Mom with a friendly note.”

I enjoy this person’s funny, witty, and constantly changing taglines. They certainly add zest to mail messages. But this one bugged me. It set up a false dichotomy. A false dichotomy occurs when someone sets up choices so that it appears there are only two possible conclusions when in fact there are further alternatives. Consider the phrase “if you’re not for me you must be against me.” Most of the time this is a false dichotomy. There are other possibilities. You may totally be indifferent to the person’s proposed idea or undecided. There may be several unmentioned possibilities (and they may not be mutually exclusive).

Driving to a Portland SPIN meeting last night I saw this bumper sticker: “I don’t have to like George Bush to love my country”. Wow. A false dichotomy pointed out in the political arena. What a novelty!

But back to what bugs me about this tagline. It first set up the false dichotomy that “mom’s hug” is better than “friendly note”. But wait! Mom’s hugs aren’t always better than friendly notes. Maybe you need that friendly note to help you through a tough day. Maybe that friendly note includes a useful reminder. In that case a friendly hug might be a good start, but it’s not enough. Mom can always give you a friendly hug and write you a friendly note.

The tagline then makes the powerful analogy between mom and onsite customer, and friendly note and use cases. If you don’t think this through you could end up being swayed to believe that use cases and notes are never as good as mom or onsite customers or apple pie (and that you have to pick one). But use cases and onsite customers can co-exist if you need them to. There are legitimate reasons to write things down. Maybe writing helps a customer sort through what she really wants. There can be value in recording what was said because it needs remembering by more than the development team. The next time someone tries to sway you by setting up a false dichotomy don’t get caught in their faulty reasoning. Stop. Think things through. Then decide what your position is or whether you see more possibilities.

Pattern drift

2006-01-30T16:49:00.000-08:00

When I first reviewed Design Patterns, I recommended it be published as a loose-leaf notebook. I suggested that authors provide regular updates (this was before the Internet was readily available!). I anticipated frequent updates and many more additions…23 patterns didn’t seem like nearly enough.

Fast forward to 2006. Design Patterns has been in print unchanged for 12 years. Although recognized as a landmark book, it needs refreshing. In fairness, the book was so popular that there was little motivation to do so. An update is supposedly in the works.

I give my students the original text, but they struggle to read it and find relevance (C++ and graphics examples are a stretch for most). I always point them to other sources, both online and in print, to fill in the gaps. Many have written their own take on specific patterns. That is a good thing. In 1998, in a C++ Report article, John Vlissides acknowledged that pattern definitions aren’t cast in stone.

It seems you can’t overemphasize that a pattern’s structure diagram (class diagram) is just an example, not a specification. It portrays the implementation we see most often. As such, the Structure diagram will probably have a lot in common with your own implementation, but differences are inevitable and actually desirable. At the very least you will rename the participants as appropriate for your domain. Vary the implementation trade-offs, and your implementation might start looking a lot different from the Structure diagram.

In Refactoring to Patterns, Josh Kerievsky quotes Vlissides and then after illustrating the original Composite pattern:

Gives his own take on a single-class implementation:

Hmm. A single concrete class that could support either leaf or composite behaviors. Now that’s a thought…but is it still recognizable as a composite pattern? Sure…but what is it that makes a composite a composite and not just another structuring mechanism? Is it just a fancy name for a “tree structuring mechanism” or is there something more?

Bob Martin, in Agile Software Development, presents another variation. He illustrates composite with a Shape interface which defines a single method-draw(). That interface is realized by classes that are either primitive shapes or composed of other shape objects.

In 1994 when Design Patterns was published, interfaces weren’t present in popular programming language. The authors relied on abstract class definitions instead. Since I spend my time with C# and Java, today I’d likely recast many GOF patterns using interfaces instead of abstract classes, especially when there isn’t any common meaningful behavior to inherit.

But Bob’s example illustrates another important design choice. He didn’t force-fit composite behavior into a common abstraction shared by both “composite” and “leaf” objects. He isn’t alone in making this tradeoff. Many of my students after struggling to define meaningful operations common to both, throw up their hands and grumble that the GOF authors made the wrong tradeoffs when they specified the composite pattern. This sentiment is echoed on a RICE webpage:

In Design Patterns, the abstract component AComponent is shown as having accessor methods for child AComponents. They are not shown here because it is debatable as to whether one wants the Client to fundamentally view the AComponent as a single component or as a collection of components. Design Patterns models all AComponents as collections while the above design models them all as single components. The exact nature of those accessor methods is also debatable.

Debating design tradeoffs is healthy. That’s why I give my students GOF undistilled and we discuss tradeoffs as they learn patterns. This helps them gain design confidence as they articulate their values and say what they like and don’t like about the patterns as presented…But sometimes I think they’d prefer a simple “canonical” pattern form they could just use without much thought. I often point them to the Data & Object Factory website which has a quick pocket guide discussion of each pattern. But the composite pattern sample implementation there defines an abstract Shape class with empty add() and remove() methods. And leaf classes implemented add or remove by writing a console message “can’t add/draw a shape to an X”… A toy solution if I ever saw one! Perhaps if I paid $79 to purchase their Design Patterns Framework I’d see a more realistic implementation.

This leads me to wonder: what makes a pattern useful, how much change can or should it undergo, and how much “stewardship” should there be over pattern drift, pattern evolution and pattern explanations? I don’t expect patterns to be fixed and unchangeable. They should wiggle around a bit. But I like thoughtful discussions and reasonable examples. I wish there was a community that maintained an active PatternPedia repository where authors would be encouraged to keep their patterns up to date and where there were useful teaching examples, thoughtful reviews, and summaries of both new and classic patterns. The Portland Pattern Repository is a springboard for patterns, but it doesn’t seem very active. The Hillside website is useful, but it just points to other sources. I have more in mind a cross between Wikipedia and Amazon with an edge and an active editor/convener whose job is to keep us informed of the latest breaking pattern news. Sure I can search the internet and books for patterns. But my search feels scattered. I never know when I’ll stumble across some arcane shift, a mangling of a pattern’s intent, or a good trend to follow. It’s too hit and miss.

Currently, most patterns are copyrighted by authors and are locked up in relatively static media—books or conference proceedings or magazine articles—or static online versions of the same. There’s no central source, no common repository for a growing body of pattern wisdom gained from experience. So when pattern interpretations shift, as they invariably do, it is in a quirky ad hoc manner. I don’t mind Kerievsky’s compact interpretation of Composite. I just wish his version was accessible to those who didn’t buy his book, and that there was a place for open debate about the merits of this implementation choice that was readily linked to other Composite pattern interpretations. Is this asking too much? Isolated works make it difficult to change/refine/invigorate patterns with in a larger community of users/developers/pattern authors. What would it take to create a patterns commons? I’d be interested in hearing your thoughts.

Alan Shalloway's Hat Trick

2006-01-12T16:42:00.000-08:00

Why does design seems so effortless in the hands of a master and why do beginners find design so difficult? Alan Shalloway’s talk about Emergent Design at Software Development Best Practices last September demonstrated three ways to get to an identical good design: apply design patterns, use commonality-variability analysis, and practice test driven development techniques. The problem he used to illustrate his talk was fairly simple. Design classes to support monitoring microwave chips and cards by requesting their status over either a TCP/IP connection or via SMTP. Messages may optionally be encrypted with either 64 or 128 bit encryption. Cards queue information and send it out no more than every 10 minutes unless there is an error (then they send it immediately). Chips send results immediately.

Alan started by describing a tall, ugly hierarchy with intermediate abstract classes and 24 concrete subclasses for each hardware type, encryption mechanism, transmission protocol combination. This design is clearly bad because it contains redundant behaviors and a combinatorial explosion of leaf classes.

Next he applied the GOF authors’ advice of favoring composition over inheritance, to create a design that had three families of classes—one for each variation—hardware type, transmission protocol, and encryption. The specific hardware class plugged in the appropriate encryption and transmission protocol helper classes together to implement the appropriate behavior variations. Alan then showed how test-driven development starts with a simpler game plan. Instead of understanding all variations upfront, create a clean design which supports just one partial feature (or story) at a time. Refactor as you add more capabilities following a few good design principles. The idea with TDD is to let the design emerge, one story at a time. The first story Allan specified was to request the status of a chip with 64 bit encryption transmitted via TCP/IP. The next story added the flexibility to support different encryptions, the third transmission via SMTP, and so forth. He concluded his design demonstration by applying commonality-variability analysis to create the same end result. In a nutshell commonality-variability analysis involves identifying common abstractions and variations, relationships between them, assigning them responsibilities, and then linking them together. It differs fundamentally from TDD in that you upfront analyze variations before creating classes that are then configured to work together.

Voila! Identical designs following different approaches and a handful of design heuristics. Is this a realistic expectation outside of a canned talk? Can mere mortals, students new to designs, or developers faced with considerably larger more complicated design variations perform such clean design factorings in a real-world setting? I’m highly skeptical. I’ve seen so many different designs for a more complex problem I present to students of my design class that I’ve stopped believing I know every reasonable solution. I am constantly amazed by the sheer number of different acceptable design solutions students create. Sure, there are recurring patterns and themes among a range of acceptable design solutions. But I don’t expect identical solutions.

Alan's demonstration that a good design can be achieved three different ways—an amazing hat trick—really hit home the point that you needn’t always start by knowing everything upfront. But toss in a few more wrinkles—add a communications port, a mechanism to gain access to that port, define different card and chip types (with different reports), cards that report at different time intervals, cards and chips that can be programmed to report or have to be polled (or both)…and I expect design solutions to really diverge. One designer may embed an if-then-else decision into a method while another may factor out a variation into a family of classes. Some designers check a condition before asking a helper to perform an action, rather than find the polymorphic way to hide those details. Instead of having an “empty encrypter” class, designers may use a variable to represent bits of encryption, and only invoke the encrypter if the variable’s value isn’t zero. Even though I strive for squeaky clean polymorphism and to eliminate external checks, I often can’t convince students or some designers of the benefits of using null objects. To them, creating another (null) class seems like more work than it’s worth.

So while I don't expect different designers to produce identical results, I firmly believe that abstractions can either be developed “as you go” or plotted out ahead of time. Alan advises designers to selectively use these approaches. Work out pattern-oriented solutions ahead of time when you know what variations are prevalent. When design variations aren’t so straightforward, start simply and add support for variations as you go. By using test driven development and rigorously refactoring before adding new functionality, you can keep an emerging design clean. Just don't expect everyone’s design aesthetics to line up. Commonality-variability analysis seems to be a useful anlytic technique whenever I'm laying out the facts as I consider how to support a related set of variations.

Start Me Up...

2006-01-09T16:41:00.000-08:00

...it's a new year and time to exercise my blogging muscles. I've been hunkered away writing design columns for IEEE Software (as well as enjoying a holiday break). Now that two columns are in the bag, I am turning some attention here. In addition to appearing in print, I will also post my columns on my website's resource page. Looking for Powerful Abstractions appears in the Jan/Feb 2006 issue. If you have any design ideas you'd like to kick around or think are worthy of a 1500 word column, please drop me a line.

John Vlissides

2005-11-29T15:43:00.000-08:00

John Vlissides died November 24th. A wiki page is dedicated to his memory.

One of my favorite books is John’s Pattern Hatching. I love that book. Reading it is like conversing with a wise, witty, insightful friend. As parting advice in Pattern Hatching, John advises pattern writers to,“ Write clearly and unpretentiously. Favor a down-to-earth style rather than a stuffy academic one. People understand and appreciate a conversational tone, making them more receptive to the material… Make sure everything you write is something you could hear yourself saying to a friend.”

Good advice. When I asked John to write a forward for our design book I was anxious about whether our writing and writing style would pass muster. They did (whew!). I was stunned by his generous, kind, and encouraging words. John has been a good and wise friend, mentor, and colleague, who has encouraged and inspired many in the software community. We will miss him very much.

Exceptional exceptions

2005-11-28T23:14:00.000-08:00

I should have known something interesting would happen today when I read my horoscope*:

Chug along as planned. Circumstances might create a series of minor emergencies that interrupt your routine. Remain fluid about plans.

Today I had a bizarre ATM experience. The machine gobbled my deposit envelope but kept beeping and prompting me to deposit the deposit envelope in the slot. But I had already made my deposit! So after 30 seconds of incessant beeping I pressed the cancel button. The beeping didn’t stop. I calmly walked inside spoke to a teller (we could hear the beeping inside the bank). She walked outside, looked at the screen, and followed instructions inserting an empty deposit envelope. The ATM then ejected my card and a receipt that indicated my transaction had been canceled. But the machine still had my deposit envelope.

After a short consultation, a more senior teller took over. She opened the back of the ATM, opened the deposit box, and sorted through the envelopes. My deposit envelope wasn’t there. She closed the machine (meanwhile as she was doing this someone else successfully made a deposit that landed in the deposit box). She went inside, consulted someone in a back office, made a phone call and then spoke with me. She had reached someone who she said was “a little unreasonable”. They suggested I file a dispute and then they would schedule a technician to search for my missing deposit envelope lost inside the machine. Meanwhile she rechecked the deposit box, took my name and phone number and said she would resolve this today. And she did. A technician came out, popped open the front panel of the ATM, and found my deposit envelope clinging to the top of the dispenser in a way that allowed other envelopes to slide over my envelope and drop into the deposit box.

My thanks and gratitude goes out to that persistent teller. Without her my deposit would still be in limbo.

What about the ATM? Could it have worked better? How could it have handled this really exceptional case? I am guessing that my envelope never was sensed (otherwise, how could the deposit slot still be waiting to accept an envelope). It was in limbo. But beeping a long time while displaying the “insert your deposit envelope in the deposit slot” didn’t help me out. Those instructions didn’t apply to me! The fact that a teller could insert a blank deposit envelope meant the deposit slot was working; the next depositor’s actions confirmed that. But somehow my deposit envelope hadn't been recognized by the machine.

What about the behavior of “cancel”? Cancel didn’t mean “immediately cancel”. The machine kept incessantly beeping…demanding that an envelope be deposited. I was too stunned to know what it wanted. Even if I had figured out what it wanted, I don’t think putting in a blank envelope would’ve been a good thing to do. I can imagine the bank then claiming that I’d deposited an empty envelope and I probably would have had to file a dispute. In hindsight, my actions were the right ones to take. If cancel had immediately ejected my card, things might have been better… there was something disconcerting about cancel not having an immediate effect, even though it led to me going inside to find smart people who eventually tracked down the problem. It seems like a poor system design to have cancel wait until a hardware initiated action was complete. This could’ve been a result of poorly designed hardware. I just don’t know enough to say.

If cancel had been immediate, my card and a canceled deposit transaction would’ve been ejected. I still would’ve had to deal with the missing deposit envelope. But I suspect the story I told the teller wouldn’t have been so compelling.

The teller said that after a certain amount of beeping the ATM would have canceled my transaction anyway and swallowed my card (so this leads me to believe that there is some ability for the system to time out if expected hardware actions don’t occur). I still suspect a software bug. If the ATM had swallowed my deposit envelope this way during non business hours I suspect I would’ve stood at the machine until it stopped beeping …which would’ve led me down the same path but with undoubtedly more trouble. Hm.

As someone who has written many use cases, I would have specified that cancel should be immediate and that user transaction’s abort as soon as the cancel key was pressed (unless the transaction was beyond canceling and then some indication of that failed response signaled to the user). And then I would’ve written tests to push on all the weird cases I could think of.

How cancel is detected, when it should take effect, and what should happen often fall into that gray unspecified area. Most use case descriptions ignore or say very little about canceling actions. Specifying cancel exception behavior doesn’t fit well neatly with tying exceptions to specific use case steps since cancel can happen at many different places (and across many different use cases). Aren’t use cases best when they describe business-level steps, not lower level implementation details? Sure, but sometimes it is important to specify these pesky interaction details that make your system be responsive or react predictably.

My advice: when you want to specify these things, start by writing statements that describe when cancel is enabled (and when it is not), when the software should detect it, what should happen, and what should not be allowed to happen. You may need to define invariants that must be preserved, describe detailed cancel actions, or develop state models. These descriptions, in addition to use cases can specify interaction design. It’s unrealistic to squeeze every little detail into a use case description.

*Disclaimer: On the rare day that I read my horoscope I forget it by the time I’ve finished reading Dilbert and Doonesbury. But today’s horoscope was strange enough that I remembered it.

Customer service that works!

2005-11-14T10:47:00.000-08:00

It is passé to rag on poor customer service. So I won’t. Instead I’m going to praise Interlink Electronic’s customer support. A year ago I purchased a remote pointer from Interlink. I wanted to use it on my new tablet pc. Plug-and-play didn’t work…and I went to their website to read the manual which directed me to “press the laser button and direct the beam on the receiver’s starburst pattern for 5 seconds” to re-program the device. “When the green light glows steadily the receiver is programmed to the unique address of the RemotePoint Presenter Remote. After address is established, the LED will return to blinking green.”

There was no starburst pattern on the receiver and no matter how long I shined the laser on it, nothing happened. So in a fit of inspiration I sent an email to their tech support. The next morning I received a reply that said that “my device should require no reprogramming to get it to work”. But still it ended with a polite, “are you having problems with your remote?” I replied that yes, I was still having problems and it didn’t work. Within an hour I got a very clear email:

Try this procedure for re-training your receiver:

1. Disconnect the receiver from the USB port and wait 10 seconds.
2. Reconnect and once the LED starts to flash, position the remote no more than a foot away from the receiver.
3. Press and hold the right arrow on the remote for about 15 seconds. You should see the flashing LED on the receiver turn to solid green, then red and back to flashing green.
4. Your remote should be good to go.

And it was. I even sent another email asking for access to downloadable software that lets you reprogram the device and I got another quick reply. I could rag on Interlink’s out of date manual or plug-and-play equipment that wasn’t. But I won’t. Because their customer service (thanks Ody) was so responsive. Helpful customer service. Imagine that.

OOPSLA, Creativity, and Practice

2005-11-01T13:46:00.000-08:00

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. As a teacher of 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 “evic ed”—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.

Musings of an OOPSLA elder

2005-10-24T10:21:00.000-07:00

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 thus launched my enduring interest in design.

Thursday I had another elder moment. Iwas 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!

Paremetric Diversions Revisited

2005-10-14T10:07:00.000-07:00

OK, I admit it. After writing about H.S. Lahman’s talk on invariants and parametric polymorphism, I wanted to see what the rest of the world thinks parametric polymorphism is (and isn’t).

The Wikipedia entry for polymorphism states,

“polymorphism is the idea of allowing the same definitions to be used with different types of data (specifically, different classes of objects), resulting in more general and abstract implementations.”

Hold that parenthetical thought—specifically different classes of objects—resulting in more general implementations.

Well in the billing example I defined a single generic algorithm that worked on a single class of data (a RateSpec). The clever encoding of the RateSpec threshold and rate tables allowed a single algorithm to cover a wide range of data values: some customers could only be charged a single base rate, others could have different thresholds. The RateSpec object provided a uniform view of this data from the algorithm’s perspective. I wasn’t technically using different classes to represent different encodings. I was being economical by only defining a single class that could encapsulate many different rate and threshold encodings. Is this really parametric polymorphism?

The Wikipedia entry goes on to say:

“Using parametric polymorphism, a function or datatype can be written generically so that it can deal equally well with objects of various types. For example, a function append that joins two lists can be constructed so that it does not depend on one particular type of list: it can append lists of integers, lists of real numbers, lists of strings, and so on… Parametric polymorphism was the first type of polymorphism developed, first identified by Christopher Strachey in 1967. It was also the first type of polymorphism to appear in an actual programming language, ML in 1976. It exists today in Standard ML, O'Caml, Haskell, and others. Some argue that templates should be considered an example of parametric polymorphism, though instead of actually reusing generic code they rely on macros to generate specific code (which can result in code bloat).”

There's a subtle distinction between modern implementation techniques that are labeled parametric polymorphism and what H.M. was getting at. Before hearing H.M.’s talk, I’d thought of parametric polymorphism as just being another word for parameterized types and/or template classes. That does seem to be a fairly common modern definition. But H.S. Lahman put a slight twist on things. His main point was that careful design of data along with a generic algorithm can accommodate wide variations without lots of classes, case statements or conditional logic. In fact, the key is to design a single, uniform view of seemingly disparate data. In a complex system (the Shreveport LA water rates aren’t complicated enough), different RateSpec implementations would likely be needed. And I suspect that there isn't one algorithm to calculate rates. But in my simple example, they weren't. So while I technically might not have been using parametric polymorphism, I did achieve uniformity by encapsulating what varies in a single RateSpec class whose instances would be composed of different rate and threshold table attributes. And that what makes this design simple and flexible.

Parametric polymorphic--or driving behavior with data

2005-10-13T15:40:00.000-07:00

At Software Development Best Practices 2005 I attended as many design and architecture talks as I could fit in. I enjoyed H.S. Lahman's talk on Invariants and Parametricpolymorphicm. His talk illustrated how instead of abusing inheritance, you can use data to drive general algorithms. This is something I've done on many an occasions, and no, I don't think it violates responsibility-driven design principles. In fact, it is a vital technique for creating extensible designs where extensions can be done externally to your application (by business people creating appropriate data).

An example is worth illustrating the concept. Consider the problem of calculating charges for a water and sewage bill (my first COBOL program as an analyst/programmer for the city of Vancouver, WA made these calculations). Although there were many, many different types of customers (industrial, commercial, residential of various sorts, government, non-profit, etc.), the basic algorithm for computing the customer's bill was to apply a minimum charge based on the customer type and meter size, then apply a rate stepping function: Base rate + (first tier rate * units in first tier) + (2nd tier rate * units in second tier). Sewage was another similar calculation. Searching the internet, I was happy to find a published similar example of water and sewage rates for the city of Shreveport, Louisiana.

The key to making a single calculation work for a variety of different computations is inventing an encoding for a business rule or algorithm or policy (your invariant) that can be driven by descriptive data that can be treated uniformly by a single algorithm. This data can be encapsulated in a specification object. Of course, given a myriad of Rates and Tier values, these would most likely be encoded in a relational database or some tabular scheme that would be objectified into a specification object.

Computing monthly charges is pretty simple (ignoring floating point arithmetic precision for the sake of simplicity).

Parametric polymorphism is a fancy name for using parameterized data to drive behavior. A bad alternative would be to create many classes of objects to accomplish the same thing. Imagine the nightmare of maintaining a different class for each type of rate and threshold combination! Fact is, though, there is a lot of rate information to maintain. No getting around that. Rather than being hardwired into a program, the rate and threshold specs can be maintained by non-programmers. Even better.

More generically, decision tables can represent information compactly that can be used to drive complex computations. Drools.org offers open source frameworks that support integrating decision tables with Java. If you've tried these on a project, I'd be interested in hearing about your experiences.

The key is to effectively exploit objects and data to drive flexible, scalable solutions. If you have really quirky computations and rules that can't be tamed and codified in a simple manner, you can still exploit these techniques. But you will likely have to untangle and codify several decisions in order to drive several different computations. No one said life is easy. But effectively encoding decisions and variations is key to building flexible, scalable solutions that don't have to be solved by bruteforce, ugly, rigid code.

Fitting problem framing into everything else you do

2005-10-11T11:21:00.000-07:00

At Software Development Best Practices 2005 I presented a tutorial, Introducing Problem Frames. Problem frames are a way of thinking about software problems and approaching the task of writing descriptions of desired and expected behavior. More can be found about them in Michael Jackson’s definitive book. There’s also a website devoted to problem frames. I find Jackson’s paper, Problem Frames and Software Engineeringgood summary of problem frames for the mildly curious. Jackson introduces five basic problem types: workpiece, information, transformation, commanded and required behavior. Each frame can be described in terms of :

A decomposition of a problem into a particular set of interacting domains;
A characterization of domains as being lexical (symbolic), causal (responding to and/or causing events), or biddable (typically humans who can be asked but not forced to respond);
A characterization of the shared interfaces (events, state changes) between domains, and;
A depiction of a requirement and its relation to particular domains.

My tutorial illustrates Jackson’s problem framing using an email client application (thanks to colleagues Jim and Nathan who worked with me on this example). I hope to expand on it in the future. The example illustrates various frames and concerns but doesn’t go into great detail specifying requirements. That’s OK. The point was to introduce frames, not introduce the art of writing specifications after identifying frames.

For now, I’m content to have an example in hand which illustrates the basic mechanics of problem framing applied to a purely software system. Jackson’s examples and emphasis is on software interacting with the real world. He made this very clear in a posting to our Yahoo Problem Frame discussion group:

...the emphasis on physical phenomena is very important—even central—to problem frames. If your problem is "given a very large integer, find its factors" there aren't really any physical phenomena involved at all. aren't really any physical phenomena involved at all. Of course the integer must be somehow presented to the machine, and this will involve physical phenomena of keyboard strokes or something of the kind; but these phenomena are just incidental to the problem.

I don't think that the problem frames ideas are totally useless for a problem without signficant phenomena, but I think they lose a lot of their value and appeal. Problem frames are about engineering in the sense that Vincenti quotes: "Engineering ... [is] the practice of organizing the design and construction of any artifice which transforms the physical world around us to meet some recognized need."

-- Michael

Most folks I work with aren’t developing software to control physical devices. Yet I believe that framing could be applied to many IT software problems and help clarify what the system should do—as long as framers can transcend Jackson’s real-world focus and look inward to the interior domains prevalent in their software world and understand how to describe the shared phenomena between them.

However, I think there are several hurdles to overcome before problem framing will have a wider IT audience. Practicing analysts already have many tools for specifying systems: context diagrams, event-response tables, business rules, use cases, user navigation models, user classes, personas, data and information models, decision tables. Where do frames fit with what they are already doing? In my tutorial, I made a point that the end-products of framing aren’t just those simple frame diagrams (they are in fact only a placeholder for discussing and writing—if you are so inclined—requirements and descriptions of domains and phenomena). But framing still has to compete with other analysis activities. And the descriptions and requirements have to fit in with other behavioral descriptions analysts write. And at the end of the day, one of the tutorial attendees remarked, “Thanks for introducing problem frames to us, Rebecca. I’m not sure I am going to use them formally as an analysis tool, but I suspect just knowing about problem frames will help me write better specifications using the tools we already use.” We’ll see.

Then there is that sometimes difficult distinction to be made between specifying what the system should be vs. what it should do. People are slowly adopting techniques for specifying measurable non-functional requirements using Planguage. These ideas also compete with problem framing for mindshare.

Contrast framing with the agile practice of not writing down requirements (according to Gerard Mesazros who presented Agile Requirements with User Stories at Agile 2005, user stories are “an I.O.U. for a conversation”). Any agile person would throw up their hands and shout “enough! Just give me practical advice on how to apply framing techniques directly to what I do—and I’ll consider them. But I don't want to write a lot of formal descriptions.” Framing has to be more than a set of frame diagrams that lead to descriptions …or it isn’t going to find any audience the agile marketplace, even though I believe that framing is an invaluable thinking tool when having that conversation with the customer.

Those are some challenges I see. Coming up with practical techniques applying problem framing to complement and clarify the work busy people are already doing.

Loaded words

2005-10-10T15:32:00.000-07:00

What do you do when people react negatively to terms you use to describe ideas? If you are like one clever manager I met at Software Development Best Practices, you turn around and let the team take ownership of the way they are going to speak about things. This manager of managers in a health care company recounted how he introduced Scrum into his organization. After talking about Scrum values and practices, he got pushback on the names of Scrum activities. “Scrum? Sounds like a fight. We don’t like that. Sprints? Why the goofy terminology? We don’t like the sound of it. Sounds like people are always running hard. And besides, we’re not athletic.” So he asked his group to propose alternative names. Instead of sprints, his group calls them iterations. And yeah, they know they need to be short. They are following scrum practices; they just don’t call a spade a spade. He’s convinced that they are the better for it. It isn’t so important what they're called as how they're applied. They’ve even renamed daily standups. And they have them mid-morning so everyone can attend (as the team’s work hours are staggered).

Another case in point. At Agile 2005, Jon Spence from Medtronic presented an experience recounting how he got his company to adopt agile practices on a project. Medtronic makes defibrillators and pacemakers. It was somewhat tricky introducing agile concepts into his organization. Jon had to tone down the edginess of the agile message. He can’t imagine the Agile Manifesto hanging in the hallways at his company. For one thing, one of its tenets favoring, “Working software over comprehensive documentation” would be highly controversial. Medtronic builds FDA regulated products that require extensive documentation. According to Jon, the Agile Manifesto would cause an “allergic reaction” at Medtronic. He said he wasn’t going to bring back copies of it to pass around (they were handed out at the conference). No sir. Those would be fighting words. And Jon wants to avoid controversy so he can focus on introducing agile practices. What proved effective was talking about delivering code incrementally with higher quality using a balanced set of practices that provide a safety net. Those were the right words to convince management. His project delivered on their promises and he and others are now spreading agile practices to other project teams.

I appreciate powerful words that people can rally around. But they don't have to be edgy. By avoiding loaded words you can more effectively get your message across. If the agile manifesto doesn't have the right words for your organization (and you don't want to be branded a radical) you may need to discover different ways to talk about agile practices. It isn’t always necessary to use inflammatory words and shake people up to cause change.

It’s official...specs are “bad”

2005-10-06T05:56:00.000-07:00

…according to Linus Torvalds. I have to chime in on Linus’ newsgroup posting and the attendent buzz it sparked on the net this week (and on the Linux Kernel mailing list). Linus stated:

So there's two MAJOR reasons to avoid specs:
- they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None.
It's like real science: if you have a theory that doesn't match experiments, it doesn't matter _how_ much you like that theory. It's wrong. You can use it as an approximation, but you MUST keep in mind that it's an approximation.
Specs have an inevitably tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP.

He went on to conclude:

"But the spec says ..." is pretty much always a sign of somebody who has just blocked out the fact that some device doesn't. So don't talk about specs. Talk about working code that is _readable_ and _works_. There's an absolutely mindbogglingly huge difference between the two.

This posting launched an onslaught of discussion. Linus is right. Reality always differs from a specification of how software is supposed to behave. That’s a reflection on how difficult it is to write precise specifications of behavior and on how many decisions during implementation are left open . Still, I'm not willing to say "no specs, ever" even though I'm a signer of the Agile Manifesto and on the board of the Agile Alliance. We need to get better at recognizing what types of descriptions do add value and under what circumstances. And become more aware of when and where precision is needed (and when it drags us down).

Linus points out that specs often introduce abstractions and concepts that shouldn’t be directly implemented in code. I never expect to directly translate what someone writes into code without using my brain. I design and think before and during and after coding…and nothing substitutes for testing/proving out a design and implementation against the real environment it works in.

But that doesn’t mean specs have no value. Working, readable code isn’t the only thing that matters. It matters very much in the short and long term. But try understanding design rationale by just reading code. Or reading the test code. It's difficult, if not impossible. I find value in design documentation that explains the tricky bits. This type of documentation is especially valuable when those coding aren’t going to hang around to offer explanations.

A spec is an approximation of what is desired. I certainly don't expect it to tell me everything. There can be enormous value in writing descriptions of what software should do—especially when it is important to communicate design parameters and system behaviors instead of just providing an implementation. Most developers aren’t good at writing specs, let alone descriptions/discussions about their code and design choices. But that doesn’t mean they should stop writing them and resort to “organic code growth” in every situation. A firm believer in agile practices, I don’t insist in writing merely for fun or because it is expected. But if I need a spec, I write it. And if doesn’t reflect reality or is misunderstood, I change it if there is value in keeping it up to date. There may not be. And if that's the case, I don't update it. It depends on the project and the need. It helps if I write these descriptions for someone who wants to read them (and will actually use it rather than toss it aside). I've got to know my audience. That often takes experimentation. Maybe I need to include sample prototype code in addition to design notes/models/sketches. Maybe I don’t. Communicating ideas to a diverse audience is especially hard. But specs aren't the problem. It's that effectively communicating how something works or should work is more difficult than cutting code. I prefer working code over piles of outdated, difficult diagrams and explanations. But that doesn't duck the issue. Specs aren't inherently bad. Most spec writers would rather be doing something else. And that is a problem.

It's not OK..or is it?

2005-10-04T16:42:00.000-07:00

Inspired by the TV show Starved, which chronicles the lives of friends with eating disorders who attend meetings with other food-challenged folks (where inappropriate behavior is censored with the chant, “it’s not OK”), I imagine a support group for software agilists gone astray…

“Hi, I’m Dave and I don’t like to pair program. If I spend a few quiet hours alone before everyone shows up, I can get a whole lot more done.”
“Dave, it’s not OK.”

“Hi, I’m Beth and I prefer to sketch out my design before I write any code.”
“Beth, it’s not OK.”

“Hi, I’m Rick and I plan the work for my team and then show them my plan.”
“Rick, it’s not OK.”

Or is it?
I recoil from absolutes. The chant “It’s not OK” grates against my core values. Sure sometimes behaviors may be inappropriate, but there’s got to be a better way to address the issue. Imagine another world….

“Dave, you don’t like pair programming. I want our team to really try pairing. Maybe as a group we should tone down all our chatter. It can get pretty loud sometimes and that makes it hard to focus. If you really don’t think pairing is going to work for you, you can still be agile—but you might find it more to your style to work on the mark project. They’re writing unit tests, doing daily builds and have short iterations, but they’re not following all XP practices. One thing the mark team insists on instead of paired programming is to have paired checkins for all new modules and any changes close to the end of an iteration.”

“Beth, I like that you know UML and use it effectively. When you do draw design ideas everyone seems to understand thing better. I think you have a knack for making ideas understandable. When you take the time to sketch out what’s really needed, I suspect you save rework time. Maybe we should consider doing even more design pre-work for complex functionality. Let’s set up an experiment to measure the time we spend refactoring vs. the time we spend doing some upfront design for a couple of challenging user stories on our next sprint.”

“Rick, I like that you want to plan ahead. But instead of planning for your group, why not get them involved in planning? They’ll be more committed if they set their own goals…”

Hard line agilists used to say that until you know how to play by the rules don’t break them. But I think that hard line stance is changing. In the second edition of Extreme Programming Explained, Kent talks about core XP practices and ways to move towards your values. At Agile 2005, in a keynote Bob Martin talked about the trend of adopting agile practices from a "Chinese Menu". It is a better strategy to adopt agile practices that fit your development lifestyle. As any dieter knows, any successful eating plan has to fit into your lifestyle and work to your strengths. Some dieters can succeed eating a little chocolate each day. Some can’t. No food should be censored or out of bounds unless it's too difficult to handle.

The same goes for agile development practices. Deviations from typical (published) agile practices shouldn’t automatically be censored in a knee-jerk fashion. That’s counter productive. But don’t cheat on your agile goals, either. If you find a particular recommended practice too hard to adopt, ask why and dig deeper. Maybe that practice doesn’t fit with your team or your company or with the way you work. Maybe you’ve got to change something first. Or maybe it just isn’t a good fit. But if a particular practice causes you to stray from your goals, take a long hard look at why it’s counterproductive and how you might clean up your act. Sorting it out will require some honest thinking, experimentation, and reflection. And that’s OK.

Little things add up

2005-09-05T15:40:00.000-07:00

Being in the country, surrounded by fields and trees, my perennial garden requires constant weeding. A few nights ago I was out in the garden digging out some tenacious crab grass. At first I noticed pinprick or two on my arm and my legs itching. I ignored those slights and kept working. But after being bitten several times and feeling a persistent roving itching sensation around my ankles I stopped to investigate. A small army of teeny ants were streaming over my shoes, crawling up my pants legs, into my socks, over my gloves onto my bare arms… I ditched my shoes, socks, pants…and dashed inside. That ended weeding for the day.

I’m like that. I ignore little annoyances. Bug bites or a few scratches don’t stop me from weeding. I block out most distractions when intent on a task. It’s only when irritations exceed some threshold that I turn my attention to what’s bugging me. Otherwise small distractions, if I notice them at all, are easily brushed aside.

Software developers often have an unrelenting focus when tackling big meaty design problems. Little annoyances get brushed aside in the rush of making the design work. Who cares about those little bugaboos when exciting stuff is unfolding right before your eyes? And yet, those little things add up.

Why is it that we wait until there’s a persistent itch before we scratch it? I suppose it is human nature. If you let every little thing distract you, you’d never get anything done But design bugs don’t have six legs and initiative so they tend to hang around. If you don’t knock ‘em down and clean them up things can get really ugly. The more of them you have, the more difficult it is to get your design working. Yet when you’ve invested so much in your design you have to keep working at it (even if it would be better to scrap it and start afresh).

That why test-driven development is a big win. Writing tests first forces you to focus you on thinking about the interface before you design and code it. Making those tests work becomes a relentless way of getting observable behavior to work rather than letting crufty untested code pile up. But it isn’t enough. Writing a test is isn’t the same as testing for the quality of a design choice. Maybe that little design choice you just made should bug you (but it doesn’t) because you can’t tell whether it is just OK or what might make it better. If you are in this situation I have one bit of advice on how not to insert a little thing into your design that may end up biting you in the end:

If you find yourself writing code that asks an object whether it is in a certain state or whether it is capable of handling a request, and then turns around and asks it to do the right thing (based on its answer), think twice. This should bug you. There’s usually a better design choice that places the decision-making responsibilities inside the object that is being directed. A small example from my design course’s problem can illustrate. The problem is to create a design that sets the report interval for any kind of sensing device. Some sensing devices are “intelligent” and can be programmed to report at specific time intervals. Others have to be polled on a schedule. How should you design a controller that handles either case? A straightforward design might have a controller ask:

If sensingDevice.isProgrammable() then sensingDevice.setReportInterval(timeInterval)
else { /* code to add the sensing device to the poller at the timeInterval *}

My choice, instead, would be to would have the control code turn around and ask any device to set its report interval (and have the device make the decision based on whether it was programmable or not) to do the work. One line of control code with decision-making being done in the sensing devices:

sensingDevice.setReportInterval(timeInterval);

Instead of making explicit control decisions I always prefer delegating those responsibilities to objects that do things based on what type of thing they are. It makes for simpler control code and localized (encapsulated decisions). Objects that behave differently based on who they are and what capabilities they have can greatly simplify control code. Making objects smart can eliminate external decision-making.

I’m going to continue compiling a list of my favorite garden-variety design bugs and will be writing about more of them. If you have some seemingly innocuous design choices that bug you, I’d like to hear from you.

Exactly what do you mean?

2005-07-29T15:37:00.000-07:00

I spent the past week at the Agile 2005 software conference. What an amazing conference and inspiring group of people! I spent some time with Lynn Miller from Alias who presented a report about how her companysuccessfully integrated User Centered Design (or UCD) with agile XP (Extreme Programming) practices. Lynn is the lead interaction designer on an innovative product called Alias® SketchBook™ Pro. As an interaction designer, Lynn gathers customer information and defines and refines user features through prototyping and customer feedback. Lynn then feeds her designs to the development team who develop production quality code in month long “sprints”. At Alias, interaction designers work in tight collaboration with the development team, feeding them just-in-time interaction designs. According to Lynn, this is pretty unusual. Most companies do interaction design in all in one big lump before doing any software development. At Alias, interaction design is done monthly increments, just like the code. Each coding sprint is fed by features defined by the interaction designers who worked on them during the previous month. Skeptics in Lynn’s field don’t believe that usability design can be done this way without sacrificing quality. Alias’ success story challenges these assumptions.

As an interaction designer Lynn isn’t up on the latest agile jargon. So for the first couple of days at the conference she was puzzled when she heard stories about how other agile teams had trouble identifying and working with the “customer” who defined “user stories” that the team implements. To Lynn—and most people outside the agile community—customers are people who purchase products or services. How could you co-locate “the customer” with a development team? Don’t companies have many customers? What exactly was the problem some XPers were having? Only after a Lynn realized that XP defines customer as “an informed expert who clarifies requirements for an XP team” did her confusion evaporate. An XP customer isn’t necessarily an end user or purchaser of a product. Lynn plays the role of “customer” for her XP development team when she designs features. I agree with Lynn, the definition of an XP customer is confusing.

Lesson learned: Agilists who communicate with others outside their own community need to be aware that jargon is confusing. When someone looks puzzled it may be because they don’t share your context. Bridge this gap by asking a newcomer what’s unclear. Then take the time to “decode” insider jargon for them. You'll learn something about what they do and how they think in the process.

I discussed with Lynn and Jeff Patton (another talented user-centered designer)what we each mean by “design”. To me, a software designer, design means creating a model of interacting software objects that are implemented in code. Interaction designers use a raft of techniques ranging from contextual inquiry (to understand the users' work environment), to user-centered design (to cluster tasks and identify user categories), to interaction and user interface design. All these activities to an interaction designer are “design”. It was pretty easy to understand our different views and see how they dovetailed into an overall system design process. I don’t think we should come up with an unambiguous definitios for our various activities. Besides being unrealistic, we’d all have to start speaking design Esperanto—which wouldn’t be a good thing. But I learned something. When you don’t understand what I mean, it is my problem not yours. As a good communicator I should try to bridge my ideas into your context. And when you don’t understand what I’m saying, please ask, “What do you mean by that?”

Framing and Questioning

2005-07-15T15:47:00.000-07:00

As a mental exercise, two colleagues and I have been spending time uncovering and documenting the problem frames in internet email. It is nice to frame a complex, concrete example that has architecture descriptions readily available. We can compare what we come up with against the machinery that’s already been built. Initially, I didn’t want to know too much about how things really worked so I could stack up our frames against the architectural solutions that already exist. Lately I’ve discovered that by examining technical architecture descriptions, I can quickly frame new parts of the problem…which I can then use to loop back and try to understand the reasoning behind existing architecture.

Based on the problem we’re framing, we can also conveniently draw parallels between email and the physical world of postal mail. Today, Jim explained to Nathan the difference between local and internet based dispatching of mail by drawing an analogy to delivering mail within your house. If you address a letter to another family member, there’s no need to put it in mailbox, just hand deliver it. While the physical analog of postal mail is interesting, there’s a point where it is critical to drop it and focus on the problem at hand. Analogies only take you so far. But this got me thinking. How did the original architects of email find their inspiration? Did they create their solution based on perceptions of how the postal mail was handled? And if they did, when did they break away from that mental model and do the really heavy mental lifting needed to finish their design?

To me, an important aspect of framing is the questions it leads you to ask. Answering those questions helps you make design decisions. But even when looking at an existing technical design, framing has value. You can question why things are as they are and what problems were being solved. For example, in Qmail why are there two mail delivery strategies---one for local and one for non-local email? Presumably, because local messages can be processed faster and cheaper. Which leads to asking whether this is really necessary or a holdover from earlier computing days? Thinking for a bit, we enumerated a number of reasons why local mail can and should be handled differently than remote mail. (No need to check for spam, no need to go to a domain name service to get the host to transfer to, processing can continue when the parts of the internet are down…). In short, local email can be processed much more efficiently and outgoing mail should be processed much more reliably…they are two different concerns that shouldn’t be lumped together into the same solution. Problem frames can help you focus and subdivide a problem into smaller ones. I want to continue to wade deep into software machinery and critically examine whether framing helps me understand the nature of problems. I’m concluding it does. So far I’m not inventing anything, just exploring known territory. But even there I find value in framing and then asking why. Makes me feel like a two-year old, but then again, maybe not…analogies only go so far.

The World's Smallest Software Development Quiz

2005-07-05T17:19:00.000-07:00

A couple of weeks ago a friend sent me a link to the Word’s Smallest Political Quiz.
If you answer 10 questions on personal and economic issues (with possible answers being yes, no, and maybe), you’ll get rated on whether you are a Liberal, Centrist, Conservative, Libertarian, or Statist. I passed the link out to a few friends and family members and said I’d report my test score if they’d tell me theirs. Needless to say it was interesting…I’m married to a libertarian, have a centrist brother, and have raised two liberals. When I take the test (depending on my mood I answer questions differently) I’m either a liberal or a centrist. I lean towards supporting significant personal liberties but believe in the value of some “governmental control”—especially where environmental issues are concerned.

This political test got me thinking about concocting a similar test for software development processes to ascertain whether developers are agile, centrist, traditional, anarchic, or formal. I’ve been reading too much agile and traditionalist bashing on newsgroups lately. It’s time that software folks call a truce to name calling and make a concerted effort to understand what’s driving their differences and what values they may have in common (even though they are in different camps).

I see software situations where more formality is needed. I also see situations where agile approaches would definitely inspire teams. At some places, the development processes seem to work, but development still proceeds slowly. I’m not sure whether agile practices would speed things up. They live in a complex world with lots of rules and regulations. On the other hand, I’ve definitely seen places where testing for quality at the end of a long development cycle definitely hurts their delivery. And I’ve visited other places where any process or project documentation would be better than what they have now. Still other groups seem to thrive on rolling their own software without much thought to process at all. Maybe instead of centrist, I should be labeled “chameleon”. What works depends on circumstances and your group and organization’s leanings.

However, there seem to be two fundamental axes that divide software process beliefs: predictive versus reactive planning, and evolutionary design/development versus targetted (or planned) design/development. (I plan on exploring the differences I see between evolutionary design and incremental design in the future. But from my vantage point there is a big difference.)

What agile folks believe and more traditional folks believe isn’t that different in some areas. Both tend to value teamwork and process. Anarchists don’t. Neither do formalists—they tend to value the formalisms over any process that gets them to those formalisms. It is just agilists don’t place high value on document or pre-work (be it design, extensive requirements gathering, prototyping), etc. The lines between code and design are very blurry. I’m still working on questions that will draw out more of these distinctions.

Comparing Design Notes over Coffee

2005-06-30T13:44:00.000-07:00

My architect friend Ken and I had coffee the other day and caught each other up on the latest trends in our fields. Ken and his wife designed our house. Ken and I like to talk about meaningful design processes (me about software, Ken about buildings and homes) and learn from each other’s experiences.

I explained to Ken the new trend in software called agile development which emphasizes teamwork, close customer involvement, evolutionary design, programmers as designers, and incrementally delivering value to customers. On a typical agile team there isn’t much distinction between designing and programming. Design is viewed as something that is constantly happening while you are coding. In fact one view held by extremists that I find somewhat disturbing is to equate any design up front as being the same as Big Design Up Front which is equated with being wasteful. Since you will change your ideas during implementation anyway, why invest any time inventing pie-in-the-sky solutions? (In case you can’t tell, I take a more moderated view—it all depends on the situation and the context. I believe a little upfront design never hurts, and sometimes more is needed).

More traditional processes tend to divide development into phases: problem requirements are gathered and analyzed, solutions are designed and implemented. Although even that description is too simplistic. The Rational Unified Process talks about overlapping phases and delivering incrementally. So what’s the big difference between agile and more traditional approaches?

One big difference between agile and more traditional approaches is what stands between the developer and the problem. Traditional software development teams have analysts or business architects who gather requirements, write them down, and then work closely with developers/programmers who implement the software. These people hold the torch for what the user needs and wants (and can afford) throughout the process. The good analysts I know are skilled at talking with users and business experts and at translating their requirements into terms that developers understand. They bridge the complex world of the business and the detailed world of the programmer. On agile teams, developers work directly with their “customers”. Middlemen are eliminated. As little documentation as possible is created. There’s direct, open communication. The software design takes shapes in a very organic manner. Things are not planned out to the nth degree beforehand.

Ken noted that a similar trend in building architecture, especially the environmentally friendly architecture that he’s interested in. There’s the traditional design process which Christopher Alexander believes makes for lifeless buildings, and the more organic, buider-as-designer process (which is a haven for old hippies, according to Ken). It is into this world divided into disparate camps, that Ken wants to bring his creativity and vision. He’s worked in a big architectural firm and felt far removed from the customer’s needs. On the other hand, do-it-yourselfers tend to not want help. Where does such a passionate designer like Ken fit in and make a living? I told him he has to find a new market and educate potential customers on the benefits of taking responsibility and engaging in the design of their environmentally friendly homes with a designer like him.

I told him I find myself in a similar situation. But I haven’t had to create a totally new market. More often than not, I work with those who follow fairly traditional development processes. There I add value by talking about responsibility-driven design. I also help people who want to build flexible, well-designed systems get more skilled at articulating what they want and how to build it. I also try to bring a spark of agility to their processes—finding ways to simplify heavy-handed processes, streamline documentation, and communicate more effectively. I’d like to spend more time with agile teams helping them bring their design skills up another notch while programming like crazy. But so far, that opportunity hasn’t come along.

I’m always fascinated by the parallels between software and the architecture world that Ken and I find whenever we have time for a cup of coffee. My next challenge will be to absorb some of Christopher Alexander’s latest writing (but Ken has warned me that his four volumes are not light reading) before I have another conversation with Ken.

Why Objects?

2005-06-14T12:40:00.000-07:00

As I’ve been working on a position statement for an OOPSLA panel reflecting on the roots of modern software development practices while looking to the future, I’ve been thinking hard about why I got hooked on object technology. Compared with structured programming and design, objects seemed significantly better at handling complexity. Object programming languages were an earth shattering improvement over the procedural and assembly languages I used when I first encountered structured design techniques. Instead of simply following conventions, object programming language constructs forced me to bundle together meaningful operation and data. Object-oriented methodologies generally incorporate the principles of structured design but OOD seems much more than an incremental improvement over SD. Instead of focusing on a thread of control and managing its complexity via procedural decomposition and structured control constructs, object design enables me to break a composition into thousands of semi-autonomous entities with structured roles and responsibilities. Objects offer me a completely different way to think about computation. This way of thinking empowers me to deal with a level complexity that I could never have dealt with only using structured design techniques. Object technology encourages me to form abstractions—objects—and to design how small neighborhoods of them interact.

Responsibility-driven design offers thinking tools that enable developers to conceive of an implementation in terms of interacting roles and their responsibilities. It provides a vocabulary for describing designs that helps developers communicate complex ideas and make tradeoffs more effectively. Agile practices, by emphasizing working code that satisfies customers, seek to reduce accidental complexity by admonishing you to design simply and grow complexity only when needed. Eric Evans, in Doman-Driven Design: Tackling Complexity in the Heart of Software, offers tactics for identifying, preserving, and sharing a common domain model. Refactoring tools have taken tediousness out of making changes and modern application development environments have made it possible for development teams to “hum” by testing and building incrementally. These all represent progress.

But at the end of the day, they cannot reduce the complexity inherent using diverse tools, platforms, and technologies that make up a typical sprawling IT system. While OOD/OOP did give us an order of magnitude improvement over previous techniques and tools, we still don’t have the order-of-magnitude better approach we need to sort today’s complex environments and minimize the gaps and seams that are inherent when diverse technology comes together in a complex system. In the meantime, thank goodness for the framework builders who give us various ways of linking objects with relational databases and for little languages and tools that take the tedium out of repetitive (error prone) tasks of gluing things together. We live in a complex world where objects will continue to make a lasting, significant contribution. What will be the next breakthrough in software development that will subsume the principles of OOD (and transitively SD) and provide the next order of magnitude improvement? I’m not sure. While I don’t think there are any silver bullets out there, I look forward to discovering and encountering even more effective practices, technologies, and techniques that allow us to address inherent complexity head on.

Don’t Look for Grisgris

2005-06-13T14:29:00.000-07:00

Gris-gris
African fetishes, charms or amulets.
Objects believed to have magical or spiritual powers to protect against evil or injury.

I received an email from a colleague pointing out a blistering critique of object technology in an article by Richard Mansfield, OOP Is Much Better in Theory Than in Practice, and a website devoted to defrocking object-oriented myths. The article starts out on this gloomy note and only gets more negative:

“Think object-orient programming (OOP) is the only way to go? You poor, misguided soul. Richard Mansfield contends that OOP is just the latest in a history of ideas that sound good in theory but are clumsy in practice.”

My colleague found this rant rather depressing. He has assumed for years that modern systems are ideally coded using OOAD---but still has struggled to make it happen in his own projects. He asked, what do I think of this kind of criticism?

Here’s my take. Any one who raises questions and concerns is good to listen to. There certainly initially was a lot of hype around objects. In the early days it was oversold. On the other hand, many of Mansfield’s comments remind me of someone who likes take broad swipes at something just for argument’s sake as well as someone who tweaks things for database performance. For him, objects get in they way. He’d much prefer to build software machinery optimized for relational database access. Reminds me of the classic ACM Article by Donald Knuth extolling the virtures of GOTO statements. GOTOs are useful sometimes. Objects, in my experience are even more useful---but not universally so. I know lots of people who have benefited from doing the hard work of creating a design with reusable classes with planned variations. Creating a model of interacting objects is hard intellectual work. Writing piles of code with cut-and-paste reuse is easier. It just is harder to maintain. I also know people who don’t see much benefit of objects because most of the code they write simply shovels data to and from a database with little behavior other than validity checks in between. While they may use objects to create GUIs and get results back from the database, they rarely invent objects of their own. And unfortunately, object programming languages still don’t co-exist very neatly with relational technology.

The value of object programming and design is apparent when you have significant behavior in your application and you create a model of interacting objects that does some significant work. Sure, you don't need objects, just like you don’t need high level programming languages. But objects can sure come in handy. To discount the benefits of object-oriented designs simply because people don’t create good designs using them (another one of those correlation=cause false arguments in this anti-object writing) isn’t a rational argument. That’s like saying diets don’t work because fat people diet! There are also tangible benefits to developers who leverage extensive class libraries to build complex systems. I would hate to have to build all the complex software we do today without them!

I thanked my colleague for pointing me to this website and article. I'm going to give them a more careful reading which will probably result in some blog entries, if nothing else. Untangling any truth in a rant from fallacy is always good practice. But at the end of the day, we shouldn’t be looking for grisgris to be universally applied with blind faith to ward off all software ills. Instead we should be looking for solutions that work well for a given situation. I find objects a pretty good tool for a wide class of problems. In my own modeling and design over the last two years I’ve also looked at creating solutions using declarative approaches and seen how rule engines and objects mix (not very well unless you are very skilled at abstracting and writing generic rules with lots of meta-context). The value of objects hasn’t dimmed; my toolkit has simply expanded.

The Cost of Inertia

2005-06-08T19:13:00.000-07:00

Last week I closed out a safety deposit box that I had rented but hadn’t touched for over 20 years. In theory, I paid for the box to hold tax returns and valuables, but never visited it after placing some “starter” something into it when I opened the account (what was it?). The bank branch in our town had closed years ago and the safety deposit box had been relocated to a branch in a nearby town. So I had to drive 6 miles for this little errand. I was damned if I was going to pay $39 for another year’s rental!! For some reason, I decided to take action. I’d rather donate the fee to the Oregon Food Bank, instead of lining the pockets of a bank. To my amusement, the box had 3 coins in it—2 Susan B Anthony dollars and a 500 lire piece. Over the years those coins have cost me $600.

Why did it take me so long to stop paying my annual fee and clean out the box? Plain and simple: inertia. As defined by dictionary.reference.com:

The tendency of a body to resist acceleration; the tendency of a body at rest to remain at rest or of a body in straight line motion to stay in motion in a straight line unless acted on by an outside force.
Resistance or disinclination to motion, action, or change.

In the busyness of life it’s all too easy to let things slide rather than fix ‘em. I didn’t miss that $39 in my pocket, but I didn’t like paying for something I wasn’t using, either. As a small act of, well, determination, I took an hour out of my busy day and “fixed” the problem. Over the past year I’ve shut down my unused dialup service (saving $10/month, and readjusted my banking to eliminate most monthly fees). Now if I could figure out how to get my phone company to coalesce my home and DSL lines (that’s a long story not worth recounting here), I’d save myself another $300 per year. But two painfully long phone calls to my phone company haven’t fixed things yet. I’ve got to muster some determination before I try again. Every so often I get the itch to cut out waste.

I had lunch today with a software manager who described some costs of inertia in her organization. Inertia that makes for tedious retyping of data from one system into another instead of writing software that could handle the majority of data transfers. Inertia that keeps a 30 year old system chugging along, even though it hasn’t aged gracefully. Most software, as it ages, gets more complex and more difficult to maintain.

There’s a cost to inertia. In my case, a few hundred bucks a year. In companies with inefficient processes and creaky software, the cost can be quite high—in dollars as well as the expense of people working at tedious (unnecessary) tasks. Lean software development practices aim to strip away “excess waste” in processes. But applying lean thinking to legacy systems and maintenance projects isn’t nearly as cool as using it on new initiatives. I wish it were. There may be no glory in chipping away at cruft built up because of inertia. But there should be. At the end of the day you will have left the world in a slightly better state. I know I have. My check to the food bank is in the mail.

Timely events in Use Cases

2005-06-01T10:14:00.000-07:00

Last week in a use case writing course I was teaching, a student presented me with a use case where he had been puzzling over how to accurately express the passage of time. His use case occurred over a period of several days and went something like this

Day 1:
The user does this
And this
And the system does this
Day 2:
The system does this
Another action..
Day 3:
The system does this
The user does this
And then things are finished by…

Although it accurately reflected the passage of time in the current system, he wasn't satisfied with it. He wanted to describe a new version that could be more responsive. Instead of waiting for nightly data feeds, what if the system could process data more quickly? Expressing this in terms of time passing (day 1, day 2, etc.) seemed too concrete and limiting. After probing a bit, I suggested he consider restating this passage of time as “events” that enabled the use case to move forward. For example, “Day one” could become “Prediction made”, “Day two” could become “Project Completed”, and so forth. This shift in thinking--from describing elapsed time to describing events in a complex process--brought clarity to this use case and will influence the system re-design.

People can get bogged down because they don’t know how to express passage of time or lengthy pauses in action. Some might be tempted to “fix” the above use case by splitting it into three smaller one with appropriate pre and post conditions. That technical solution would only obscure the user’s overarching goal.

My eventful solution, another alternative, was inspired by Michael Jackson’s Problem Frames. Jackson emphasizes that “the point of software development is to build machines that interact with the world and change it.” Jackson is big on describing problems in terms of domains and software “machines” having direct interfaces where shared phenomena flow between them. He cautions, “Don’t think of an interface as a queue or pipe or stream of messages flowing between the domains; instead think of events and states and values as being shared between the connected domains. Each interface is an interface of shared phenomena.” This notion of shared phenomena has been difficult for me to wrap my head around. I don’t typically think about what’s going out there in the world when I'm focusing on writing usage descriptions. But Jackson’s viewpoint is slowly starting to influence my thinking. Sometimes eventful interjections can help explain why the user or the system is doing what they are doing and lift you out of writing uninformative “skin level deep” descriptions.

Rock, Paper, Scissors--oh Sh#$%!

2005-05-31T15:03:00.000-07:00

What’s your reaction to errors in a technical book or article? If you are like me, you discount the writer’s words if there are too many errors. If I find the topic interesting, however, I ignore infrequent errors and plunge ahead. But sometimes errors impede understanding. In that case, it’s always good to ask what the author meant to say. From time to time I get emails from readers tripping over errors in my own books. I try to thoughtfully answer their questions. Let me share a recent query:

Hi Rebecca,

I'm a little confused with your paper, rock, scissors example and the errata for your Object Design book. I figured out there seemed to be a problem when I got to figure 1-9. I went looking for errata. But the errata seem to have a problem too! For page 21, it mentions figure 1-9, but figure 1-8 is on pg 21! I'm not sure whether the page number is wrong, or the figure.... I'm assuming the figure. But beyond all that, I don't understand the purpose for three added methods beatsRock(), beatsPaper(), and beatsScissors(). Since a rock only calls beatsRock() and a paper only calls beatsPaper(), then why do we need three methods in this interface? Why not just have a "beatsMe()" method that is defined for the particular class being defined? Any clarification would be appreciated.

This reader had every reason to be puzzled. Not only did the example in my design book have a coding error, but the accompanying sequence diagrams did too. Even more frustrating, the errata referenced the wrong figure. After acknowledging the reader’s concerns, I went on to explain at some length that the purpose of this rather contrived example was to illustrate how double dispatching works. While indeed, the answer could’ve been implemented in a single method, that wasn’t the point. Instead it was to illustrate that double dispatching eliminated the need for case or switch statements. Double dispatching (whether you think it is a good idea or not) is a tricky enough to grasp even without the typos!

I didn’t intend to purposefully introduce errors. They crept in because writing and editing, like coding, require concentration and attention to detail. Because I’m human, I’m not perfect at tasks like these. Most people aren’t. With material that you are overly familiar with, you tend to read into it what you meant to say, skipping over small mistakes without even seeing them. One way I’ve found to force my brain to look at text or code with a fresh eye is to read it from the bottom up, one sentence or expression at a time. This shifts my perspective, allowing me to see errors more readily.

When others revise your work, there are even more opportunities for introducing error. Overzealous copyeditors introduce errors because they don’t believe you would want to say something that way (you couldn’t have meant OffF(i), so I’ll just change this to Off(i). Never mind that OffF(i)—for Off-Floor-i—was exactly what you intended). I understand why some insist on typesetting their own books and compiling every line of code. An author has to be really on her toes to catch those ‘thoughtfully’ induced errors. These can be especially difficult to detect because our brains skip over infrequent mistakes, especially when we “know” what is right. Fortunately, the more errors there are, the easier they are to spot. But first the fact that they exist has to be brought to your attention.

Ever wonder why pair programming is advocated by Extreme Programmers? It’s not because geeky software types as a general rule like to socialize, but because one can spot another’s mental lapses. Ever wonder why test-driven development is catching on? Tests force you to think through the functionality you want to implement with a fresh viewpoint, catching errors in your thinking before you code.

The next time you spot an error in a book or an article, consider letting the author know about it. I know I would appreciate hearing from you. Your comments make me a better writer (and you a more actively engaged reader).

Whole Systems Thinking and Pesky Details

2005-05-11T13:27:00.000-07:00

I wasted an hour today trying to get an email signature line just the way I wanted it. The mail program I use is Eudora. I use it in paid mode. I’m not picking on Eudora so much as I am picking on the state of software tools in general (I’d love to hear your favorite tool horror).

I wanted to create several different signatures for different occasions…one for marketing to local clients, one that is just my “standard tagline”, etc. As part of my signature I wanted a line that included links to my website and blog on a single line:

website: www.wirfs-brock.com blog: www.wirfs-brock.com/rebeccasblog.html

That worked just fine for my standard signature file, where these were the only links. But then I wanted to create another signature which included these links followed by lines with links to upcoming public classes. Each class would be listed on a single line containing a link to the registration page. When I inserted these lines into my file, I encountered problems. The signature looked just fine when created and displayed as I was composing email. But somewhere in the process of sending and receiving the email, that first website link got mangled. I had encountered yet another case of what Scott Meyer’s refers as the keyhole problem. I still don’t know if this is a send or receive error, but trying to fix this problem drove me nuts.

Instead of a well-formed link, the link in incoming email was extended with spaces, breaking it. Needless to say, being a software geek, I vowed to tame this problem. I perform twenty or so different experiments over the next hour. I inserted tabs instead of spaces between my website and blog link. This worked, but the formatting was ragged and I don’t like inserting tabs into messages as some people’s mail systems don’t uniformly display text with embedded tabs. I put the website and blog links on separate lines. This worked, but it made my signature longer. I inserted one tab and spaces after the website link. This worked but had resulted in a ragged signature line that looked unprofessional. I copied the line with the links that worked from my other signature file and pasted it into the second signature one (of course this didn’t work, what was I thinking?). I tried re-specifying the links (this didn’t work either). I moved the broken-linked lines to after the single link lines in my signature file . This largely worked, too, except the spacing between the website link and the blog link came back with an extra space between them (making it a ragged line).

I then got the bright idea of creating a signature file in a fixed font, instead of Ariel. This worked. But I didn’t like how Courier looks. Too clunky. When I changed my signature file back to a font more appealing than Courier, Eudora apparently let me change my signature file, but it refused to pick up the new font information as specified in that file. Even rebooting my mail program didn’t correct the problem (obviously it was caching the font style and not really looking at the font specified in my signature file). I was headed even deeper into the weeds... At this point I decided to give up as I had several approaches that would work OK, even if they didn’t let me format the signature file exactly as I wanted.

All the trouble I had making a signature file made me want to chuck Eudora and move to another mailing tool. But I haven’t, just yet. I’m a healthy skeptic. Each software tool I use has its own peculiar quirks and annoying irritations. (But send me some convincing arguments about why I should move to another mail program and I’ll seriously consider it). Is this because developers are lazy or don’t care about quality? I suspect that most developers do not purposefully go about building quirky software. Yet somehow quirks creep in. There are myriad reasons. For one, most software is developed by teams. Each person has their own piece to implement and the system as a whole isn't "owned" by anyone. This traditional view of software development is changing with agile teams. Collective ownership, one of XP's core practices emphasizes teamwork. The more eyes that look at code, the better. But still, you need to pay attention to the system as a whole, even while paying attention to details.

You cannot eliminate these all bugs, but you can certainly waste time writing dumb little unit tests that don’t add any value. Uncovering quirky system behaviors requires spending your testing time wisely. It isn’t enough to write one simple test and declare, “setting up a signature file” seems to work. My quirky bug spanned multiple contexts—composing a signature file, sending email, and then receiving correctly formatted mail. Exploratory testing is a practice worth considering. It involves spending some time poking around, looking for stuff that just might not work. But developers need to take more responsiblity for overall system quality, too. Just checking that your code works isn't good enough.

Good enough domain models

2005-05-02T18:05:00.000-07:00

Eric Evans talked about Domain-Driven Design at our Portland SPIN meeting Wednesday. Eric’s thesis is that unless you capture the “ubiquitous language” that people use to talk about the functions of the business and create a domain model representing object concepts, you are developing software at wrong level of detail. Instead of talking about Shipping Routes, Legs, and Itinerary, you’ll be talking about “creating rows in the stop table” for each port along a shipping route. Why create Itinerary and Leg objects when you can get by stuffing a database table with “stop” records? Because it makes other parts of the system easier to program. Re-routing cargo gets easier if you can remove all Legs after a particular destination and splice one Itinerary onto another one. Lack of a domain model can severely limit the effectiveness of software (and make it hard to maintain systems and add new functionality).

Creating a domain model is more complicated than just capturing the language people use to talk about system functionality and creating software objects with appropriate names. In complex software, development teams often work on different sub-problems. Each subsystem may need its own model. Meanwhile, subsystems and teams still need to define appropriate ways to communicate with each other. In addition to ubiquitous languages, you need to define the appropriate common languages for inter-system/inter-team communication. Nothing is ever easy!

Eric’s masterful talk motivated me to ponder about why developers often end up with muddy models instead of ones that more clearly incorporate domain concepts. Eric says that domain modeling isn’t looking for a perfect model, only ones that are “good enough” to support the hardest problem well. Why don’t more development teams end up with “good enough” models? I suspect there are many reasons. What constitutes “good enough” can be so subjective that people don’t want to get bogged down. They give up and take the easiest paths—not the simplest ones. For lack of a good object to relational mapping tool, some developers may compromise on database tables being “good enough” approximations to classes. And their models get compromised. There are many reasons why software falls short of capturing “ubiquitous language” in a domain model. I suspect that a big reason is that it isn’t always obvious that a model is needed. If your code shuffles data back and forth from the UI to a database with few edits…why create a model? Only when there is significant behavior and computation, does a model pay off. Now if we all could agree on what “significant” means. If you have ideas about what constitutes significant enough behavior to warrant a model, I’d like to hear your thoughts.

Lava Flows, Swiss Army Knives, and Boat Anchors for the rest of us

2005-04-13T10:19:00.000-07:00

I’ll be the first to admit that I’m an object geek. But sometimes good ideas from the object community get lost because they are wrapped up in the mystique of objects. Consider the architecture anti-patterns described in AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis or the Portland Pattern Repository.
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 avoid or remedy it. The point isn’t so much to say “don’t do this” as it is to say “you probably don’t even realize that you’re doing this, but it doesn't work, and here are some things you might do to fix things.” In a recent workshop I conducted for architects working for a state agency, I presented the ideas of anti-patterns to this veteran group of developers. We had a great time identifying anti-patterns they encounter and deal with on an ongoing basis. Most of these architects were not using object technology…but they could spot good decisions gone bad when they saw them. We discussed several examples of Lava Flows, why they occurred, and why sometimes it may not even be a good idea to clean ‘em up. What if your code is subject to changing legislative regulations? Arguably, it may be easier to leave in some code than always be shuffling things around. Especially if you are living with a shrinking budget and staff. On the other hand, if you can cut out bad practices and eliminate confusion of why that “three hundred byte record” is there, removing a lava flow can make it easier on the architect who doesn’t repeatedly explain how to step over it to new staff.

I’m on the look out for object biases in the way I talk about design. I’m hoping to bridge the divide between “those in the know” and “those in the know who use objects.” We have much to learn from each other.

Problem Frames and an Eager Designer

2005-04-12T13:11:00.000-07:00

The past few weeks I have been participating in a book study group on Michael Jackson’s Problem Frames: Analyzing and structuring software development problems. Problem frames are a concept that Michael Jackson (the UK software analyst, not the courtroom celebrity) invented to characterize classes of problems that computer programs solve. According to Jackson,

"A problem frame defines the shape of a problem by capturing the characteristics and interconnections of the parts of the world it is concerned with, and the concerns and difficulties that are likely to arise. So problem frames help you to focus on the problem, instead of drifting into inventing solutions."

Problem frames are lenses you apply to look more deeply at a problem. If you know what type of problem you are looking at, you can ask intelligent questions and make tighter specifications for how your software should behave and how it should interact with things in the world. Being a designer, I’m always looking to solve problems. Yet it is true that mixing up problems with solutions can cause interesting communication problems and disconnects.

Consider this statement from a Canadian farmer about the trouble with daylight saving time: “Chickens do not adapt to the changed clock until several weeks have gone by so the first week of April and the last week of October are very frustrating for us." OK, I’ve gotta ask, do chickens really understand changed clocks? Of course not. The problem isn’t that chickens can’t adjust to the changed clock. The problem is that farmers’ sleeping and waking habits shift as a consequence of daylight saving time. The chickens still are disrupted, but only because the farmers have adjusted their behavior. Let’s not mix up cause with effect.

Jackson’s book is full of examples that exercise the muscles in your brain that help you untangle cause from effect and explore how much of the real world you have to understand before you can specify how your software should behave. It has been novel for me to take several steps back in order to deeply understand the nature of a problem. Be aware that I have a healthy skepticism for “big upfront analysis” just like I do for “big upfront design”. I don’t think the right approach for me is to spend lots of time deeply pondering problems before I start thinking about solutions. But l hope to apply Jackson’s ideas and deep insights on problems into practical advice and recommendations for those who aren’t keen on formalisms. Stay tuned.

Speculative Design

2004-12-21T18:26:00.000-08:00

Incremental design isn’t always the best way to tackle really hard design problems. Sometimes you need to explore the territory ahead before you commit to a solution. I have a client who has been rolling out a complex business system over several years. They have several production releases a year. Yet at the same time they’ve also investigated design solutions for future releases. Over the past year, they’ve worked out some key design ideas and implemented several prototypes that demonstrate how to solve some complex processing. Some of these prototypes have worked their way into production; some have been stopped after lessons were learned; others are still in the “speculative pipeline”. How have they managed to successfully balance this speculative work along with production release work?

A major key to their success was to not tie any speculative design work to any specific production release. Keeping this work off the production schedule has let them explore some ideas that required some heavy mental lifting, research and prototyping. But they have been disciplined about this work, too. Speculation isn't another name for "noodling around". Here are some practices that seemed critical to their success: Defining concrete, realistic scenarios to drive design efforts. Having a knowledgeable leader/practical visionary set goals and monitor progress. Tackling thinking and design work in managed increments. Measuring progress. Knowing when to stop pursuing an idea. Delivering value—whether it is a description of an algorithm, a partially thought out object model, a working prototype, a summary of lessons learned, or all of the above—on a periodic basis.

I think teams can be successful at speculative design if they take a disciplined approach. If you have found ways to successfully balance future design while at the same time incrementally developing production software, I’d like to hear from you. What worked, what didn’t, and how did you find the right balance?

Notes from a Responsible Designer

2004-12-20T10:40:00.000-08:00

Today is the first day I'm officially blogging. In this blog I hope to explore issues and share experiences about software design: what it is and isn't; how successful teams approach design, and how good designers think about problems and solutions. One student in a recent object design class I taught said that what he learned just seemed like common sense. I was really pleased with that comment, and remarked that common sense, unfortunately, isn't that common. In this blog I hope to share some observations on that creative process called software design...and impart to others some common sense ideas I have bumped up against over the years.