Thinking inside a bigger box - Latest Comments in Teaching good software design

Re: Teaching good software design

TelecommunicationS — Wed, 10 Jun 2009 06: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.

Re: Teaching good software design

Trond Arve — Mon, 30 Jun 2008 10: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.

Re: Teaching good software design

Trond Arve — Mon, 30 Jun 2008 10: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.

Re: Teaching good software design

Johannes Brodwall — Tue, 24 Jun 2008 12: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.

Re: Teaching good software design

Eivind — Tue, 24 Jun 2008 06: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.

Re: Teaching good software design

Marius Mathiesen — Mon, 23 Jun 2008 03:17:38 -0000

Being new to the term I had a good laugh; you just nailed it. It seems somewhat related to aesthetiritis, where a programmer (probably one new to, and sold on, Ruby on Rails) is so obsessed with making his code "beautiful" that it becomes totally ungraspable.