Communication Is Procedural

At various times, in various places on Wiki, people have talked a little bit about teaching. The gist of the question being "how do you teach good software practice" (for example, TeachingSimpleVsComplexSolutions or TeachingPatterns).

There's an old software maxim. One variant of it goes: First build it, then build it right, then build it fast.

The teaching version seems to be: Teach them how to do it, then teach them how to do it correctly.

An example: I'm trying to figure out how to explain JDBC. And the solution I keep coming up with is:

Write a hunk of procedural code that embodies that would happen if everything went right and there were no other point to the program than making the one call.
Then explain how to do things right.

Which makes sense; simplify everything to communicate the core idea and then gradually back off the simplifications. But it also means that complaints about CS departments (they don't teach people how to program) are probably never going to bear fruit; there are sound pedagogical reasons why most of the code in CS courses is ugly.

WilliamGrosso

In one of the bigger surprises of the year, to me, the above turns out to be completely incorrect. The (anecdotal) evidence so far is that well-factored code, with all its implicit flexibility, is easier for people to understand than the single-line-of-execution procedural stuff.

WilliamGrosso

Very interesting, William, please tell us more!

I'm not convinced that well-factored code is easy to write. At least not off the top of one's head. I agree that once the code is written, and refactored, it is easier to read and maintain. I have a problem with the idea that someone can write well-factored code without knowing something about the various objects and their interactions within the domain. Once the code (a SpikeSolution) is cobbled together, it can either be thrown away (and then written properly), or refactored.

CS exercises also have to take into consideration that not every programmer is brilliant, so you show them what to do, and then take them through the refactoring process.

The other thing to remember is that, since these are students, they are more-or-less guaranteed to have little knowledge about the given problem domain.

It's only through writing hunks of procedural code that the shape of the solution becomes clear.

I wonder whether there is any link to the 3rd-normal-form business, or whether you have encountered a different issue. Our company originally wrote the "methodology" to recommending designing the database, and had a special step called, "put it into 3rd normal form". Oops. Turned out the better approach was to teach them to think directly in 3rd normal form. Shorter path to good design, fewer errors, less expensive. Is your situation similar or different? AlistairCockburn

3NF is part of it. The other part is that it seems to be easier to remember the well-factored version. There's an initial hit in reading the factored code (as opposed ot the procedural version) and I thought that, in a classroom setting, that hit would dominate the costs.

Turns out, I think, that having the cognitive chunking done for you is very helpful for a newcomer ("this is how someone who's worked in this area would factor this" turns out to be useful information, even over the compressed time scale of a single course).

Like I said, surprised me.

WilliamGrosso

If I wanted to become a good fiction writer, I would read from the best books, from the most eloquent and stylistic authors, instead of canned exercises. And I would read as many books as I could get my hands on...

And then I would write until my fingers fell off...

I have learned more about programming style by working with a small subset of InterViews than I ever could by reading procedural, 'simplified' examples.