Being Fast or Getting Faster? (aka Build Momentum, not Velocity)

With technology becoming a large, often critical part of any large business today, businesses always want their technology NOW — to prove product market fit, to leapfrog ahead of competitors in new offerings, and to stay ahead of newcomers by building an unassailable technical moat. Needless to say, the market always wins, and pure technological concerns are often left behind in favour of achieving the next critical business goal. As engineers, we don’t always do, or get to do, the best technical thing — we often settle for meeting the end goal.

Repeat this story of developers building the just-enough solution writing not-so-good code using the not-best-suited tech stack over a couple of decades and we end up with a collective belief that good code and short timelines are opposites of each other, and never the twain shall meet. I want to question this folk wisdom by calling out that there are caveats to this, and there are now well proven ways where we can (and teams have) delivered consistently good technology in great timelines.

The thing with “good code takes longer” is that it holds good only if we are in the building game for a short period. Short term is fine for early start-ups, who don’t know if they will exist the next year. They should focus on doing whatever it takes to get a foot in the door and finding their first customers. But if a team is past that stage and knows that it is there to stay (at least for while), different rule apply. As a team, we should of…