Here’s a quote from Bricklin on Technology regarding what colleges should teach in software engineering. (I added the bullets.)
For years we emphasized
- execution speed,
- memory constraints,
- data organization,
- flashy graphics,
and algorithms for accomplishing this all. Curricula need to also emphasize
- robustness,
- testing,
- maintainability,
- ease of replacement,
- security, and
- verifiability.
The criteria in the first list are primarily mathematical. The criteria in the second list have more to do with human nature. For example, code is maintainable if it’s organized so that a person can readily understand and modify it. That’s a matter of psychology.
More projects fail due to problems with the second list. Problems with the first list tend to be localized. Problems with the second list tend to permeate a project. A clever person may have a quick fix for problems with the first list. Quick fixes are rare for problems on the second list.
{ 4 comments… read them below or add one }
John Moeller 06.04.09 at 18:12
Excellent article. I’m in absolute agreement. Since I’m in training to be an algorithmist, I can’t quite say that it’s a good idea to ignore the first list
(with the exception of graphics; I really don’t care about visual UX, because there are people far better at it than me). But I agree; algorithms are best implemented as a module.
My experience as a software engineer has taught me that every single item in the second list will cost time. These are all items that must be considered from design through maintenance, but are too often attempted as turnkey implementations or duct tape/spackle/bailing wire at the last minute.
Daniel Lemire 06.04.09 at 20:44
Great point. However, robustness is commonly addressed mathematically. Something like “rate of failure”. We probably could model mathematically all elements on the second list.
It seems to me that the first list describes “core Computer Science” whereas the second list is more about “good software design”. Don’t expect a Computer Science professor to know about designing good software. This requires practice, and Computer Science professors typically don’t write *any* software. Ever.
John Moeller 06.04.09 at 21:31
Or if they do, it’s a one-off that doesn’t ever get integrated into anything, and thus doesn’t need to meet the restrictions noted in the second list.
There are curricula that attempt to address these issues through teamwork and long-term projects. Unfortunately, there are software engineers (thankfully in the minority) who never learn these principles in the workplace either.
Roger Marlow 06.10.09 at 07:07
I agree. And your point that items in the second list have more to do with psychology and human nature is important. It is people that commission, manage, design, build and use software; every aspect of software creation is impossible without people, yet students of software are taught little or nothing about how they “work”. Indeed they are predisposed to be disinterested, even antagonistic, towards any efforts to teach them psychology let alone soft skills. Interestingly there was a similar problem in Economics (i.e. it was dominated by a narrow mathematical world view) but Behavioural Economics is changing all that. Will there be a similar movement in Computer Science and Software Engineering? I believe it is overdue and academia could provide leadership in this area.