Building a minimum viable product and managing technical debt
Yesterday's email was about a proof-of-concept application that I’d quickly built to validate an idea and explore some initial approaches.
Today, I’ve been working on a client project that I’ve improved and maintained for a few years.
When I started working with this client, they had one website, built with Drupal 7 and Drupal Commerce. Now, there are x websites using the same codebase due to Drupal’s multi-site functionality.
My main task for the last few months has been to get one of their sites onto Drupal 9 (which I did, it went live in October).
This first site was the "minimum viable product" (MVP) - the least amount of functionality required to make it releasable to customers. This is different to a proof of concept which is to validate the idea and start a conversation about requirements and scope - where we define the MVP.
For example, there is the ability to create products and product variations from a CSV file. It loads the file from disk and creates the products, but it doesn't update a product variation if a row with an existing SKU is changed, or disable the variation if a row is removed from the file. There is no admin UI for the client to upload a file - the only file that it'll use is the one that's path is hard-coded within the module.
There are user stories for this, but we decided that we didn't need it for the initial launch and that we were happy to take on some technical debt, knowing that we can address it later when the original solutions are no longer sufficient.
Now the minimum viable solution has been released, we can continue to iterate and enhance it based on customers' feedback, add more functionality, and address the technical debt as needed and as requirements require us to do so.
- Oliver
