[bonesss]

“Complexity” understood as the immediate first impression a junior gets looking at some arbitrary facet is always bad and too much and bad.

“Complexity” understood as what’s gonna make development on this system fly easy and fast for the next 10 man-years de facto means side steps when naive approaches would charge straight ahead.

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. So much “faster” for weeks, and it just meant the schedule slipped 6 months.

[skydhash]

> 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

[ahussain]

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.