Hacker News Reader

Comment by gu | Hacker News Reader

I wasn't talking about insufficient test cases. Your remark about extensive unit tests is therefore quite irrelevant in this context as I don't question at all that the unit tests take border cases into account.

I am mostly concerned with "soft" aspects. Just consider the case where a student has to define variables, but picks variable names in a language other than English, or where control flow in a submission is more convoluted than it would have to be. Those are the cases I discuss in the article.

Moments ago, someone left a very fitting comment on my blog:

"I am taking the edX CS169.1 course and I find that I will consistently have a "less than elegant" solution that the auto grader accepts but that I feel is sub-par. The irony is this class has a large BDD/TDD aspect and is teaching RED-GREEN-REFACTOR, but with an auto grader once its green there is little reason to go back and refactor."

View on HN

Let me try to make my point by a "soft" analogy, in your terminology.

If a fiction book has a great, gripping plot and interesting, relatable, wonderfully done characters, then weird spelling and heavy sentences are not a big deal and can be easily fixed by a competent editor. But nothing can save a very grammatical and clean-written text that is just flat, boring, or makes no sense at all. Ask any publisher - which kind of books they prefer?

Similarly in software, getting the big picture right is much much more important than "elegance" in each individual line.

You are setting up a false dichotomy here. Speaking in your analogy, the question is not between grammatical and boring and ungrammatical and exciting, but between a novel that is gripping and grammatical versus one that may be as gripping but wasn't properly edited.

That comment on your blog is exactly what professional programmers do in the real world: pass the test suite and move on. After all, the goal of software engineering isn't to write elegant code; it's to deliver software that solves the customer's needs. And the customer's needs are tracked via the spec, not the style guide.

This is a short term attitude that is incompatible with building a system that grows mor ppwerful or a decade. That may be OK or maybe not, depending on your horizon and sunset plans.

IME it's not that binary.

In our corporate environment we do enough to pass the tests, with one extra 'test' being a peer review which should take into account a list of criteria that aren't easy to check for automatically; house code style, test code coverage, future maintainability, g11n/i18n-ness, etc.

We often only go as far as 'just good enough' but the standard to which that is assessed is pretty high.

Apart from the issue that we're talking about an introductory CS course, the greater problem remains that you'll only load up "technical debt", which may well lead to problems later on.

Michael O.Church briefly talks about this in his article on startup culture: http://michaelochurch.wordpress.com/2012/07/08/dont-waste-yo...

Also, see the recent HN post, "Ask HN: I just inherited 700K+ lines of bad PHP. Advice?": http://news.ycombinator.com/item?id=4557919

Lastly, in my article I highlight Open Office, which still has comments in German in its source code.

Reply on news.ycombinator.com