Comments on: Teaching good software design

By: TelecommunicationS

TelecommunicationS — Wed, 10 Jun 2009 15:19:57 +0000

Designing usable software is difficult, and teaching others how to do it is worse! Although useful methodologies exist, it is not possible to teach someone simply “how to do it”. To be capable of doing more than producing Microsoft clones, student designers need a broader approach to the task, one that has important attitudinal, aesthetic and creative components.

By: TelecommunicationS

TelecommunicationS — Wed, 10 Jun 2009 08:19:57 +0000

By: Trond Arve

Trond Arve — Mon, 30 Jun 2008 14:05:19 +0000

A typo at the end, sorry: In any case, giving general advice when I don’t know the problem well enough often fails.

By: Trond Arve

Trond Arve — Mon, 30 Jun 2008 14:03:57 +0000

One piece of advice that might be useful in most situations is to start learning about your problem domain. Writing tests is a way to start learning. Working with examples you have to think about how your solution is to be designed and used by clients. Of course there are many more ways to learn, like drawing models on a whiteboard, discussing the problem with others or just start hacking. I tend to prefer tests, but I appreciate that testing requires experience and can be a hard path to follow. In any case, giving general advice when you I know the problem well enough often fails.

By: Trond Arve

Trond Arve — Mon, 30 Jun 2008 12:05:19 +0000

A typo at the end, sorry: In any case, giving general advice when I don't know the problem well enough often fails.

By: Trond Arve

Trond Arve — Mon, 30 Jun 2008 12:03:57 +0000

By: Johannes Brodwall

Johannes Brodwall — Tue, 24 Jun 2008 16:11:30 +0000

Hi, Eivind

Thanks for another insightful comment. As you say: We shouldn’t stop doing object-orientation. My experience is that I should only stop recommending that others choose object-oriented solutions when asked for my input.

Trying to force people to use object-orientation (or testing for that matter) without proper understanding is probably not a good idea. With teaching tests, at least I know what to point to as good examples that won’t lead people astray. With OO… not so much.

By: Johannes Brodwall

Johannes Brodwall — Tue, 24 Jun 2008 14:11:30 +0000

Hi, Eivind

Thanks for another insightful comment. As you say: We shouldn't stop doing object-orientation. My experience is that I should only stop recommending that others choose object-oriented solutions when asked for my input.

Trying to force people to use object-orientation (or testing for that matter) without proper understanding is probably not a good idea. With teaching tests, at least I know what to point to as good examples that won't lead people astray. With OO... not so much.

By: Eivind

Eivind — Tue, 24 Jun 2008 10:22:59 +0000

There are a lot of deseases out there, for example architecturitis, analysis paralysis and big design up-front, just to mention a three. And why not add object-orientation itself to the list? It is much like eating and drinking, it may give you a lot of pleasure, but abused, it often results in a lot of pain. But that doesn’t mean that we should stop doing it, does it?

I think a keyword you mention here is “needlessly”. I use to teach that if you don’t possess the modelling and abstraction capacity required for doing good object-orientation, you’d better stick to the plain, old, structured way of thinkink. At least, that gives you something that is working in the short term, although perhaps not as modifyable in the future. Object-orientation and architectures are good for managing changes. At the same time, changeability implies complexity, so they ought to be kept at a minimum. In fact, we may make everything changeable, at the price of making is so complex that it is not changeable any more. That, may be, is a good definition of architecturitis.

By: Eivind

Eivind — Tue, 24 Jun 2008 08:22:59 +0000

I think a keyword you mention here is “needlessly”. I use to teach that if you don't possess the modelling and abstraction capacity required for doing good object-orientation, you'd better stick to the plain, old, structured way of thinkink. At least, that gives you something that is working in the short term, although perhaps not as modifyable in the future. Object-orientation and architectures are good for managing changes. At the same time, changeability implies complexity, so they ought to be kept at a minimum. In fact, we may make everything changeable, at the price of making is so complex that it is not changeable any more. That, may be, is a good definition of architecturitis.