This post is about effectively using your time. It is not a defence of taking on huge technical debt to make your life easier for a single\u00a0day, and you are hopefully smart enough to avoid doing that. It’s just a simple approach to growing a system you’re working on while avoiding duplication of effort and over-engineering.<\/p>\n
The first time you have to do it, just get it done. You’ll be in the best position to improve your solution once it actually exists<\/strong>, by knowing real things about how well it solves your problem. Plus, at that point, it’s already solving your problem.<\/p>\n You may be tempted to\u00a0figure out\u00a0the best solution\u00a0before writing anything<\/em>, which in my experience is a huge waste of time. If you haven’t written it yet, figuring out which bells and whistles to add is time-consuming and error-prone.<\/p>\n You got it done, a week\u00a0passes, and a new problem comes up that feels almost the same. Assuming you can’t just use\u00a0the thing you wrote\u00a0before, you can:<\/p>\n Most people\u00a0want to refactor now, but I think you should copy. Why?<\/p>\n With two instances, statements about the group as a whole are wild\u00a0guesses. A simple illustration —\u00a0consider these two numbers:\u00a01, 2, …<\/p>\n The next number might\u00a0be 4, 3, 1, 57, or anything else. No clear\u00a0pattern shows up, because two data points<\/em> only have\u00a0one relationship<\/em>, and patterns are formed from the relationships between things. Try three numbers: 1, 2, 3, …<\/p>\n 4 is next, and I’m sure you saw it coming. This example is admittedly a little weak, but it clearly illustrates that patterns can leap out at 3 things, while being unclear\u00a0at 2. With\u00a0three things<\/em>, you can have up to three relationships<\/em>, and similarities between multiple\u00a0relationships\u00a0are way<\/strong>\u00a0easier to be think about than similarities between … one.<\/p>\n Let’s say you chose to refactor. You put the shared code somewhere ideal for the two cases you know, and rewrite the tests.<\/p>\n Two weeks later, the problem shows up\u00a0elsewhere.\u00a0Is the code\u00a0useable right away in this new spot? If you’re like me, you gave your abstraction the smallest scope necessary, and you’ll probably have to move it\u00a0again. You parameterized the minimum amount required, and you may have to add new controls. That was all wasted time and effort.<\/p>\n Almost no effort needed. You’ll probably have to refactor in two weeks, but you didn’t waste the time today.<\/p>\n “I might forget to update a copy later!”<\/p>\n “Copying and pasting leads to typos!”<\/p><\/blockquote>\n These are both valid points. In the first case, making synchronized changes might lead you to refactor (after all, you’ve already written once and copied once), and in the second case, the risks aren’t as big they seem.\u00a0The second case has a nastier form:<\/p>\n “That’s not DRY!”<\/p><\/blockquote>\n Not repeating yourself is a well known rule, and endless repetition is obviously bad, but I caution readers to ensure that they aren’t following DRY\u00a0blindly. You should consider things like the following:<\/p>\n As for copies and typos, most people are intelligent and careful enough to deal with a single copy well. The real horror stories occur\u00a0when you make several copies (3+) of something and they’re all just a little bit different. Don’t make three or more copies: just copy once.<\/p>\n Back to that choice from earlier: say you’d copied it instead of refactoring. Now it’s two weeks later and you hit a third instance of the problem.<\/p>\n As a quick aside, the “third instance” may\u00a0just be a need to change your code in both copies.\u00a0This is a sufficient condition to refactor. Two distant, identical pieces of code needing similar non-trivial changes is a great way to create a bug by messing up minor differences of context. After\u00a0you’ve written once and copied once, the next step in this approach is always to refactor once.<\/p>\n With\u00a0three instances, you have a good chance of finding patterns. A quick refactor here is going to yield\u00a0even better code than a slow, thoughtful one would have with just two instances of the problem. Context rules.<\/em><\/p>\n Before we move on, what exactly<\/em> does “having three instances of the problem” and “the next step is refactoring it” mean? There are two paths upon discovering you need the code a third time:<\/p>\n The first choice takes longer, but is safer: your code never leaves a working state. This is a little bit like long-division. In complex situations, or when you’re less experienced, it’s best to write everything down. You’ll know which feels right\u00a0when you’re in this position.<\/p>\n What if\u00a0two weeks after your refactor step, you hit the problem yet again, and for some reason you can’t just use your past work? Why not write once, refactor twice? Or write once, copy twice, refactor once?<\/p>\n In my experience, the fourth-instance-that-doesn’t-fit-the-pattern is surprisingly rare. Refactoring at the third instance is usually good enough for a long time, so doing it then minimizes the odds that you’ll have to refactor the same thing twice in a short period.<\/p>\n As for copying twice and refactoring at the fourth instance… this gets back\u00a0into that “three copies or more” zone, where it gets hard to keep minor differences between your solutions straight. Feel free to try, but I bet you’ll find it to be a serious, bug-causing hassle.<\/p>\n So do what the title says.<\/p>\n","protected":false},"excerpt":{"rendered":" This post is about effectively using your time. It is not a defence of taking on huge technical debt to make your life easier for a single\u00a0day, and you are hopefully smart enough to avoid doing that. It’s just a simple approach to growing a system you’re working on while avoiding duplication of effort and […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/posts\/806"}],"collection":[{"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/comments?post=806"}],"version-history":[{"count":21,"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/posts\/806\/revisions"}],"predecessor-version":[{"id":813,"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/posts\/806\/revisions\/813"}],"wp:attachment":[{"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/media?parent=806"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/categories?post=806"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wcarss.ca\/log\/wp-json\/wp\/v2\/tags?post=806"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Copy once.<\/h1>\n
\n
It is very hard to determine\u00a0patterns from just two\u00a0examples.<\/h2>\n
Refactoring after two instances<\/h2>\n
So just copy it!<\/h2>\n
Objections to copying things:<\/h2>\n
\n
Refactor once.<\/h1>\n
\n
The Fourth Instance<\/h2>\n
Write once, copy once, refactor once.<\/h1>\n
\n