While the article is very interesting, ultimately it sounds like stuff I’ve been hearing for decades. I’ve been a developer since the time of punched cards and assembly language, and every decade or two, someone comes up with a variant of what we are hearing. It never gets very far — contributions are made, but they end up being incremental, not revolutionary.
Meanwhile, real progress is made in software development technologies, but those just allow us to make more complex messes. We are asked to create more complex systems, because those technologies make us more efficient so we can do so.
While there are many problems in the field, one that isn’t adequately addressed here, although several in the comments have done so, is that the requirements of real systems are frequently unbelievably complex, and often in very inelegant ways. Computer science professors, on the other hand, tend to work on elegant problems, and that creates a disconnect.
Business software, in particular, is a mess because business processes are a mess. I usually worked in more elegant areas — operating systems internals, etc, but I found out how much more complex business software is after having to move into that area. Business processes evolve, in organizations of many decision makers, over decades, and they do so in non-linear ways, and in ways that defy every approach to separation of concerns and modularity. Often nobody in a business even knows the full requirements of the software, nor do they know what the software they already have even does for them, in detail.
Creating models begs the question — you still have to “code”” the models, and that requires much of the same complexity as writing code. In fact, the huge numbers of lines of code we see today are not a result of programmers running wild, but rather of code re-use — of the use of libraries so that programmers can in fact focus on the problem, not all the grubby details of explaining everything to the computer.
With models — how do you tell the computer about tax laws, and how to handle the payroll of an employee for a firm who works in two different states each month, both of whom are taxing his payroll? That’s just a tiny example of the complexity in requirements for code that, on the surface, would seem simple.
Also, contrary to the article, programmers these days usually work with SME’S — Subject Matter Experts, whether they are engineers or business people. The SME’s know what needs to be done, although when the programmers ask questions, the SME’s discover that there are conditions the SME’s haven’t thought about. In other words, the interaction between the programmer and the SME is much like model based development, with the programmer providing new conditions that must be addressed, and the SME modeling what those conditions should provide. It’s very complex in business cases, much more so than favorite problems such as handling random arrival of events.
