My preciousss code
There are two often-cited articles about repeating yourself, rewriting everything and optimising your code for deletion and debugging that I like a lot.
These are some of my favourite assertions about web app development, but they goes against much of the commonly accepted advice. Instead of DRY, don’t worry too much about duplication. Instead of constant refactoring and optimisation (that rarely happens anyway), optimise for easy localised deletion, problem detection and rewriting instead.
Much of what we’ve ‘learned’ about software development practices still feels like it came from the pre-web days, when software was shipped under much stronger constraints. Correctness was a big deal when correcting code meant a long lead time and a high cost. Now we have real-time monitoring systems, continuous delivery and highly-abstracted deployment targets.
The web’s delivery model allows us to consider new ways of working that don’t concern themselves so much with correctness, but are more about the safety of localised, iterative and incremental changes.
What’s more, the rise of hypothesis-driven product development and lean methods further encourages us down this route by taking advantage of short cycle times to optimise for rapid learning.
If we’re to work in this way, premature abstraction is a giant waste of effort. We might easily spend weeks creating a neat abstraction, only for it to become irrelevant during user research and later product iterations.
I sometimes feel like this about big kitchen-sink frameworks and libraries. They can feel like a giant collection of premature abstractions dropped into your project all in one go.
On the other hand, big frameworks can also let us build something quickly so we can focus on minimising the ‘learning lead-time’. As Eric Ries points out in The Lean Startup, validated learning is the unit of value for new products, not shipped features.
For a more established product, the goal becomes oriented more towards problem detection, maintenance and migration work. In these scenarios, a strong suite of tests is important to protect the existing value in the product. The implementation code itself is only valuable only because it represents the current implementation.
If we accept code transience as an inevitability in the UI layer, and stop treating code as a precious jewel that must be honed to within an inch of its life, interesting things can start happening to your application design and working practices.
Is your team precious about their code? What’s their reaction when large chunks of code are deleted?
All the best,
– Jim
