My old blog and contents have been converted to wordpress. You can find this new blog at wirfs-brock.com/blog.
I find that tagging and categorizing are a good way to organize my blog writings and like the features that wordpress offers.
Now that I have a fresh start, I plan on writing more….
-Rebecca
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.
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…
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 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.
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).
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.
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.
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 Welickiand 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 software trends might be. At OOPSLA I presented a keynote, What Drives Design? that I’d spent the last five weeks working on. 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 at 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 over 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” tradeoffs 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.
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.
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.