In High Output Management, Andrew Grove mentions the term lowest value stage quite a bit. It’s a term from the manufacturing world: manufacturing adds value to things by taking raw materials and turning them into something else that can be sold. The lowest value stage is where you want to catch issues. Problem with a raw material? Catching it before that material is transformed into something else is better than throwing away a completed product.
So, how can we find issues in software at the lowest value stage? What even is the lowest value stage of software?
I like to design data first because it’s easier to work change data structures before having to worry about storing those objects somewhere. As soon as something is in the database, a change to the data might be a database migration.
By designing data before I worry about storing it, I can also sketch out various other parts of a system and how it interacts with the data structure(s). During that process, I’ll probably find things I missed in my initial pass at the data structure(s) and I can revise them without needing to worry about what the storage backend is doing. Need to think about how things are stored and retrieved? That’s fine, add interfaces that define the storage operations needed without implementations. Use test doubles of those interfaces if necessary.
This early feedback happens at the lowest value stage — a stage just beyond an idea of how a system might work.
Are You 20% Done or 80% Done?
At 20% done, I have the barest idea of how everything will fit together in the end result. My thoughts about some code as a whole are malleable — I’m still feeling out the best way forward. When I ask for feedback at 20% done, I’m asking colleagues to critique where my design is headed. I’m asking them to weigh in on issues I may not have thought of.
At 80% done, I’m pretty set in how a given bit of software will work and fit together. I’m not looking for feedback on overall design at this point, but on little details. Could a method name be better? Is there a bit of refactoring I can do now to make this easier for future maintainers? Code isn’t sacred because it’s been written, but it’s a lot harder to throw away something that has had many hours of work put in.
Sometimes a nearly done thing does need to be thrown away, of course, but early feedback can help avoid that sort of churn.
Ask for feedback at the 20% done stage. Get thoughts on overall architecture early. Do just enough work to make the idea apparent, but with minimal actual implementation.
This is a great way for mid-level software devs just starting to work on bigger projects to learn more about best practices at their company and learn a ton. Get feedback from your senior and lead devs early, and adjust your design based on that feedback before getting too in the weeds of implementation. Fewer changes will need to be made down the road (hopefully) and the next project will go even better.
It’s fun to be in the weeds, but sometimes early feedback can produce a lot better outcome.
Christopher Davis 