NYCPHP Meetup

[Brian Dailey]

So, David, where can I get a copy of your thesis? :P

- Brian

>
> On 10/19/06, David Krings <ramons at gmx.net> wrote:
> > 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
> > >
> > >
> > >
> > _______________________________________________
> > 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
> >
>