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?”
It is going to take a long time to get shift mind sets towards actually knowing your own performance. Without data you can always advertise yourself as being a good programmer, it takes a lot of maturity and/or humility to actually get a quantitative measure of your performance.
I hope the universities buy into this and we end up with a generation of developers who base their decisions on actual data and not on the condition of their coffee machine.
I wish I had been taught to develop this way.
I am not a programmer – I can count the number of programs I have written in my entire life on fewer digits than two hands possess.
But I am a writer, and I found tremendous similarity between the processes outlined by Barry for planning, coding and executing programs and those for planning, writing and publishing an article. Without a doubt, my best work comes from pre-planning the objective, structure and content before putting fingers to keys, carefully checking the accuracy of the key depressions while typing and then doing a run-through before hitting the “send” or “publish” button.
Maybe we can take PSP into the world of journalism?
Hi Barry
I would like to make some comments on your blog about a good programmer.
I also started as a programmer in 1983, my world at this time was IBM-MVS Hosts, Cobol, IMS.
I started with a big Insurance company in a 2 years trainings course. In the first 9 months we did not write one single line of code but trained structuring programmes. The company was heavily committed to Jackson programme structuring methods (I don’t know if you know about that, but at that time it was quite famous). However we trained structuring programmes until we dreamed about it at night. We also learned how to test programmes methodically, how to test exception (e.g. if no input, if impossible input, etc.).
When I came out of this course I was a good programmer and I programmed good in the sense of your blog. Something I also learned was to re-use code; copy/paste was the most efficient way to write programmes at that time: The coding was quick and the code was tested already.
However i moved forward and since a number of years I work as Project and Programme Manager. When I look at the young programmers in our teams I always find they are brilliant with ideas on how to solve a problem, but they completely lack the good old craftman ship of programming.
As a result the solutions are often brilliant, the quality is lousy. Maybe going back to these old programme craftman ship values would not be such a bad idea.
regards
Peter
“How do you know?”
Your customers keep buying your products even 10 years after the “new car” smell has worn off.
I try in my company to have software that just works and aim to make it such that if it went to mars we would not have to send anyone there to fix it.
Today with the dev tools and everything connected and flash-able it makes for sloppy lazy programmers that slam dunk solutions together and wait till run time(or customer cancellations) to bug fix.
I started out coding in assembler on Z80′s and burning proms.
If you didn’t have attention to detail you could end up with an expensive and time wasting delay or even worse a buggered processor.
I do not want a return to those days, however I have found that today’s young engineers seem to have a “just throw more processing power or Ram at the situation rather than really understand the problem.
Also with abstraction has come a lack of understanding of the fundamentals of processing and memory management.
I hired two very well qualified software engineers (MSC’s from Wits) a few years back and had them working on a RS232 comms controller for a Radio Data network.
It took three months, thousands of lines of code and endless late nights with these guys trying to debug a complex multithreading C# application complete with multi agent architecture(why?)
The system kept on locking up and running out of steam even though the PC processor was a latest dual core pentium and the Radio network driving it all was only a simple 8 bit processor.
“We can’t use SQL express we need a full licence” I was told and maybe more Ram.
Fortunately for me these geniuses were “headhunted” out of my company and I ended up having to re-write the application myself.
I am an electronics guy not a software guy so I did what was the easiest for me and re-wrote the application in VB6.
150 lines of code 1/100 of the processor load compared to the other app as I use the hardware (uart) to do half the processing for me in hardware (Data and header detection) and buffering and interrupts(sorry “events” in sw speak).
No bugs and the client is happy.
No threading no Agents running around “polling each other”, just simple code and its still working bug free a year later.
As an engineer, I like solving challenges in a simple and sometimes unique fashion, as a business owner all that is important is that it works reliably and it does exactly as the customer wants.
any news on when PSP will be offered as a course in SA?
I have not programmed for the last seven years and now I am faced with this big task of programming while pursuing my Masters here at WITS.
I have an interest in PSP as it seems it works very well for you. Where can one take the PSP course? Any recommended books one may look at?
Being a good programmer i feel is relative to your domain ie a programmer for NASA that expresses himself through mathematical equation vs a line-of-business programmer might be as good as one another in their domains, but as soon as you cross-pollinate they could quite easily be very inept. I believe what makes a good programmer is his ability to adapt. This is why it is so important to understand the fundamentals of coding ie stacks, heaps, pointers etc. These concepts are across the board for all development environments and are the single commonality – everything else is really just syntax. Discipline is the second item i would raise – ie using proven methods to produce a predictable outcome ie patterns and practices, i have seen code smells develop almopst instantaneously just because time constraints caused ‘on-the-fly’ code.
In summary – i feel that discipline and a good understanding of the fundamental concepts of programming create a good programmer, Once you have these coupled with a good attitude you should be able to adapt to whatever language you come across. Just my 2 cents worth.
Two book titles are interesting in this context, namely:
- “The ART of Computer Programming” (by D. Knuth),
- “The SCIENCE of Programming” (by D. Gries),
(Capitalization of the words “ART” and “SCIENCE” by myself, not in the original titles).
Barry’s term “good” can thus either mean: “good as art”, or “good as science”.
The question, whether programming is still (only) an “art” or whether it has already reached a status of “science”, is still an open question in the domain of philosophy of science, particularly philosophy of computer science (which is still a fairly new branch of modern philosophy).
However, in between these two extremes – “art” on the one hand, and “science” on the other hand – we can find the concept of “engineering”, which features particular elements of both, arts and science. Consequently we could ask, if Barry’s “good” programming could also be understood as: “good as engineering”.
Engineering in all classical engineering disciplines, however, has always been characterized by the availability of pre-digested and standardised “handbook knowledge”, which the engineer can easily look up and apply in the circumstances of his particular projects. Much of “engineering” is thus the repeated application of standardised “handbook knowledge”, whereas the unforeseen emergence of groundbraking new ideas of highest originality is only a rare case and only the smallest part of typical “engineering” activities. [Acknowledgments to Tom Maibaum for several related discussions I've had with him about this topic.]
Consequently the question arises now in this context of Barry’s Blog: Do we have such “handbook knowledge” in the domain of programming? The answer is loud and clear: YES! We sit indeed on an enormous pile of knowledge about Algorithms and Data Structures, which have been investigated since the late 1950s (!), and which can be readily applied to MOST of our usual, standard application problems.
The “good” programmer in this context is thus NOT the out-of-this-world “genius” who suddenly comes up with something utterly new and unheard-of. The “good” programmer is here the one who is well familiar with the vast body of knowledge (BOK) in Algorithms and Data Structures, as it has been developed since several decades, and who is able to choose wisely the appropriate “recipes” from this “cook-book” for application and re-application in his daily projects.
The BAD programmer, on the contrary, is then the one who’s trying hard to be smarter and more “inventive” than everybody else, and thereby only re-invents the wheel, because of having ignored or forgotten the ample historical repository of already existing and widely applicable BOK-solutions. The good programmer, so I may conclude, is the one who knows the HISTORY of his trade.
Hi Prof,
I am also interested in PSP and would like to know when it (courses) will be offered, and where. Is there reading material on this?
I am a programmer but I cannot really tell whether I am ‘good’ or not because I have not been measured. My job entails developing new software as well as maintaing existing software.
Hi, I came across this blog and it’s really helpful. Honestly, I can’t tell whether I’m a good programmer or not but thanks for the article anyway.
Pingback: Albert on Caffeine | Are you a ‘good’ programmer? I’m not! - Software Engineer