This blog has moved

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

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

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

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

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

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?

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.