It does sound like it would barely have broken even when considering the opportunity cost of the highly-compensated developers who had to write it, which they ignore in the article. It goes against the "rules of thumb" i learned at Google, which suggest that an engineer would break even if they saved [redacted but huge number] CPUs per year, and should only choose problems that promise to save 10x that or better.

Hi mehrdada. In the article, we discuss how to evaluate tradeoffs of ML projects. One of these tradeoffs is cost of development and deployment vs. cost of not developing a solution. In our particular case, the tradeoff made sense.

We're looking at this from a very narrow lens. A few of these wins a year in a small team will end up paying for itself fairly quickly.

Let's say X engineers making 200k a year work on this. This is a 5x return on your money in 5 years if it took 8 people working the full year to complete it. Sounds like a solid business case to me.

You also have to keep in mind that this work was interesting and it probably helped to keep few rockstart engineers from leaving.

Agreed. At this level of competition for top talent you need to pamper your staff, which includes letting them work on the kinds of projects that they’ll proudly mention on their CVs, even if it’s not the highest priority project business-wise. I am sure a company like Dropbox can afford to do this once in a while.

That makes sense if all engineers are fungable, and you are never limited by engineering capacity.

You also need to subtract the value those 8 people could create if they worked on something else.

You don't - If you do that you are double counting the cost of the engineers (If they were working on something else, you wouldn't account their salary against this optimisation).

This is unknowable

Was totally going to point this out as well. It's entirely possible that their ML team cost nearly this much to begin with.