Comments on: Two kinds of software challenges

By: Tad

Tad — Mon, 06 Feb 2012 15:08:56 +0000

Curious on your rationale on “verifiability” and “testing” being on the 2nd list. Always thought those were ones a bit easier to solve and not ones that permeated the entire project. Clear or clarified requirements and then either good-quality QA folks, or good-quality automated tests don’t always require a re-work of the whole project – though (depending on scope of project) I’ll concede that automated testing can.

By: deadalnix

deadalnix — Mon, 06 Feb 2012 15:05:42 +0000

Problems on the second list must be considered during the dev of the project. They have to be refined each time you get a better understanding of the project.

I see a lot of project wanting to go forward without considering it. You end up with a unmaintainable mess. You have to solve these issue little by little each day, mainly by fighting against entropy.

By: Roger Marlow

Roger Marlow — Wed, 10 Jun 2009 13:07:28 +0000

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.

By: John Moeller

John Moeller — Fri, 05 Jun 2009 03:31:55 +0000

This requires practice, and Computer Science professors typically don’t write *any* software. Ever.

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.

By: Daniel Lemire

Daniel Lemire — Fri, 05 Jun 2009 02:44:05 +0000

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.

By: John Moeller

John Moeller — Fri, 05 Jun 2009 00:12:05 +0000

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.