3 ms·

There is some cost/effort to building a better browser engine. They might believe that the same cost/effort would better benefit the business if put elsewhere.

by tyre 6y ago

There is some cost/effort to building a better browser engine. They might believe that the same cost/effort would better benefit the business if put elsewhere. You see this at companies when engineering teams get it into their heads that they need to rewrite in a new framework. There's a trade-off between that work and building new features for customers. The benefits might be worth it in the long term! They also might not be. That seems to be the call Mozilla made. I don't know if it's the right one, but it seems to be what they did.

coldtea 6y ago
>There is some cost/effort to building a better browser engine. They might believe that the same cost/effort would better benefit the business if put elsewhere. Yes, because all those years the Mozilla executive team has proved that they have a good grasp of where the cost/effort optimum lies... /s
- stuaxo 6y ago
  From the outside it seems like eating the seeds for next years harvest.
  - cmrdporcupine 6y ago
    I can't speak for how things were at Mozilla, I have no idea. But separate teams working on "rewrites" of platforms that other teams have to maintain often leads to a demoralized environment, pointless duplicated work, and elongated schedules and failure to deliver on milestones. I've seen it several times: Often after years of promises from "the new hot" team, with them cannibalizing resources and top talent but missing milestones and still having failed to deliver, the new beast is cancelled and the value of the "old" system is suddenly recognized. There's the classic Spolsky essay about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... What's better? Refactor the old thing as you go. Include the "legacy" team in the development team of the new thing. Even more so, make the "new" team work on the old thing as well. Rotate developers between the two, build a culture of respect. Not saying that is what happened at Moz, but I've seen it play out so many times. And without a concrete commitment to be forced to deliver to actual customers projects like these can just go forever noodling around in perfection-land.

by tyre 6y ago

coldtea 6y ago

>There is some cost/effort to building a better browser engine. They might believe that the same cost/effort would better benefit the business if put elsewhere. Yes, because all those years the Mozilla executive team has proved that they have a good grasp of where the cost/effort optimum lies... /s

stuaxo 6y ago
From the outside it seems like eating the seeds for next years harvest.
- cmrdporcupine 6y ago
  I can't speak for how things were at Mozilla, I have no idea. But separate teams working on "rewrites" of platforms that other teams have to maintain often leads to a demoralized environment, pointless duplicated work, and elongated schedules and failure to deliver on milestones. I've seen it several times: Often after years of promises from "the new hot" team, with them cannibalizing resources and top talent but missing milestones and still having failed to deliver, the new beast is cancelled and the value of the "old" system is suddenly recognized. There's the classic Spolsky essay about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... What's better? Refactor the old thing as you go. Include the "legacy" team in the development team of the new thing. Even more so, make the "new" team work on the old thing as well. Rotate developers between the two, build a culture of respect. Not saying that is what happened at Moz, but I've seen it play out so many times. And without a concrete commitment to be forced to deliver to actual customers projects like these can just go forever noodling around in perfection-land.