Re: [xml-dev] Re: URIs, concrete

["Alaric B. Snell" <alaric@alaric-snell.com>]

On Wednesday 31 July 2002 23:03, Simon St.Laurent wrote:
> Dare Obasanjo opines:
> > Maybe he is right, maybe he's wrong. The fact is that there are too
> > many apps out there to break over what is primarily an aesthethics
> > issue.
>
> First of all, I'm utterly sick of people using "aesthetics" to mean
> something isn't important.  If it looks ugly, there's usually an ugly
> problem inside.

I'm with Simon here; technical aesthetics (elegance of design, not which 
colour it is) are not to be ignored in engineering disciplines.

This has been a long running battle of mine - in my work, I always want to 
spend time designing things before building them. The reasons for this are:

1) Hacking code together without looking at the big picture first often 
wastes time because, towards the end of the project, you realise that the 
stuff you did at the beginning isn't sufficient to meet the needs of the 
modules you're now writing. You realise that information you discarded 
earlier on, thinking it was irrelevant, is actually needed again so you need 
to change data structures and argument lists and stuff like that.

2) Requirements always change. Things that have been designed into clean 
modules that fit together with no more interdependency than is necessary (an 
address book interface should expose the fact that an address has certain 
fields such as 'name' and 'email', but it should not have a method to obtain 
the name of the file each record is stored in, since you might want to shift 
it to an SQL database one day) tend to be much easier to adapt than 
hacked-together messes.

However, a lot of people have said "Pah, spending days designing a script is 
just a waste of time. You'll need to rewrite it from scratch anyway when 
requirements change."

But I've found that the actual programming is a lot faster if you've spent 
some time thinking it through first. And I've had a lot of success with 
changing software to meet changing needs.

Of course, how much time you spend initially designing is a tradeoff. Spend 
too much time planning and none writing, and you don't get any code.

> It's time to stop being slaves to bad ideas that happen to have an
> organizational stamp of approval on them.

Hurrah!