[noduerme]

I just had a recent situation like this which initially presented as a simple calendar / due date list, but then spiraled into some dreaded fuzzy set of if/then cases as the client began to add requirements for due dates of certain items in a certain order that would take priority over other items due on the same date, or missed items, or future items that could be done in advance.

After two weeks of increasing horror, and four attempts to write the algorithm, I sent the client something I called the "Blueberry Muffin Problem" email, as a reference to that scene in Casino. But there is no logical way to do this, I said. Anyway. This led to a series of conference calls in which we finally were able to see a clear strategy.

End result: 40 lines of immaculately clean code, roughly $10,000 at $200/hr, problem solved.

I obviously wasn't paid for writing the code in this situation; it was for spending enough time with the problem to find all the edge cases, and figure out the right questions to ask to get to the solution they needed.

[warrenm]

>figure out the right questions to ask to get to the solution they needed

This is how Jon Bentley starts his classic Programming Pearls

"What are you doing...and why?"[0] is almost always the best place to start when tackling requests from customers

------------

[0] my review/reference in relation to this exact problem, of asking the right question

[noduerme]

Yeah, it's kind of meta-coding at a certain point. Business people are great with the logic of making money and keeping customers happy, but they are bad at translating those operational requirements into pure logical processes. Particularly if they expect their employees or customers to use software that they expect to guide them to do things in a set order, they aren't good at thinking about the order from the software user's perspective. So just putting yourself in the shoes of both those people is really the job. It's understanding the desire of the business and seeing where that's going to run up against problems in the real world.

[brianhorakh]

Can you share or summarize the blueberry muffin email?

[noduerme]

Uh, if you really want. This is probably boring as fuck until I get emotional around the third paragraph ;)

---

I'm putting this down here because, even though it seems obvious, it's not; if you spend 10 or 20 hours really thinking seriously about what happens if people write early reports or late reports - the initial conclusion was just count how many they wrote into how many they sent, and tell if they need to send more, but that's not the way life works. Or people work. And it's going to create impossible bottlenecks if the last report is the most important one. The insight I had and what's going to drive this thing is: How many reports were due since the last one you sent. Again, that seems simple but it's not. Technically it doesn't mean they just skip them; it means if one was due Monday and one Wednesday, and you send one on Tuesday, that covers Monday's report; but if you sent it on Wednesday it covers both, the idea being to discard the missed ones without explicitly saying so, and drive them to do what's important today, and more important if it's the final day.

It also covers the situation where they filed Monday's report early, but only if they've filed all the needed reports prior to that; otherwise they'll need another one for Monday.

That's why this is so hard. It's not the code. It's the number of possible scenarios.

So the rule is, we start counting again from when the last report was written, in terms of priority. And when you're looking at 50 reports a day per franchise, you'd better know what the priorities are.

For myself personally, I think this is writing software that will lead to absolute catastrophe. I've always tried to align the way my software works with how I think people will be able to use it, to push them to do the right thing. Anyone can write the software I write, it's the thinking about this process that is extremely difficult if you're dealing with, like, hundreds of [redacted] and thousands of customers spread out over time, and have to figure out how to make reasonable suggestions. This is such a thing.

What I'm saying is that this is marching into creating a thing that will cause total chaos and I don't think this is the right way. We have the chance now to re-imagine the frequency and rearrange the expectations of the customers and the expectations placed on the staff, and I think we need to do that. The algorithm you asked for is done, but it will not be good for people. And it is extremely hard to understand, even for me, if you asked me why one should take priority over another, when dozens are urgent on the same day. I wrote an "urgency" algorithm on top of it to try to deduce that. The best I can say about it is that it will cause less misses and damage than any other way of looking at the list, and it took me a long time to get to. But I think you're asking for something that is going to be so inefficient, and create such high customer expectations, it's going to be negative on both sides.

The scene keeps going through my head from "Casino", where De Niro tells the chef in the hotel to make sure the same number of blueberries are in every muffin, and the chef just drops his hands and goes, "do you have any idea how long that's going to take?" This is a blueberry muffin situation. We need to think of a better way.

[yesenadam]

I found that fascinating, thanks for sharing!