Sharing Our Passion for Technology
& Continuous Learning
Delaying the Inevitable: Design Details
“Decide as late as possible”
On the surface this principle of Lean Software Development would seem to suggest that we, as engineers, should put off as many decisions as possible till the last moment. This seems counterintuitive, as creating a working piece of software requires a great deal of planning and decision-making! My take on this is to see it more as “Decide on details as late as possible.” Details such as presentation frameworks, programming languages, cloud providers, or databases. These should remain distinct from the business policies and processes that make up the software’s core purpose.
While holding in mind the need to decide these details at some point, even considering our options on an ongoing basis, we resist the urge to settle too soon. Delaying decisions provides us time to gather information and to experiment, informing the ultimate decision. We aim to create a solution we can easily change in the future, with no part of the software’s core purpose coupled to a detail.
Example
As an example of how we can apply this principle of deciding as late as possible to a project, I recently added an access panel into one of my home’s eaves. When I take on a house project, I never fail to forget something on the first trip to Home Depot. There are always screws, or wires, or switches, or tape, or light bulbs to be forgotten. This project was special. This project only took two trips. This project was lean.
The Core Purpose
The core purpose of this project was to allow easy access to the eave for maintenance of a wireless access point I was placing within the eave. There is a premade solution to my problem: a frame for the access hole that magnetically affixes a cap to the hole. None were the size I wanted. I own a 3D printer that has been very useful in other projects and is a good stand-in as software for this example. 3D printing has a lot of the features of software: quick feedback, easily changed, endlessly useful. I set out to design and print a simple part that served that core purpose of easy access to the eave.
Design
I started simply with a frame that was large enough to fit the wireless access point through. That printed with too thin of walls, so I thickened the walls and printed again. So it went, adding places for screws, testing the size of the cap, and experimenting with embedded magnets to attach the cap to the frame. Throughout this iterative process I contemplated the detail of how to cut the hole into the eave. I did research and found that the easiest way was to use an oscillating multitool.
The Trips
I made a research trip to Home Depot, visit number one, to scope out the selection. I could’ve bought it right then but I didn’t need it yet and there was another decision that was uncovered: which brand to buy? I went back to iterating through my design and comparing the different brands. The day finally came when all the pieces to the project were ready to be deployed and I had narrowed down my tool brand choices.
The final trip to Home Depot was glorious and decisive. I walked in knowing what two brands were better and only had to make one final decision on price. That decision was made all the easier by there being a sale on one of the brands. And with that, I fulfilled my dad’s saying: “a project isn’t done until you’ve bought another tool.”
Wrapping Up
When encountering a large problem it can be easy to focus in on the details of all the things that need to be done. But this is a trap, one that can ensnare you in a web of increasingly entrenched decisions. A focus on incremental improvements and a constant mantra of “is this really needed?” can lead us to a simple, beautiful solution. One may even end up with a high-quality tool at an unbeatable price.