Elliotte Harold wrote:
David Krings wrote:
[EMAIL PROTECTED] wrote:
too (security and quality never got any space on the project priority
list obviously).
From my experience that is true for 90% of all software projects.
Only documentation ranks lower.
In my experience, quality arises from good development practices like
test-first programming, pair programming, proper object oriented design,
internalization of coding conventions, DRY, and a host of other small
factors. It's not something you assign a time block to and put in later.
I didn't mean it in a way of how much time gets allocated. I think it is
reasonable to allocate as much time for testing as there is allocated for
writing code, better even more since the testers have to check more than just
the code, but also end-user documentation, sales literature, process
descriptions, specs, docs for support, auxilliary applications, installation,
and and and
Programmers who write quality code do not write code slower than
programmers who don't. If anything they produce more lines of code per
day, and their code does more. Possibly, if you have an inexperienced
team just coming up to speed with good development practices, then
there's some training time to learn and internalize good coding
practices. Nonetheless, even if you have to spend two thirds of your
project schedule sharpening a dull ax, you will cut the tree down faster
than if you just start hacking away.
Nicely put. Quality code is one of the biggest savings potentials for a
software company. If you are a carpenter and only have crappy tools and crappy
material the hut you build will collapse sooner than later. The same mechanism
apply to software. Nevertheless, I wittnessed many times what I call
"developer arrogance" where writing quality code was not seen as a necessity,
since "support can deal with it".
Quality is not something you can accept less of to complete a task
faster. If you omit quality from your code, the project will take more
time to complete.
I disagree, you can take shortcuts, such as not documenting code and omitting
anything other than the "how it is supposed to be used" path. One might argue
that this would not constitute project completion, but when time and money are
scarce for a software project the QA and doc team get cut and 'cheaper'
developrs get hired to do the job. Typical behaviour in companies where
shareholder value (short term gain) is valued more than product quality (long
term gain).
Too bad that the coding team that crafted the broken code cannot read our
discussion. I also think that at he origin of this thread the fact was well
established that the code in question does not adhere to any higher quality
standards. Which even makes my proposal more plausible: rip it out and do it
the right way. Otherwise more fixing will be needed and the code won't get
that much better.
David
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
