Shitlist Driven Development

sirupsen.com · 1,152 words · saved by 1 readers

Recently the team I work with completed a project to allow Shopify to run in multiple datacenters. This project was a refactoring project in disguise. When you undertake large refactoring of a code-base with 100s of developers and 100,000s of lines of code, you can’t align by sending an email. The merge-conflicts a single pull request would entail makes me shiver. When deprecating in a large code-base the only way to reliably avoid new deprecated behaviour is a failing test that tells you what to do. Otherwise the pace that new deprecated code is introduced can easily outpace the speed at which you can remove them, or be a massive source of frustration. Typically deprecations come in the form of soft warnings: Logging to stderr, capital letters and exclamation marks in the documentation, or a legacy prefix to the method or class name. At the end of the day, everyone needs to get work done, and if they see a code-path already being used from 10 places in the code-base despite these soft

Shitlist Driven Development Dec 2016 Recently the team I work with completed a project to allow Shopify to run in multiple datacenters . This project was a refactoring project in disguise. When you undertake large refactoring of a code-base with 100s of developers and 100,000s of lines of code, you can’t align by sending an email. The merge-conflicts a single pull request would entail makes me shiver. When deprecating in a large code-base the only way to reliably avoid new deprecated behaviour is a failing test that tells you what to do. Otherwise the pace that new deprecated code is introduce

Shitlist Driven Development

related reading