The training of software developers

We need qualified software developers: The sheer volume of requirements for IT systems is increasing faster than the number of skilled workers. Quality is suffering accordingly, especially when more and more critical processes are controlled by IT. So it wouldn’t be a bad thing if even more people were qualified to develop software.

This is also desirable the other way round: programming is a constructive, creative activity that is enjoyable, that makes it possible to solve many problems in the first place and that also demands and can promote interpersonal skills in teamwork and with customers. So if we need more software developers, we have to train them. But how?

The narrative of training in software development

The narrative of training among the public and much of IT looks like this:

1. “Get young people excited about IT”
2. provide tools for programming
3. present programming examples

If you look closely, you can see that this concept is actually based on learners teaching themselves programming. A look at almost any popular book on programming will illustrate the principle. A programming example, typically showing some feature of a programming language, is explained, followed by the request “And now you!”. The concept works for some at least, namely those who actually go on to become software developers.

However, there are two problems with the concept:

• Teaching by example is not a guide to a systematic approach. Accordingly, we see a lot of spaghetti code and bad architecture in many software projects.
• It does not reach many learners who give up in frustration, similar to the “I can’t do maths” that is common in mathematics.

The first problem causes technical problems, the second social, because it limits the diversity of the software developer community: Those who are supposed to teach themselves programming need self-confidence and the joy of experimenting, which require material security and are thus predominantly reserved for certain social classes.

This problem is found in particular in training approaches based on “constructionism”. This idea – propagated by Seymour Papert, the inventor of the programming language LOGO – states (in a very abbreviated form) that children in particular will acquire skills and knowledge themselves if they are only given access to tools and information. Constructionism was the basis for the One Laptop per Child project (OLPC), which, however, failed miserably didactically (and in other ways): Constructionism simply does not seem to work on a broad scale. Incidentally, there is also a lack of systematic methodology there. Unfortunately, the late offshoots of this idea are now the many foundations for German computer science teaching and for the countless robots-in-class initiatives that are supposed to “get young people excited about IT”.

Towards better training for software developers

So for a variety of reasons – diversity, equity, increasing demands on IT – we should make it work better with training. Good ideas alone are not enough: We also need to evaluate them critically and use evaluation to improve them incrementally. (And it is not enough to just ask successful learners to fill out questionnaires).

The American PLT project led by Matthias Felleisen (USA) and DeinProgramm (Germany), the latter an offshoot of the former, have dealt with this problem in particular, starting in 1999 with a series of beginners’ lectures at the University of Tübingen with Prof. Herbert Klaeren and myself. At the time, we were animated by the zeal of good ideas – namely, to establish functional programming and the programming language as the basis for beginners’ training.

There was much to be said for this approach at the time: MIT had already established something similar as a beginner’s trainingin the late 1980s and produced the great book Structure and Interpretation of Computer Programs. After initial enthusiasm – many students liked the approach – we found that the lecture did not enable many students to program independently. (The results were not bad compared to other beginner lectures, but not good enough for us. And indeed, the MIT book is a good book, just not for beginner training).

So we began what was at first a painful process of observation, evaluation and incremental improvement, to which almost all the teaching units of the original lecture fell victim. At the same time, we noticed that many of our observations and improvements coincided with those of the Program by Design project, which produced the book How to Design Programs in 2001.

The most important of these were these:

• Nice examples don’t help if you can’t explain in a comprehensible way how they came about. This means referring to explicitly named techniques that learners can easily find in the teaching material. As a result, we developed so-called design manuals – the counterpart to the design recipes from “How to Design Programs” – which embed programming in a comprehensible, clearly defined corset.
• We were convinced that the programming language Scheme, which is used in “Structure and Interpretation of Computer Programs”, is optimal for teaching because it is small and regular in structure. While these features help, they are not sufficient: good error messages and a direct correspondence of didactic concepts to elements of the programming language are also crucial. Thus, analogous to the *SL languages of “How to Design Programs”, the DeinProgramm languages were created with many changes and improvements over Scheme.
• Programming environments for professional programmers are too complex for beginners. Accordingly, we used the DrRacket environment developed by the PLT project early on.

The only thing that has remained from the 1999 lecture is the basis of functional programming, which has since proved to be a particularly effective basis not only for teaching but also for practical development.

Design manuals for software developers

The didactic approach of the construction manuals will seem extremely bureaucratic to inexperienced readers, because it really scripts and prescribes everything that is possible and almost mechanistically derives programme elements from the previous steps. (Internally, it trades as the “German civil servant method of programming.”)

The design instructions start from the data modelling and derive the framework for the programme almost mechanically from it. Data modelling starts with a stylised description of the data. Example:

“A feast consists of an appetiser, main course and dessert.”

The formulation “consists of” means that it is so-called composite data. This is in contrast to formulations such as:

“An animal can be an armadillo or a parrot.”

Here the operative word is “or”, indicating so-called mixed data. In this way, the entire data model is “declined” and then translated directly into code. The form of the data directly yields the code framework for the functions that process the data. Only at the end does the programmer really have to bring in domain knowledge; the steps before that build on each other almost mechanically. Accordingly, the approach is systematic because it leads comprehensibly to correct results.

This method is comprehensible to most learners – especially those who otherwise have difficulty teaching themselves such skills. So in the direction of broader and systematic programming education for a wide variety of learners, the approach is at least a step in the right direction.

We documented the development and findings in a series of technical papers at the time, which are linked on the project page https://www.deinprogramm.de/, as well as a free e-book in the making.

PS: I left university in 2003 and years later began teaching professional training in software development and architecture. I was amazed to find that the DeinProgram approach works entirely for such training, even though it was developed for beginners.

t2informatik develops and modernises software as a service provider. Click here to learn more.