My “Thousand Job Strategy” to be launched at JCSE’s Process Improvement Symposium

by Prof Barry Dwolatzky

Barry Fifa

So why do I write this blog? The answer is simple … I’m on a crusade. The sub-title of my blog makes it clear what this crusade is (broadly) about. It says I’m “passionate about the SA software industry”. My focus, however, is much sharper than that. Put quite simply … I’m on a crusade to ensure that the SA software sector grows in size and international reputation over the next 5 years. Furthermore I need to be able to accurately monitor and measure this growth. 

Is this a pointless crusade? Am I a Don Quixote figure tilting at windmills? 

Obviously I believe strongly that my mission is achievable. I also don’t, for one moment, underestimate the difficulties I face. 

So – let me lay it down in front of you!  Here is my action plan: 

1.  My first step is to clearly define what I mean by the “SA software development industry”.

2.  Having agreed what the “industry” is I need to measure its current performance. After considerable thought I’ve decided that the performance of the industry will be determined by collecting a set of 5 numbers from as many software development projects as possible. These numbers are:

  • Size: Number of people in the team.
  • Schedule Performance: What was the difference (in days) between the promised completion date and the actual completion date?
  • Cost performance:  What was the difference (in Rands) between the promised budget and the actual cost?
  • Project size/complexity: How big and how complex was the application developed in the project?
  • Quality: How many defects (or “bugs”) were discovered during system testing?

These – per project – measures will then be averaged to give a measure of the state of software development in South Africa.

3.  I will then implement a strategy (see below) to improve the performance of the industry. My strategy also aims to increase the number of people employed in developing software in South Africa.

4.  On an ongoing basis the measures listed above will be collected and reported on.

5.   If my crusade is to be a success, I would want to see improvements in both performance and the number of jobs.

Before you say that this is “pie-in-the-sky”, or “mission impossible”, let me ask what else we should do to sustain and grow our local software industry?  We need to have ambitious plans, and (I believe) we need to monitor progress. I accept that it’s going to be difficult, but I’m ready to try! 

I’ve developed a strategy (see point 3 above) that aims to achieve my mission. I call it the JCSE’s “Thousand Job Strategy”. It aims to create 1,000 new software development jobs in South Africa over the next 3 years. It also aims to achieve a significant and quantifiable improvement in the performance of local software development teams. 

Are you interested in finding out more about the “Thousand Job Strategy”? It will be unveiled at the annual JCSE Process Improvement Symposium on 26th October 2010 from 8:45 to 12:45 at the Sunnyside Park Hotel, Johannesburg.  I will be inviting comments, both supportive and critical. 

The Symposium will also be addressed by the eminent international software engineer, Prof. Dr.-Ing. Manfred Nagl, Emeritus Professor of Software Engineering, RWTH Aachen University, Germany. 

Visit to find out more about the Symposium. Documents describing the “Thousand Job Strategy” will be posted on this blog after the Symposium.

Are you a ‘good’ programmer? I’m not!

by Prof Barry Dwolatzky

Programmer 2

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?”

Are programmers soon to become extinct?

by Prof Barry Dwolatzky

SedibaJuvenileSkullThe discussion at this week’s JCSE “Architecture Forum” got me thinking about the future of programming. Some of the software architects present seem to believe quite strongly that the art of writing a computer program – something I’ve been doing since the early 1970’s – will soon be automated. Images of the recent fossil discoveries by scientists from my own University flashed into my mind. Will palaeontologists of the future display the fossilised remains of the long extinct “Computer Programmer”?

 Programming is about abstraction. At the heart of the computer – or “programmable device” – is some low level binary machine code. Some of us may have learnt to craft these instructions by hand at some point in our careers, but since the 1960’s programmers have worked at a higher level of abstraction. The so-called “general-purpose languages” – FORTRAN, Cobol, C, Java and C# – allow the programmer to focus on relatively high-level issues when translating a design into a program. Using these languages we write our programs using assignments, loops and conditionals. Various structuring mechanisms have been introduced to help us deal with complexity. These include functions, procedures, classes and methods. Libraries of reusable functions and classes have also long been available to simplify the task of programming.

At a level of abstraction higher than these general-purpose languages are domain-specific specialised languages. Do we still use the term ‘4th generation languages” – or 4GL? These languages allow the programmer to think about the problem to be solved at a higher level. While these certainly gained some level of adoption, millions of computer programmers around the world still develop software using languages like C, C++ and Java.

In the 1990’s the concept of “model-driven development” appeared. Programs were designed using a modelling language like UML and tools were then used to automatically generate programs in the language of choice. These generated programs were in fact structured shells – a programmer still had to write a lot of C++ or Java code. The UML tools did not automate the detailed programming, but rather the high-level structuring.

The discussion at the Architecture Forum centred around architectural representations. Some of these are at higher levels of abstraction than the detailed design expressed in UML. The issue raised was this: Using modern architectural representation notations the “business rules” of the required software can be captured. Is it possible now, or will it soon be possible, to automatically generate running software from these representations? If this is possible and becomes widespread the computer programmer as we know him/her will become extinct.

My own view is that this will not happen – at least in the foreseeable future. The work of writing the detailed steps of a program is best done by a skilled human programmer. The variation and complexity of detailed programming does not lend itself to machine automation.  But maybe I’m just a dinosaur of the information age refusing to accept my own imminent extinction!!??

Don’t complain about the broken “skills pipeline” – fix it!!

by Prof Barry Dwolatzky


The ICT “Skills Crisis” – and how to solve it – is an issue that has been my major preoccupation over the past decade (or more). I was therefore interested to read an article in ITWeb (19th April 2010 ) headed “Holes in ICT Skills Pipeline” , written by Leigh-Ann Francis. Continue reading “Don’t complain about the broken “skills pipeline” – fix it!!”