“Perfect is the enemy of the good” is a very true and helpful saying that’s often applied to creative work.

For example, if I fret over the wording of a blog post and hesitate to hit publish because my writing isn’t perfect, then I’ve prevented myself from releasing value into the world. Better to just publish something that’s pretty good and get it out there.

But “perfect is the enemy of the good” is an egregiously counterproductive mindset in the context of software projects.

The reason is that it’s a false dichotomy. Software projects are always behind. All development teams are always under extreme time pressure. Practically every production codebase in existence is a crappy legacy codebase. So the normal day-to-day state of affairs for most teams is that they’re cutting corners and doing work they’re not proud of in order to maintain some semblance of productivity. (This is not a good way to work but it’s the common reality.)

When leadership comes to a dev team and asks them to perform a miracle, the choice the dev team is faced with is not “should we make it good or should we make it perfect?” Rather, the choice is between: a) business as usual, i.e. piling yet more shitty code on top of the existing pile of shit, or b) switching to “crisis mode” and committing whatever crimes and sins and atrocities are necessary in order to meet the desired timeline. The dilemma is not perfect vs. good but crappy vs. ghastly.

Yes, it’s of course important to actually ship features and meet commitments. But the way to ship features is to employ healthy engineering practices and to take on realistic scopes of work, not to do work of intentionally low quality.