NYCPHP Meetup

[David Krings]

Hi,

    so you want to create high quality software. That is not only a task 
of developing. You want to address quality issues way before writing or 
even testing code. That would be during the design phase. Does the 
application design specify explicitly things such as input checking 
(what to check and what is to be considered OK), user interface design, 
modularization as much as possible, and things like that. Also, you want 
to tell your developers that any code passed on to QA has to be tested 
against a good set of test cases by the developer. Claiming that it 
compiles is not sufficient. Also, you want to come up with some coding 
convention and demand fully commented source code (which means comments 
for each line that have a code word or an operation in them). Also, see 
that you ideally get a tester to developer ratio of 1:1, not 1:20 as it 
is common in most places. I think 1:3 is reasonable (one tester for 
three developers). Include the testers, the developers, support, and 
customers in the design decisions. None of your developers will use the 
software on a regular basis, your customers will, so they have to say 
what flies and what not.

 From my experience, when the developer isn't absolutely and entirely 
sure that the code delivered is good code, there is no reason to make a 
tester suffer. And listen to the people at the front line, mainly 
support and the customers themselves. Uh, and get developers who know 
the industry and not just the latest tricks in coding. You can get to 
that by giving the developers plenty of training. And, put the 
developers into the support department for at least one day each month. 
Nothing straightens out a developer more than a bitching customer. Most 
developers need to experience the pain first hand to be convinced that 
their code is crap.

Besides that, you can read my MS thesis about just this topic. ;)

David K.

Brian Dailey wrote:
> Another "Ask the NYC PHP Crowd" question...
>
> I've been given the responsibility of developing a policy for a small
> (and growing) team of developers. By "policy" I mean defining how
> "development" code becomes "live" code. The point is to minimize
> problems in the program itself and the database behind it.
>
> How do you balance flexibility with minimizing risk? I've talked to a
> few of my fellow developers, and a few of them have talked about the
> usefulness of code review. That seems to be good idea, as does
> allowing only or two people to place development code on the live side
> (less cooks in the kitchen).
>
> Any suggestions on stuff I should think about?
>
> - Brian
>
>
>