Teaching professors to code
A new industry is emerging solely to repair the amateurish, yet often commercially useful software, routinely produced by academics.
The phenomenon has become so widespread that it caught the attention of The Economist, which recently published an article, titled “Of more than academic interest”, shedding light on the issue.
The Economist’s article refers to the quality of code produced by academics as “spaghetti code”, saying that the programs created “are likely to have been written in an out-of-date language, possibly more than one of them.”
The article goes on to say that, “And it is, of course, unannotated, so nobody knows what is going on inside it.”
But, despite the poor quality of the software, the programs can often be useful and relevant. Consequently, the promise of commercial application has attracted those willing to take on the task to clean up and reuse the code.
Obviously, none this would be necessary if the professors knew how to, and were prepared to produce quality software from the outset.
However, there appears to be no incentive for them to do so. Quoting The Economist again: “Those who put the effort into producing good code risk being seen by their colleagues as time-wasters”.
This scenario has all the appearances of a systemic failing within our tertiary education system. The very people who teach students commercial and technology skills can’t, or won’t, do a decent job themselves.
This concern seems to be shared by many young people who would like to enter the IT industry. We witness the continuing high demand for programmers, yet there has been a decline in the number of aspiring developers turning to formal education to hone their craft.
Perhaps the commercial world can teach universities a thing or two because software can be competently developed without extra effort – it just needs the right method.
The most effective approach to software development I’ve come across involves the adoption of real engineering principles – using detailed designs to conceptualise the software solution, making the code a byproduct of the design. A process that makes a clear distinction between design and construction.
The results of this approach speak for themselves regarding quality and reliability of the engineered application.
If university professors adopted just this relatively simple approach, in both their programming and in the way they teach students, the quality of the software produced in all facets of the economy would become dramatically better.
And, if an application had to be handed over to a third-party to commercialise, the underlying design artefacts would make life so much easier for everyone involved.
Makes sense to me, but I’m not an academic. I don’t see value in unnecessary complexity.