Engineering I.E. Quality

[Michael Pyne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 09 April 2004 03:26, James Richard Tyrer wrote:
> First I
> design a program, and then I write the code.  Sometimes this is a cycle:
> Design, Code, Design, Code ... etc.  But I always design before I code.  I
> do this because it works.  It results in better code with less total work.
>
> Like I said on the Dot: Design twice, Code once.

Well, speaking as a programmer, I would tend to concur about the importance of 
design, even if it's just a paper sketch.  However, I think you underestimate 
the importance of design to the developers.  Sure, some programs could have 
used a much better design step (such as practically everything in kdeadmin).  
But things like KWallet and the KParts infrastructure are IMO good examples 
of a design process at work.

They certainly don't appear to have UML diagrams or such, but it still doesn't 
stink of an overnight hackfest.

Perhaps it would be better to come up a nice beautiful plan covering all the 
contingencies first.  That is certainly how we're taught to build projects in 
my CS major.  I personally find that I quickly lose interest in a program if 
I can't get SOMETHING coded within a few days after planning, however, which 
usually leaves me time for only a cursory design.  And that's a problem with 
volunteer effort:  If someone loses interest, then we get no contribution at 
all.

I think it's good to emphasize the importance of design (and Havoc P. has a 
good idea going with the Project Utopia use cases IMHO), but I don't feel 
from my observations that the KDE developers are unnecessarily ignoring 
design, even if they don't feel it is as important as you do.

I'm reminded of the example of John Romero, the designer for iD software when 
they made Doom.  He eventually left the company to found Ion Storm because 
the rest of iD kept letting those pesky technical issues interfere with 
John's vision.  The motto of Ion Storm became something to the effect of 
"Design is law", and the company became a spectacular failure, although it 
managed to produce a few noteworthy titles.

It's clear that you're not advocating designing the code with no regard to its 
eventual implementation, but (again speaking from my personal experience) I 
find that it's easier to design around a system's peculiarities when you're 
actually sitting there at the system.  I use an incremental approach: Design, 
code, test, code, test, test, test, code, etc.  If it becomes obvious that 
the design isn't working, I overhaul it before I get too much coded.

The initial design always helps, but it's never thourough.  And ironically 
enough, my program ends up better for it 9 times out of 10.  Of course, 
that's just me.  But I suspect more KDE developers pay attention to design 
that you think, even if they don't flesh out the entire structure at first.

Regards,
 - Michael Pyne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAdla7qjQYp5Omm0oRAuC2AJ9XVTwNahavisLuDmI48wM/qPTBzACgzTLc
GY/IwrR3RoAXKxg3hbIrd4M=
=tUxG
-----END PGP SIGNATURE-----