Are you a ‘good’ programmer? I’m not!
by Prof Barry Dwolatzky
I’ve been writing computer programs for close to 40 years. I wrote my first program – in Fortran IV – in 1971. I wrote my most recent programs at the end of last year – in C++. In the years between I’ve written many, many programs. Some large, some small, some serious, some just for fun. I love programming!
But am I a ‘good’ programmer? I guess there are two ways to think about this question: “Do I write ‘good’ programs?” or “Am I ‘good’ at writing programs?”
“Do I write ‘good’ programs?” – the answer has to be “sometimes”. One of my programs, called CART, written single-handed while I was on sabbatical in 1997, is still being used by engineers around the country to support the design of electrification networks. I’m proud of CART and think that it is a really ‘good’ program.
“Am I ‘good’ at writing programs?” – the answer to this depends on how one defines ‘good’ in this context. Words like ‘predictable’ and ‘bug-free’ come to mind. So let us change the question to the following: “Can I predict how long it will take me to write a program?” and “How ‘buggy’ are the programs that I write?’. Answering these questions is quite difficult. The truth is that, even after 40 years of programming, I simply don’t have the required data available to answer these questions.
In October and December last year, I attended a course on the Personal Software Process (PSP). I was required to write 7 small-ish programs (a few hundred lines of code each). I collected data on how I performed.
For the second program in the course I predicted that it would take me 240 minutes to complete. It ended up taking me 530 minutes – an underestimation of about 120%. The program had 361 lines. I injected 31 defects while writing the program and removed them while compiling and unit-testing. That’s about 1 defect for every 10 lines. Not very good quality by any standard!
Therefore, based on how I performed in the PSP training and an interpretation of ‘good’ that relates to predictability and the number of defects, I’m not a ‘good’ programmer. I have to admit this!
It was also extremely interesting to examine how I write programs. The process of writing a program always includes a number of distinct steps:
- Planning: getting the required information, tools and resources together;
- Designing: both high level (strategic) and detailed design during which we analyse the problem and work out how to solve it;
- Coding: actually typing in the lines of code;
- Compiling (if we are using a compiled language): running the compiler and correcting any errors until we get the program to run;
- Unit Testing: running one or more tests to check if the program is correct. While testing we sometimes have to correct errors to the design or the code and re-compile the program.
During the PSP training I did something I had never done before – in 40 years of programming! I measured the amount of time that I spent doing each of the above steps. The results of this measurement shocked me! I found that over 90% of the time I spent working on a program was used for Coding, Compiling and Unit Testing. I hardly did any design. Not only that – I cycled through these steps (Code->Compile->Test) repeatedly in a very tight loop. The PSP course taught me that working like this was wasteful of my time, unpredictable and frustrating.
By the end of the PSP course I had learnt a new way to program, based on my own (new) personal software process. The 7th program I wrote was completed within 30% of my estimated time (still not brilliant, but much better). It also had far fewer defects.
Although I still can’t claim to be a ‘good’ programmer, I think that the PSP course gave me really deep insights into how I might go about becoming a ‘good’ programmer.
If anyone reading this is a programmer, my question to you is “Are you a ‘good’ programmer?” If the answer is “yes” – my next question is “How do you know?”