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.


Comments

Post a Comment

Popular posts from this blog

THREE.js: minecraft in a weekend

Image
I have been enjoying exploring the ideas behind procedural worlds and in a previous post even showed a simple voxel renderer based in THREE.js which would load chunks when the camera got close enough to the edge. That was based on the great tutorial here which explains how to create a voxel-based mesh in THREE.js such that it doesn’t use all of the machine’s resources for the smallest of worlds. I found that to be an invaluable source of information and continually referenced back to that throughout the weekend. Looking back at my git logs for this project to be able to type this up, I have no intention of this post being a tutorial in itself, my progress was as follows: Walking around rather than observer view Sideways collision detection - not walking through the map Changing to a system where there was a sensible grass - sand - water height system Adding trees Another optimisation for terrain generation in addition to the afor...
Read more

Picking apart Perlin noise from first Principles

Image
Although there are a lot of tutorials explaining the what and even the how of Perlin noise and the general class of algorithms; gradient noise, I have found none explaining the why behind the algorithm. Why does this algorithm work? In this post I aim to build up perlin noise from first principles, explaining why we add each element to the algorithm as we do. We will start by trying to make a surface, perhaps for a computer game world map. We are aiming for something that looks like a mountainous region. We don’t want to hand craft this landscape as we want it to go on forever, how can we procedurally generate this world? Given we want the surface to be random, we could start with that. However as you can see that doesn’t lead to the most pleasing of surfaces, in fact it wouldn’t be traversable in the game. Our problem is that there is no smoothness from one place to another. The lowest of points could be adjacent to the highest of points. What we want is for it to take som...
Read more

The invincible 20 year olds

Image
It is often said that people age 20 think of themselves as if they’re invincible. It’s an attribute most commonly given to young men in general.  The idea of immortality is one which comes up in mythology a lot and sometimes it comes up within scientific circles. Bacon spent his life in search of finding ways to become immortal until, in perhaps an ironic way, his search killed him. When immortality is spoken about the concept of ageing is often also brought up, Tithonus comes to mind. Solving the problem of ageing through does not lead to immortality, although it may seem to be that way. Each year you live your chance of dying that year increases. This is how the ageing process manifests itself in this side of the numbers, growing from a low of 0.01% age 5 up to almost 40% age 100. What if instead, this didn’t rise. What if every year you had the same chance of dying as wh...
Read more