Robin Garner wheezed these wise words:
> What I'm saying is that tools that make the edit/compile/debug
> cycle quicker encourage people to do just that rather than
> think about the problem.
Good development tools encourage programmers to change the code when
they discover major design flaws. For example, throwing away large
chunks of code and replacing it with new code.
This may happen when the design spec changes, but it may also happen
when a programmer uses the insights they've gained, from writing the
code so far, to redesign and improve the code. It's not simply a bad
habit used by poor programmers. Some problems don't even have a spec.
The fact that some programmers are lazy is no excuse for making tools
hard to use. It is possible to think about a problem and write code to
solve it using friendly tools. The development cycle is sometimes not
as simple as edit/compile/debug. For many programmers, it can be more
like edit/compile/debug/demo. The feedback from users goes back into
the development of the code. Thus, no static spec.
This may possibly explain the popularity of Rapid Application
Development tools. Alternately, perhaps there are just a lot of lazy
programmers (and no users)?
BTW, I'm crossposting this to comp.lang.lisp, as this is a subject
that comes up from time to time in that ng. However, we tend to look
at it from a different perspective, probably because we have a lot of
neat tools that make the edit/compile/debug very short indeed.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
Martin Rodgers wrote:
>
> Robin Garner wheezed these wise words:
>
> > What I'm saying is that tools that make the edit/compile/debug
> > cycle quicker encourage people to do just that rather than
> > think about the problem.
>
> Good development tools encourage programmers to change the code when
> they discover major design flaws. For example, throwing away large
> chunks of code and replacing it with new code.
[more in the same vein snipped]
No argument with any of this.
The initial reason for this tangential subthread was to
counter the assertion that faster processors implied
faster code because you could test your code more
thoroughly.
Perhaps I was too facetious (for USENET, at least) in
suggesting that slowing down the tail end of the development
process improved software quality, although I _have_ observed
things that suggest this to me, and seen papers to support
this, although I can't find them at the moment.
The point remains that software quality is best improved
early in the process rather than later.
> BTW, I'm crossposting this to comp.lang.lisp, as this is a subject
> that comes up from time to time in that ng. However, we tend to look
> at it from a different perspective, probably because we have a lot of
> neat tools that make the edit/compile/debug very short indeed.
I wish you hadn't. I've put followups to comp.lang.lisp only,
because I don't want to be responsible for degrading the
comp.arch S/N ratio any more.
--
Robin Garner SMTP: Robin.Garner at assetservices.com-junk.au
VMS Specialist Snail: 169-171 Gladstone St. Fyshwick ACT 2609
Asset Services -- addresses munged to avoid spam --
+61 2 6285 7577