Lately I’ve been using the “crawl -> walk -> run” methodology a lot. I just thought of this example:
Sometimes you want to automate something but it is too difficult. However, you can automate the check to see if the results are correct. You can then still do the difficult-to-automate part by hand, but know that the result is correct. That’s crawl.
I’ve often discovered that after implementing the “check”, you’re now a smarter person. Implementing the “do” is now possible.
When you automate things often your code does a “check” and a “do”. That is, you check if things are the way they should be. If they aren’t the “do” fixes that.
For example, in DNSControl, I really want to automate listing the env variables for each plug-in properly in the .github/workflows/pr_integration_tests.yml would be a PITA, but we can at least write code that verifies that none were left out (if we have a source-of-truth that tells what what they all are… which we don’t right now).
Another example is frequently I have a website that has a page that lists links to all the pages within the website. I want to control where new pages are inserted. It isn’t something I can easily describe as an algorithm like “alphabetical”. Therefore I’ve been delaying implementing this because doing so would require defining some kind of tagging or categorization system that would allow the list to be generated automatically. However, I can do the “check” part, which is better than nothing. We’re not scaling this to billions of web pages, so a little manual effort is ok.
I really should write a “check vs. do” article someday. A lot of times people write code that is just the “do” part, but writing a “check” first often can be a great optimization if it prevents a “do” that is a heavy lift.
By the way… I have written about the “crawl - walk - run” methodology, but its buried in my new, humorously titled, article Unethical Ways to Manage Technical Debt.
