The other day I was going through some code on a pull request by a coworker. It was a rake task to update entries to a new format. A table was getting deleted, and the information had to be merged into the parent model.

It’s understandable why he chose to solve the above situation with a rake task: it’s reusable across environments and it seems more elegant than a quick, dirty command in the console… but sometimes that’s exactly what you need in order to automate a quick, dirty, “manual” task.

The first mistake was to suppose that reusability was desirable. In this case, the table and the model were going to be deleted afterwards, so that’s a dead end for reusability.

Next, backwards compatibility. If we move information from one table to another, we could use a way to go back. Oh and don’t forget the tests… We need those to ensure that our code works at any given point in time.

Given that this task was going to be run on a staging server, and the final product was not even live yet, I don’t think we really need any of the above to alter just a handful of records.

Uncle Bob makes great point on whether it’s worth it or not (link [1]).

“TDD is a discipline for programmers like double-entry bookkeeping is for accountants or sterile procedure is for surgeons. Are there times when accountants don’t use double-entry bookkeeping? Are there times when surgeons don’t use sterile procedure?” (The answer is yes).

In this example it was just too much for a trivial task. Next time you face a similar situation, consider the need for reusability, automated tests, backwards compatibility, etc… and the effort it requires. Then before you start coding ask yourself: is it worth it?

“There are times when TDD is too costly, and a lower discipline should be used instead.” [1]