Design Play at Work

Big Goals, Panic, & Little Tricks

When should you not have big goals as a software designer?

Tutoring young software designers yesterday I noticed a few common themes:

• Big goals

• Panic

• Little tricks

Software design (or in TF? terms structure investment) should be going in some direction. We notice “this feature seems harder to implement than it should be”. We think “if the design were more like this then the feature would be easier”. That’s the primary reason to design, to make features quicker/cheaper/safer.

The folks I worked with yesterday all had that knack. The software they were working on had become clumsy for some needed changes. They knew there was something wrong, or at least sub-optimal. They could imagine a better structure.

However, there was a big difference in how they reacted to they big goal. For some the goal was exciting. Yes development was annoying now but they were about to make it better. For some, by contrast, the big goal became a source of panic. Yes if I had an object like that then this feature would be easier but OMG HOW AM I GOING TO GET FROM HERE TO THERE???

Panic doesn’t help. A little fear is healthy. Fears tells you “pay attention”. Fear tells you “make sure you’ve anticipated every way you might have broken the system”. That’s not what I’m talking about, the fear that’s like salt on food. I’m talking about dumping the whole canister of salt. Actual progress halts.

What was the difference? One difference was the experience level of the folks. More experienced designers might know more ways to design, but what they definitely know is that:

1. They can get from here to there. If there is a design point they need to reach, then if they take enough positive steps they will eventually reach that point.

2. Even if they don’t reach “the point” they were aiming at it’s okay. The code was hard to change. It’ll be easier to change. Whether they get all they way to what they imagined is irrelevant.

3. The more experienced folks have tricks that help along the way. These tricks provide moments of structure & satisfaction during design.

We were working in Smalltalk, which (shockingly) has some of the most sophisticated design tools of any environment. One such tools is a syntax tree rewriter. You provide a pattern to match & a target pattern & the tool does the rest. Many (all maybe?) structure changes can be expressed as syntax tree transformations.

Tree-based design changes can be difficult to express. However, they are ultimately flexible. The folks who knew the tree rewriter seemed calmer. They knew they could pull out martello (the big hammer) if they needed it.

As I move into the second book I need to collect as many of these tricks as I can. Understanding the current design helps. Imagining a better design helps. But knowing lots of ways of getting from here to there (or at least here towards there) also helps.