On Fri, Aug 31, 2018 at 04:45:57PM -0600, Jonathan M Davis via Digitalmars-d wrote: > On Friday, August 31, 2018 4:23:09 PM MDT Walter Bright via Digitalmars-d > wrote: [...] > > That won't fix anything, because there is NO conventional wisdom in > > software engineering for how to deal with program bugs. I suspect I > > am the first to try to apply principles from aerospace to general > > engineering (including software). > > > > For example, in any CS program, are there any courses at all about > > this? > > There are probably some somewhere, but most CS programs really aren't > about writing good software or even being a software engineer. Some > definitely try to bring some focus on that, but it's far, far more > common that the focus is on computer science concepts and not on > software engineering. A good CS program gives you a lot of theory, but > they're rarely big on the practical side of things. [...] > It's often pretty scary how poor the average programer is, and in my > experience, when trying to hire someone, you can end up going through > a lot of really bad candidates before finding someone even passable > let alone good. [...]
The problem is that there is a disconnect between academia and the industry. The goal in academia is to produce new research, to find ground-breaking new theories that bring a lot of recognition and fame to the institution when published. It's the research that will bring in the grants and enable the institution to continue existing. As a result, there is heavy focus on the theoretical concepts, which are the basis for further research, rather than pragmatic tedium like how to debug a program. The goal in the industry is to produce working software. The industry doesn't really care if you discovered an amazing new way of thinking about software; they want to actually produce software that can be shipped to the customer, even if it isn't using the latest and greatest theoretical concepts. So they don't really care how good a grasp you have on computability theory, but they *do* care a lot that you know how to debug a program so that it can be shipped on time. (They don't care *how* you debug the program, just that you know how to to it, and do it efficiently.) A consequence of this disconnect is that the incentives are set up all wrong. Professors are paid to publish research papers, not to teach students. Teaching is often viewed as an undesired additional burden you're obligated to carry out, a chore that you just want to get over with in the fastest, easiest possible way, so that you can go back to doing research. After all, it's the research that will win you the grants, not the fact that you won teaching awards 3 years in a row, or that your students wrote a glowing review of your lectures. So the quality of teaching already suffers. Then the course material itself is geared toward producing more researchers, rather than industry workers. After all, the institution needs to replace aging and retiring faculty members in order to continue existing. To do that, it needs to produce students who can become future researchers. And since research depends on theory, theory is emphasized, and pragmatism like debugging skills aren't really relevant. On the other side of the disconnect, the industry expects that students graduating from prestigious CS programs ought to know how to program. The hiring manager sees a degree from MIT or Stanford and is immediately impressed; but he doesn't have the technical expertise to realize what that degree actually means: that the student excelled in the primarily theory-focused program, which may or may not translate to practical skills like programming and debugging ability that would make them productive in the industry. All the hiring manager knows is that institution Y is renowned for their CS program, and therefore he gives more weight to candidates who hold a degree from Y, even if that actually doesn't guarantee that the candidate will be a good programmer. As a result, the software department is filled up with people who are good at theory, but whose practical programming skills can range anywhere from passably good to practically non-existent. And now these people with wide-ranging programming abilities have to work together as a team. Is it any wonder at all that the quality of the resulting software is so bad? T -- Amateurs built the Ark; professionals built the Titanic.