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:
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:
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.
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.
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.
> For some, by contrast, the big goal became a source of panic.
This reminded me of something Dr. Jennifer Heisz said on her current book tour for "Move the Body, Heal the Mind" where she said that we might better cope with overwhelming tasks by lowering the stakes of what we're doing. Hearing her say that reminded me of Test-Driven Development. Taking small steps, tabling related or inspired work for later, and making sure we're staying focused on one thing at a time has brought great relief through lower the stakes of any individual commit or PR.
(I read TDD before doing the technical phone screen at Pivotal Labs and it truly helped me stay calm and focused when I was certainly anxious. Thanks are in order!)
- Work out a contract/interface for the change. Sounds obvious but I’ve seen it go wrong fairly often, results aren’t tight and clean.
All the flavours of this you have explained, the tricky question (at least for me) is when you use which which approach. Specially in the beginning of the discussion you describe when group perspective is all over the place.