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…

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.

It’s really Wong Design….

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!

Start Me Up…

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

Customer service that works!

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

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

Try this procedure for re-training your receiver:

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

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

It’s official…specs are “bad”

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

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

He went on to conclude:

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

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

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

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

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

Notes from a Responsible Designer

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