Can all “software developers” write programs?

by Prof Barry Dwolatzky

In my role as Director of the JCSE at Wits University I have, over recent years, been interacting with a large number of South Africans who earn their living as software developers. In some of these interactions I’ve had the opportunity to formally assess their skills and abilities. I’ve been shocked to find that some – a small but significant minority – of our “professional software developers” find it difficult to write working programs – even simple ones. Some of these developers have degrees and diplomas in IT-related disciplines from local Universities and Universities of Technology. 

As an academic responsible for educating software developers, and as a person deeply concerned about the successful future of the South African software sector, this situation has troubled me deeply.

What is a “software developer”?

Before I go any further, let’s be sure that we’re on the same page with respect to terminology. I understand the term “software developer” to refer to the individual at the sharp end of the software industry entrusted with the task of putting hands to keyboard to write software.  In the past we called these people “computer programmers” – (I’m not sure when and why they were rebranded as “developers”).

We can debate in some detail the set of generic and specific skills that a “software developer” should have (I will come back to this later). There is however one absolutely critical ability that (in my mind) is never negotiable. A software developer must be able to write a program!  In other words he or she must be able to convert a specification or requirement into a set of instructions in a “programming language” (of some sort) which can then be run successfully on a “computing device” (of some sort).

Although this may seem obvious, let me expand on this last sentence.

Suppose, as a very simple example, that the “programming language” is C++ and the “computing device” is a PC. The specification might say “Read a set of numbers from a text file. Add them up and write the total to another text file.” Anyone who calls him/herself a “C++ software developer” must – in the very least – be capable of translating the specification to (something like) the following:

    blog code

The C++ developer must also be able to get this program to run successfully on the target computing device. This will require compiling, loading, testing and (possibly) debugging the above program.

 In modern software development, there are many different languages, environments and devices.  Developers need many specialized skills and abilities. However, any developer, must be able – in the very least –  to do something conceptually equivalent to the task described above.  The target language may be very different from C++. The target device may look very different from a PC. The specification may look very different – it will undoubtedly be much more complex. But every software developer needs to be able to successfully translate a specification into a “program” that can run on a “computer”.  I’m sure that no one will dispute this.

 Other generic and specific skills

Given that a “software developer” can write a working program, what other skills should they have? This is a topic that I’m sure we could debate for a long time. My suggestion would look something like this:

Generic skills and abilities

  • Detailed design: Any software developer should be able to develop a number of alternative detailed designs that would satisfy a given requirement. He or she should then be able to examine these alternatives and select the one that best meets the requirement.  In many cases the requirement may correspond to a small piece of functionality and the design options may be relatively simple.
  • Unit testing: The developer should be able to test the program that (s)he has developed. Test cases may be given as part of the requirement. They may also have to be devised by the developer. In either case the developer will need to run the tests in a systematic way and record the results.
  • Documentation: The software developer is responsible for low level documentation. In many cases these are added to the code being written in the form of comments.
  • Estimation: If asked the question “How long will it take you to write a program to do X?” can the developer provide an estimate? (S)he should be able to do so with some degree of accuracy. Furthermore, what is this estimate based on? Is it an “educated guess”, or is it based on data collected by the developer from previous tasks?

Specific skills and abilities

  • Different software developers need a vast array of specific skills relevant to their specific technical environment. They also need to have some understanding of the domain (eg. financial services, health care, etc.) in which they are working. Many of these skills are acquired “on the job”. They are not taught at universities and colleges.

The problem we face

As I said in my introductory comments I have a concern that some of our local “professional software developers” do not have the “entry level” generic skill of being able to write a program. If this is true then none of the other generic and specific skills really matter.

My concern, however, is based purely on a perception gained in interaction with a number of developers over recent years – it is not based on any research I’ve done.  I may be wrong!

My question to you – the readers of this blog is: Do you share my perception? Can all professional South African software developers write a program? If (in your experience) they can’t, what should we be doing about this? Is it a problem? Am I wrong to assume that “software developers” need to know how to program? 

I would welcome any comments on this issue.

Creating a 1,000 jobs – round pegs in round holes

By Prof Barry Dwolatzky

 square_peg_in_round_hole

The story so far…. In a previous blog posting I outlined a strategy based on the “Franchisor/ Franchisee” model for setting up software development units capable of delivering extremely high quality software in a very predictable way. I made a commitment that over a 3 year period I would set up 40 such units, each employing 25 people. In this way we could create 1,000 new software development jobs. I will call these new software development units “High-Maturity Units” or “Hi-Mat Units”.

I ended with two questions: Where will all the skilled people come from to staff these units, and where will all the software projects come from to keep them busy?

Finding the skilled people

We have all heard about (and some of us have experienced) the “skills crisis” in the South African IT sector. Both large and small companies struggle to find suitably skilled and experienced people, and – when they do – find that they have to pay top salaries to attract and retain staff. At the same time we have the paradoxical situation of large numbers (hundreds of thousands) of unemployed graduates. Some of these graduates even have degrees in computer science, information systems and other IT-related disciplines. 

I believe that the root cause of this paradox is that we as South Africans have not been at all successful at matching people to jobs. There is frequently a mismatch between aptitude and interest on one hand and education and training on the other. We have the situation where a person chooses to study computer science (for example) when he or she is not well-suited to working in the IT sector. We also have people with a degree in (say) psychology who land up working in software development.

Part of the solution to the “skills crisis” is therefore aptitude testing and career counselling. In other word putting “round pegs in round holes”. In finding people to staff the “Hi-Mat Units” our focus will be on identifying people with the right aptitude and a high level of enthusiasm. While experience and formal qualifications are important, aptitude and ability will be the determining factors.

 Each “Hi-Mat Unit” will employ 25 people. A quarter of these (about 5 or 6) will be experienced in software development. The remainder will be recent graduates or unemployed graduates. After passing and aptitude test all recruits into the “Hi-Mat Unit” will be trained extensively. The focus of the training, which might require several months to complete, will be to teach the recruits to use the processes and tools specified in the “operations manual” for the Hi-Mat Unit. It’s like sending people employed to operate a McDonald’s franchise on intensive training before they are allowed to work in the store. Many of the successful Indian IT companies send new recruits to a training campus to learn how to work within the company’s environment. Intensive technical training will also be given to “Hi-Mat Unit” recruits.

Each “Hi-Mat Unit” will have a formal relationship with a local University and/or University of Technology. This will also assist in recruiting staff into the units.

Keeping the “Hi-Mat Units” busy

 Each “Hi-Mat Unit” should be capable of doing about R10 million worth of development work per year. Where will all of this work come from?

 In the first few years work will come from Government, NGO’s and parastatals. Some of the projects might have to be subsidised. Since the “Hi-Mat Units” will be unknown entities with no track-record, giving work to them may be seen to be relatively risky.  In time, however – on the assumption that the work done by the units will be of exceptionally high quality – they will win contracts to develop software on merit. They should also be well-placed to compete for work internationally.

 Next steps

 At this moment I have a proposal “in the pipeline” with Government to get seed-funding to set up the first 4 “Hi-Mat Units”.  These will be used to flesh-out the concept and as “proof-of-concept” pilots. Moving forward the “Hi-Mat Units” will be rolled out using profits and skilled people from each Unit to seed others.

If you have any questions or thoughts about this concept, please comment.

Creating 1,000 Jobs: Learning from Big Mac

by Prof Barry Dwolatzky

 Burger

What does a “Big Mac with French Fries” have in common with software jobs in South Africa? At first glance …. not much, but I plan to change that! 

Bear with me while I explain this important relationship: When I left SA to live in London in the 1980’s I came to know the McDonald’s Big Mac Hamburger really well. As a poor post-doctoral researcher at Imperial College I realised that I could buy a meal of known quality, taste and nutritional value (or lack thereof) at a very modest price if I sought out the local McDonald’s. More than that – wherever I travelled around the world I could get the same hamburger at almost the same price. When I returned to SA in the early 1990’s I found that the Big Mac had also returned from exile. I could buy that same familiar burger at a McDonald’s “family restaurant” in Sandton, Sea Point and Port Elizabeth. 

 Okay – you’re still no closer to seeing the connection between burgers and software development! Let us reflect, however, on McDonald’s secret to success. How does it achieve such excellent consistency and predictability? What is McDonald’s business model? The famous hamburger chain, like many other international fast-food brands, is a franchise. As the “franchisor” McDonald’s has done the following:

  •  It created the brand and the “brand promise”. McDonald’s continues to spend a huge amount on advertising to ensure that almost everyone on the globe understands what their brand offers consumers;
  • It developed an “operations manual” to support its brand promise. Anyone setting up a McDonald’s restaurant will find procedures, processes and recipes in the operations manual covering everything from what colour to paint the walls to how to clean a fryer to how to set out the weekly financial reports;
  • It provides standard training that helps “franchisees” (those who operate a restaurant) train their staff to work according to the “operations manual”. In many parts of the world one will find McDonald’s training centres called “hamburger universities”;
  • It quality assures its franchisees. In this way it ensures that each McDonald’s outlet follows the methods as prescribed in the operations manual and achieves the “brand promise”.

 And what about the franchisees? What’s in it for them? By buying a McDonald’s franchise they are NOT setting up their own business in the true sense of the word. They are buying the right to operate a restaurant within the narrow constraints defined within McDonald’s operations manual. Why should they do this? Simply because they have a significantly higher chance of success. Research has shown that running a franchise gives the franchisee between 2 and 12 times better chance of success than running a similar business on his own.

 The other key element is that the franchisee sets up the business from scratch. One doesn’t take a “mom-and-pop” corner hamburger joint and attempt to convert it into a McDonald’s. You would shut the old store, tear down the building, rebuild and re-equip it as prescribed in the operations manual, recruit and train new staff and then run it as a McDonald’s.

Now … let us imagine a world …. where software development follows the same business model as a fast-food franchise. (I can hear a chorus of raised voices telling me that developing software is not even vaguely similar to making hamburgers!  Again, please bear with me.)

 We start by defining a brand. My “brand promise” says that “Barry’s Software House” is able to produce and deliver software applications to order (i.e. bespoke development). I promise that each project I undertake will be delivered:

  • within 10% of the scheduled date;
  • within 5% of allocated budget;
  • having less than 0.5 defects per 1,000 lines of code (KLOC) in delivered software.

This promise is impressive because international industry benchmarks, and current best practice in the South African software sector, shows that software projects are delivered:

  • 27% to 112% late;
  • 17% to 85% over budget, and
  • Having 2 to 7 defects per KLOC.

 In other words “Barry’s Software House” promises to be significantly better than any other software developer in South Africa and on a par with the best in the world. Furthermore my promise is not simply a promise. I will collect data from every project to show that I’m meeting my performance targets.

How will my software house achieve these performance targets? I will develop an operations manual based on known and proven industry best practice. I will draw heavily on the work of the Software Engineering Institute (SEI) in the USA. My processes will be based on CMMI. My methods will be based on the Team Software Process (TSP), Personal Software Process (PSP) and various agile practices. I will seek out and integrate best of breed tools to support my operations. Everything set out in my operations manual will be designed to ensure that my targets are met in a quantifiable, data-driven, repeatable and predictable manner.

Together with my operations manual will be training. This will include both existing courses (such as those offered by the SEI) and new curricula that I will develop. Individuals completing the training will receive various levels of certification.

 In setting up “Barry’s Software House” I will use the franchise model. My own organisation will be the franchisor, defining and advertising the brand promise, creating the operations manual and developing and certifying training curricula. My organisation will also quality assure and certify franchisees.

These franchisees will be any individual or organisation that wants to acquire the “Barry’s Software House” franchise. The prerequisite is that they will set up the software development operation from scratch, will follow my operations manual exactly, recruit and train staff as I require, and undergo quality assurance activities.

Since these franchise operations are being established from scratch I will be able to count the number of new jobs created. My intention is that each franchise will employ about 25 people. In this way, by establishing 40 such operations over a 3 year period, I will have created 1,000 new jobs.

 But … where will all these skilled people come from, and where will all the software projects come from to keep them busy.

As they say in the best TV sitcoms – my story is “to be continued” in the next blog that I post.

 In the meantime, any comments – either supportive or howls of derision – will be welcome.