A Programmer’s “Breadboard”?

I’m a fan of rapid feedback. When I write software, I prefer to find out if I’m on the right track as soon as possible.

There are all sorts of techniques I’ve tried for getting customer feedback without having to go to the effort of delivering production-quality software, which is a time-consuming and expensive way of getting feedback.

I’ve tried UI wire frames and storyboards, which do tend to get the message across, but suffer from two major drawbacks: one is that we can’t run them and see if they work on a real problem, and the other is that we have to commit to a UI design early in order to explore the logic of our software. Once a design’s been “made flesh”, it tends to stick, even if much better designs are possible.

I’ve tried exploring with test cases – examples, basically – but have found that often too abstract for customers to get a real sense of the design.

The thing I’ve tried that gets the most valuable feedback really is to put working software in front of end users and let them try it for themselves. But, like I said, working software is expensive to create.

In the 1990s, when Rapid Development was at its peak, tools appeared that allowed us to “slap together” working prototypes quickly. They typically had names with “Visual” or “Builder” in them, and they worked by dragging and dropping GUI components onto forms or windows or panels, and we could bind those controls to databases and add a little code or a simple macro to glue it all together into something that kind of sort of does what we need.

Then we would take our basic prototype to the customer (sometimes we actually created it in front of the customer), and let them take it for a spin. In fairly rapid iterations, we’d refine the prototype based on the customer’s feedback until we got it in the ballpark.

Then – and this is where it all went wrong – we’d say “Okay, great. Now can we have £500,000 to build it properly in C++?” And they’d say “No, thanks. I’m good with this version.” And then we’d ship the prototype that was made of twigs and string (and Visual Basic for Applications) and live with the very expensive consequences of allowing a business to rely on software that isn’t production quality. (Go to any bank and ask them how many Excel spreadsheets they rely on for enterprise, mission-critical applications. It’ll boggle your mind.)

The pioneers of Extreme Programming learned from this that we should never put working software in front of our customers that isn’t production-ready, because if they like it they’ll make us ship it.

Sketches don’t suffer this drawback, because we very obviously can’t ship a drawing on a whiteboard or in Visio. (Although we did try briefly in the late 90s and early 00s.)

Now, in electronics, it’s possible to create a working prototype that is very obviously not a finished product and that no customer would tell you to ship. Here’s guitar pedal designer Dean Wampler showing us his breadboard that he uses to explore pedal designs.

This is the thing with a breadboard guitar pedal: you can plug a guitar into one end and plug the output into a real guitar amp and hear how the pedal will sound.

It looks nothing like a finished pedal you would buy in a shop, and you certainly couldn’t take it on the road. A production-quality Wampler pedal is much smaller, much more robust and much more user-friendly.

wampler

Of course, these days, it’s entirely possible to design a pedal on a computer and simulate how it will sound. Some guitar amp manufacturers design their amps that way. But you still want players to be able to plug in their guitar and see how it sounds (and how it feels to play through it, which is tricky with software simulations because of latency.)

So breadboards in guitar electronics design persist. There’s no substitute for the real thing (until virtual breadboards catch up).

And this all got me to thinking: what do we have that’s like a breadboard?

Pictures won’t cut it because users can’t run a picture and play around with it. They have to use their imaginations to interpret how the software will respond to their actions. It’s like showing someone a set of production design sketches and asking them “So, how did you like the movie?”

High-fidelity prototypes won’t cut it because customers make us ship them, and the business landscape is already drowning in legacy systems from the 90s that were only intended to be for illustration purposes.

I’m thinking is there a way of throwing together a working app quickly for customer feedback – Microsoft Access-style – but that doesn’t bind us to a UI design too early, and very obviously can’t be shipped? And, very usefully, that could be evolved into a production-quality version without necessarily having to rewrite the whole thing from scratch.

Right now, nothing springs to mind.

(Talking of Scratch…)

 

 

Author: codemanship

Founder of Codemanship Ltd and code craft coach and trainer

One thought on “A Programmer’s “Breadboard”?”

  1. I read some time ago of a widget toolkit that made your working app look visually like a rough sketch, but for the life of me I can’t find it again…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s