I finished the main part of the feature I've been fighting since last week, only to discover that a sub-feature needs refactoring as well. Basically, before implementing this feature, the user would recalculate their model every time they changed its parameters. Calculation usually takes 5-10 seconds for most models, but (a) for some models it takes up to a minutes and (b) the calculation engine uses a first-in-first-out queue when calculating. But the calculation engine caches on a most-recently-used basis (meaning it flushes the least-recently-used calculations when it needs to free up space), so generally, it's just a quick call to retrieve the same results.
In actual user testing, we realized that users often want to go back to a previously-used set of parameters. The calculations for any set of parameters should always return the same results, so in theory this isn't a problem. But we only stored the URL of the most recent calculation for any model. So to get previous results, the users had to recalculate the model with the previous parameters.
I've spent the last 5 days refactoring all of that so that all calculation results are stored, even incomplete ones, and users can simply flip between them with a drop-down. Only, there's a second step, whereby the API takes the results and transforms them into a different view. That calculation is very quick—just a few milliseconds—but also subject to the queuing mechanism, and requiring a second call from our UI to our API, and then from our API to the calculation engine, after our API looks up the results of step 1.
All of this has pushed our sprint out a week, as well as made me very cross with myself for not anticipating this workflow a year ago when we built our current UI.
Anyway, it's past 4pm on a Friday and I will probably spend another 90 minutes on this tonight to get it to a point where I can finish it Monday morning without having to rethink the whole API. Good Omens II will just have to wait.