Design principles before fancy patterns
I’m continuing my scrappy, in-public drafting of the follow-up article to Create your own dysfunctional single-page app in five easy steps…
I barely touched on Mistake 4 that I’ve seen team make when developing single-page apps: Use naïve dev practices.
Nobody sets out to use poor software engineering practices intentionally. Poor code is something that happens despite our best efforts to avoid it. The Agile Retrospective Prime Directive, attributed to Norm Kerth, applies well to this situation:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
(Emphasis mine)
Even the most experienced and senior of developers is perfectly capable of producing terrible code despite best intentions, because circumstances are not always in our favour. Tight deadlines, awkward technology stacks, poor communication, changing requirements - the list of possible flies-in-the-ointment is endless.
What’s more, in the case of front end development, the pace of change means that (so-called) ‘best practices’ have not really solidified (SOLID-ified? Geddit?) yet. Much of the discussion is about ‘idiomatic’ patterns that become established via popular blog articles or books. For example: using the ducks file structure in a React application; or the various ways of managing asynchronous side effects.
It’s keeping on top of these patterns that creates a great deal of the ‘fatigue’ in front end development: where and how to apply them, what they’re for, what benefits they provide, what the alternatives are.
But what’s often lacking in our discussions of these individual patterns is a strong set of overarching design principles that link practices and patterns together coherently and provide a basis for choosing approaches and libraries.
The SOLID principles are just one well-know set of principles. If you’re more interested in functional or reactive programming, you’ll be interested in a different set of principles.
But the important thing is to choose. Just as you choose tabs or spaces. Your design principles will lead you down a certain path and guide your team’s shared understanding of what good software design looks like, even if not everybody agrees 100% with it.
What’s your most important software design principle?
All the best,
– Jim
