Summary

Technical leaders often struggle to introduce “tricky” design concepts into their code bases, because the other programmers don’t seem ready for them. Focus on refactoring paths over applying the pattern “correctly” and universally to avoid having to choose between chaos and stagnation.

Quick question, if you want to implement a design that leverage a particular tricky concept but it’s a good technical decision for the software you’re building, what should you focus on?

What kind of “good” is that good technical decision? Who will need to change that code after you finish writing it?

An example that immediately comes to mind would be something like writing Front-End components using the Atomic Design Pattern. It makes writing modular components simpler but the pattern can be difficult to understand at first and apply properly at first.

Would mostly apply to Front-End & UI Devs

If I can see how to refactor safely from What We Typically Do to the Desired Future Standard Design, then that would make it safer to advocate for the DFSD while falling back to WWTD. Yes, it takes time to refactor, but in exchange, I don’t have to view the dilemma as all or nothing. Meantime, it’s hard to say where I’d focus, but I’d always be prepared for the group to decide that they’re just not going to accept the DFSD yet. Then I can decide which strategy to adopt: enlist a trusted colleague, demonstrate a pilot project, extract a Warm Dry Place with freedom to choose…

Typically, when technical leaders treat such a dilemma as “all or nothing” and “now or never”, then they get into trouble. This often creates more problems than it solves. Decision making like this is either an ongoing negotiation or a dictatorship. Pick one. (I can respect both choices.)

BTW: I didn’t know about Atomic Design, but I made some guesses, then I read a few articles. I mostly guessed correctly. This approach is not new. It has been proposed and discarded several times over the last 3 decades, especially during the Early Mainstream Adoption of OO design.

I believe (based on evidence from similar discussions in the past) that the conflict lies mostly in viewing software design as an activity of “First figure out the correct boxes, then carefully put each line of code in the correct box, and get it right the first time.” Even when programmers don’t say this explicitly, their objections and complaints reveal a bias towards deciding every little thing correctly the first time. Notably, they view changing decisions as “mistakes” and “avoidable rework”.

I propose that we radically change this attitude.

This is why I promote understanding how to refactor towards patterns such as Atomic Design: when we feel competent and confident doing this, then we are free to “get it wrong”, secure in the knowledge that we will gradually converge towards a reliable pattern as we need it.

I find patterns and styles such as Atomic Design more helpful when I know how to break them without disastrous consequences. Sometimes, we need to break the rules for a while, to achieve some other goal, then later bring the design in line with our established patterns and guidelines.

When programmers feel the freedom to change their minds, they can live in the best of both worlds: the security of a reliable pattern or guideline or framework without seeing those things as prisons that prevent them from Getting This Simple Stupid Thing Done Sooner.

One more thing: when we resolve to refactor in the direction of the pattern, then we stop arguing about “how to apply the pattern correctly” and instead simply nudge the design in the direction of the pattern relentlessly. We’re more likely to get there with less drama.