Too whet an appetite for DRY principles

DRY - Don't repeat yourself

One of the things I did wrong when I started to write software for a career is to try and optimise before I had a chance to understand. Having worked a little longer I feel I have a better appreciation for what should be automated and when. 

There are a lot of things that I felt I was repeatedly doing that according to my understanding of the DRY principles at the time, I thought I should be abstracted away, so as not to have to repeat myself. I kept telling myself that if I was finding a project boring that the boredom was a notification from my mind that there is unnecessary repetition. I still feel that there is a level of truth in the idea of boredom being the mind picking up on repetition however I now realise that is that there is a level of repetitiveness that is inherent in working as a software developer. That is not to say that we shouldn’t strive to remove the repetitiveness but that the job of a developer when working on a project must be first and foremost be that project. Trying to automate whatever element you realise contains the repetition can be a project in itself. It’s likely that the automation could be useful to the community at large but given as an employee your work is proprietary to your employer, sharing the work with the wider community just isn’t possible. For the project then the automation is not worth the time you will spend on it.

The problem then is being able to see the repetition and stay focused on carrying out the task, even though your mind can see the repetition.

Although I have gained this insight over time, I still struggle with taming my mind to continue to focus on the repetitive task in hand, rather than let it race off in search of the solution to what it sees as the repetition.

There is another problem with my search to remove the repetition. What I often found is that rather than removing the repetition from the task I simply abstracted the task to a data entry task, which felt far more tedious than the original code. There is something to be said for doing this where possible and where sensible. Adding a location where data has to be loaded adds to the task of the next developer reading the program structure. The newly introduced abstraction can also increase the complexity of what should otherwise be very simple, if verbose, code.

Unfortunately, the abstraction often takes longer to build, longer for other developers to understand, as well as yourself, and as a result, is less stable and harder to debug when it does go wrong.

It can be clear that abstracting away the data entry when the data entry is large enough is the way to go. 100s of if statements is clearly bad practice. What I must admit to doing when I first started was building an importable CSV for a scenario with as few as 4 cases.

The later management of the config CSV files in the build, as well as the understanding of what ended up being almost a domain-specific language itself, caused far more upkeep than the, perhaps verbose and repetitive, if statements would have. Not to mention took longer to code.

All this may seem perhaps too down on the DRY principles. I do still look for ways to speed up my workflow however I am more careful about over abstracting simple cases. One of the arrogant reasons for trying to move the code away to a simpler, albeit more boring, data entry job, is that the data entry job can then be passed onto another team who may be cheaper or even a system like Amazon’s Mechanical Turk. However, this only works if the data entry is large enough to justify the expense of explaining to someone who has to type it in what they have to type in. Even when the size of the task is of the order of 100 elements it might still be cheaper for the developer to finish the typing before they might have finished explaining the task to the data entry clerk. That assumes the task of allotting which clerk to give the work to! Clearly, there is a time and a place for abstracting concepts away to a separate accompanying data file. With some experience, the existence of that line is clear, with more experience the location too; will become clear.