Doing the simplest possible thing
I spent most of today working on some code I wrote for the first phase of a client project a few months ago.
The previous version used hard-coded data within a Vue.js application, which was sufficient for the previous criteria and in line with the lean approach we decided to take.
It was the simplest thing that worked.
A new requirement means that the hard-coded data no longer works, so I need to refactor and enhance the code to work with different configurations. I have a proof of concept of this working using JSON from an API endpoint, but I would also like to use a static JSON file when needed for local development.
I experimented with a few different ways to approach this before asking myself, "What's the simplest possible thing I can do to get this working?".
I already knew that I needed to make a change to the structure of the data, which I was able to do quickly with the hard-coded data that I already had, and whilst a static JSON file would be a nice-to-have, I could quickly move the hard-coded data into the API endpoint that I'd already created and continue building on my proof of concept.
The idea of "What's the simplest thing?" is something that I use regularly.
When teaching or coaching test-driven development, I want to write the smallest failing test and then find the quickest and simplest way to get it to pass - even if it means returning a hard-coded value for now.
When working on development tasks, I like to break things down as much as possible and find the smallest thing I can do, commit, and push. This gets the ball rolling, and then I repeat the process.
Even when writing an email or blog post, once I start writing, it's much easier to continue once I'm in the flow.
Taking the simplest approach and not making assumptions about future requirements or scope means less and more maintainable code, as well as being a productivity hack.
- Oliver
