Quality and speed are not diametrically opposed. A great engineer does well on both axes by building the minimal thing needed now in a way that is easy to extend in the future.

I have also seen projects go badly because the eng was trying to be perfect upfront. Whereas quickly getting to an MVP and then iterating tends to go better.

> Tortoise and the Hare… the urge to hurry up and burn hard the first two weeks (low hanging fruit, visible wins, MVP!), resulting in ever decreasing momentum due to immature design and in-dev maintenance needs is befuddling to me.

Well said. In Kent Beck’s Tidy First, it explores the slow process that can be summarized by this except from his substack [0]

“Valuable” lives on 2 axes:

  Features—what the code does now.
  Futures—what we can get the code to do once we learn the lessons of this set of features.

While there might be a component of time to get features out, it’s rarely urgent enough to forget about being flexible and having a somewhat constant velocity.

[0]: https://tidyfirst.substack.com/p/genie-tarpit