Working backwards
Today, I did a show-and-tell session with my team where I demonstrated an integration I've been working on for a few months and recently released to production.
The simplified workflow is we collate some data, send it to a third-party system for translation, receive the translated file and import the translations into Drupal's translation system.
Where did I start?
The first thing I did was not to collate the data and generate the file but to send a minimal, hard-coded version of the contents to the third-party system.
I'd have started with the code to import the translated strings if I hadn't already done this in an earlier spike.
This allowed me to send the file, check the response from the third party and ensure they could work with that file type and my proposed content structure.
If needed, I could have changed direction and avoided investing much time. This wouldn't have been the case if I'd left this until the end of the process.
I also have a working end-to-end test, and I can send a file and get the response I need.
What if I'd written all the code and discovered something wouldn't work?
What next?
Now, I can work backwards and start to make the content dynamic.
I can introduce more authentic and complicated data, remove the hard-coded test data, and check that things still work.
I still have the quick feedback loop, as I can always send the data to the third-party system and verify things work as I iterate on my implementation.
With the main pieces of the puzzle in place, I can continue building and filling in the others.
Once I have a complete feature with all the pieces in place, I can refactor as needed.
I still have the same finished puzzle - I just built it in a different order.
- Oliver
