Software Design and Development is Fun???!

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

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!

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

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

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

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

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

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