Jonathan Snook has written a post about the process that freelance programmers follow. I think it applies quite strongly to plugin writers many of whom are hobbyists like myself.

The post focusses on quite an old article from Fast Company about the engineers that produced the computer code for the space shuttle programme.

The article has inspired me to improve the way I work.

I, like a lot of plugin writers, have never had any formal instruction in programming; I have pieced together what I know, somewhat happazardly, as and when I needed it. This often means that there are patterns and practices that are obvious to some that simply don’t occur to me, and therefore my code tends to be produced in a rather trial and error way.

The first part of the process is to properly plan the plugin.

In business when you start a project you specify it great detail. You know what you want into each process and out again. But with a hobby project it is usually a case of starting with a small kernel of an idea and then building on it as each part seems to work.

I have gotten used to specifying things in my head and then writing to see how they work and whether I should keep working. If the basic part works I look at what else I should add, and then bold on whatever else comes to mind.

My goal from now on is to formally specify the features for each version that I write, and then write with that aim in mind. Only when that is complete and works as intended will I add any new features.

Generally, my testing consists of using the plugin and trying to replicate the scenarios that it was created for.

My intention from now on is to use unit testing to check that each part operates properly before the plugin gets anywhere near WordPress itself.

I made my first attempt at unit testing this weekend. I was aware that the counter on my anit-spam plugin was counting comments it shouldn’t so I downloaded the Simple Test unit testing framework and tested the crucial counter section.

Just by going through the process I managed to make the code easier to work with and, hopefully, a little better, but I also confirmed that it was actually working as intended. The problem was that the inputs into the function were different under certain circumstances.

Testing against the revised inputs showed me exactly where the problem lay and I was able to resolve it.

I have always struggled with the bounderies between art and science when it comes to programming. While I want to work like a scientist, all too often I end up working like a artist. Hopefully I can start to change that now.

Share: