Thank you for the article. My only issue is that it doesn’t address the creative/discovery aspect of software development. You cannot discover what is needed to address user requirements by being obsessed with locking in deterministic rules. Naive product features with no bugs are still naive. I don’t think code quality should be defined solely by its ability to not break. I’m not sure what Mark intended in his original tagline, but it is true that only when things break do we get access to the information content needed to know what users needs. Being obsessed with unbreakable code means you lock in whatever naive assumptions you’ve made upfront about your product.
Of course Facebook has bigger concerns over product downtime than most organizations. Big companies are risk averse by definition so I’m sure they would rather be bug free and stale than buggy and full of discovery. But it would be great if engineers could strike a more balanced dialogue, rather than suggesting Mark’s tagline is 100% wrong and we must always squash bugs and keeps things rigid.
If we are going to ratchet up the need to chase down bugs and report errors as we build, lets balance this with an ability to break things before production. How can we experiment with messy, chaotic code to afford ourselves the benefit that comes from making mistakes; while still ensuring ourselves a sound infrastructure built by talented engineers? I would argue the best developers know how to break things and how to ship reliable software. They know how to discover and create.
Thanks again for the great article.
