• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)

Date: Monday, 26 Oct 2009 23:31
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.

Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Thursday, 13 Aug 2009 16:04
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...
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jun 2009 16:55
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Monday, 08 Jun 2009 15:12
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).
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Tuesday, 03 Mar 2009 00:25
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Thursday, 29 Jan 2009 04:25
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Monday, 03 Nov 2008 22:05
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?
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Friday, 19 Sep 2008 00:33
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Thursday, 21 Aug 2008 02:02
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Tuesday, 19 Aug 2008 23:07
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).

Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Monday, 16 Jun 2008 04:49

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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Sunday, 20 Apr 2008 17:18
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Wednesday, 20 Feb 2008 01:39

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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Wednesday, 20 Feb 2008 00:55

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!
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Saturday, 03 Nov 2007 02:05
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
“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).
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Wednesday, 17 Oct 2007 01:04

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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Tuesday, 18 Sep 2007 02:38
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Friday, 29 Jun 2007 01:18
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Nuances   New window
Date: Thursday, 17 May 2007 19:16
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.
Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Date: Thursday, 19 Apr 2007 16:15
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!

Author: "noreply@blogger.com (Rebecca Wirfs-Brock)"
Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader