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.
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.
The more complex a software project is, the more important quality
becomes. It is a precondition for developing critical systems. You can
no more leave it out than you would leave out the condition that the
code compiles (or interprets, for PHP). You may not put it into the list
of priorities, but if quality isn't there in sufficient quantity, the
project will fail.
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.
Security is part of this. A team that knows and understands basic
principles of security, like using prepared statements, will not take
any longer to develop a system than one that doesn't. However if you
first have a team that doesn't understand security build a system; then
have a second team of security specialists fix all the mistakes the
first team made, then yes; it will take you longer and you will need a
place in your schedule to put in security.
The key is to make sure that your team has sufficient experience and
knowledge of the relevant quality factors such as security that they
don't make a lot of mistakes in the first place. Sometimes this just
means hiring the right team. Sometimes it means hiring one good person
and letting them instill those values in the rest of the team members.
At worst, it means sending the team away for training and giving them
time to read the relevant books. That you may have to schedule for. But
it's still more efficient to sharpen your ax before you cut down the tree.
--
Elliotte Rusty Harold [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
_______________________________________________
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
