Importance of a full specification
Because of COVID, restaurants are offering only take-aways. Therefore I was (t)asked to create a module for lunch orders for employees, in which there are 4 meal choices, soup and salad or dessert each workday. Then it will record payments made by employees to a designated person.
The data model was quite straightforward, it's basically a simple e-shop. And even simpler, because I can merge orders with payments. So it all fits into a single database table, with a row per day and employee.
When it was ready for testing, I got two “innocent” follow-ups: It should be possible to define amount for each meal, because some employees order lunches for their family members as well, and payments are not only in cash, but also using meal vouchers (common work benefit here in Czechia).
Because for each row I stored price and not the amount, the change would require either a significant extension of the model, or a complete rework. I could imagine further follow-ups like this, so I opted for the more robust latter choice.
The complete rework rest in adding another dimension, so now every row will be for combination date-employee-type, where type is either food or payment.
I have to admit, I didn't expect the change to be that significant. The amount of code doubled, along with its complexity. When I had hard time to update the current code, I ultimately decided to delete most of it and rewrite it almost from scratch, which helped immensely.
It would save me more then half the time required to complete the task, if I had the whole specification from the day one. I partially blame myself, because I went the easier route without further analysis, where the need for food vouchers would possibly emerge.
Update after two months: Guess what? I got another request, this time to record paid invoices to the meal company, that would calculate leftover cash. This time the change was quick and easy, thanks to the clever choice I made :-)