Two Ways To Design

There's a quote from TonyHoare from back in 1980 which goes:

"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."

I wonder whether people here agree, and how they would rate their favourite/ least favourite design notation/ method.

I can't imagine how to design a web-site so there are obviously no deficiencies. I'm not even sure I've ever seen one with no obvious deficiencies; the problem being that, unlike an app, users of a web site are generally exposed directly to most of its complexity.

Here's a go at imagining this;

Use a single page,
Use only text and 'standard' HTML.
Any links in the page link to points in the page

Not sure it would provide a useful web site, but with these constraints I'm sure you could fairly easily show there are no deficiencies.

: From the point of view of the user, both exist, and if only the two choices exist, the preference would be the first. A site which simply presents a single page or presentation, with associated images and text, with the information you expected when you branched to it, and no links to other pages or sites for the completion of the activity. The completion of the activity would be to click the back arrow.

Hmm, here's a different split on TwoWaysToDesign. You can either start from the UserInterface and work back to the objects and database to support it, or you can start with the SoftwareDevelopmentTools? and a bunch of index cards and use XP to deliver incremental functionality.

Okay, TopDown versus BottomUp.

If you use only one page, is it really a [web]site? It should be relatively common knowledge that a web site should be a collection of 30k or under pages, hyperlinked where necessary. Regarding design, that depends on your audience. The more frills and fizz, the less intelligent the target audience usually is. That is frizz and frills without content. -- AluoNowu

ChuckMoore (of Forth fame) prefers websites that are designed like slide presentations, and has good arguments for it. Don't pack too much information on a page, but don't put too little on it either. If and when you need to design a site, see if you can rearrange it into a presentation-like format. That seems to make websites much simpler to navigate. It's certainly not suitable for everything, but it's amazingly adaptable for a wide variety of sites.

Also, Hoare's quote was specifically relevant to software design, not necessarily to UI design. Still, the philosophy of doing something so simply that it's obviously correct just screams for BottomUp implementation and arguably design as well. And it makes sense; given four pieces of code that are patently correct, and a suitably enforced contract between them (preferably compile-time checking, but also by way of unit tests too!), it should be possible to combine those four pieces into a correct, higher-level program too.

-- SamuelFalvo?

Screams for BottomUp design? I'd think the opposite. With BottomUpDesign, you can miss whole subsets of functionality and never notice because you're too focused on the little pieces you're putting together. Even if you can prove each piece at the bottom is correct within its specification, you can't be sure that its specification was correct, or that the gestalt you'll have by putting the pieces together is correct... that's the flaw of the BottomUpDesign.

I'd say Hoare's quote applies when the goals/requirements are clear and fixed (for it is impossible for a fixed design to meet moving goals or for an explicit design to meet hand-wavy-vague goals). However, in those rare cases where the quote does apply, it calls for a TopDownDesign: you break the overall goal into abstract parts, prove that putting those parts together will be sufficient to meet the requirements (without violating any constraints), then do the same for those abstract parts... all the way to the bottom. There will be many valid approaches, but this is essentially a constraints-bound search for a plan, and at the end you'd be able to prove that there are no deficiencies.

Of course, once you have the design, BottomUpProgramming is appropriate. At that point you've PROVEN that you ARE going to need it.

BottomUpDesign (a'la implementing 'UserStory's) works better when one's goals are unclear, hand-wavy, or unfixed. For that, you go after one goal at a time to figure out what is really appropriate, all the while trying to avoid breaking those you've already implemented. This approach, however, makes it extremely difficult to handle negative requirements and goals that exist only as emergent properties of the system (e.g. security, privacy, 'snappiness', hard real-time, etc.). Even when you meet them, you often can't prove them in the corner cases.

CategoryQuote