[SATLUG] IO-InfoOnly: PHP Eats Rails for Breakfast

[Justizin]

On 12/6/06, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> K. Spoon wrote:
>
> > But if I'm on a team where everyone else is churning out 200 lines a day
> > and the newly minted BS/CS is bragging about how he's doing 500... to
> > me, that's a warning sign that someone needs to go check his work and
> > reign him in if need be
>
> I tend to agree, but would point out that but the new and the old
> programmer's code needs to be checked.  If after checking the one doing
> 500 is more productive is doing more work.

Again the type of work is also more important.  More productive is a
term I hate, although I'm sure I abuse it as much as anyone.

Let's say I have one year of experience with a project, and I complete
100 requests per week to change or fix it, outputting, in any given
week, between 500 and 2000 lines of code, and one of my compadres has
three years of experience on the same project.

Perhaps I'm outputting 2000 lines of code because each of 100 requests
requires 20 new lines of code, even if 20 of those requests are for
something very similar.  Although I'm rather productive, I have a
problem, so I talk to my cohort:

  "Dude, it's too much trouble to make this type of change and I have
to do it all the time."

Maybe he only completes 5-10 requests per week, but if they are
requests from junior team members, like myself, they probably carry
far more importance.  For one week, I might still do 20 repetetive
changes to keep the wheels of business moving, but I'm going to crash
soon if this doesn't stop, because there are 200 of these changes
needing to be done within a month, and that's an order of magnitude
more than I am handling now.

After the end of this grueling week, my cohort comes to me and says:

  "Voila!  A tool!  Now those changes take three lines of code which
can be generated from a single line of XML."

This is great.  I spend two weeks writing 200 lines of XML and process
the remaining changes all at once, freeing up time to frolic in the
sunlight.

A few weeks down the road I may start thinking:

  "Hm, I wonder if I can build the paramaters of this XML file into
the request form people fill out - then I won't have to spend a week
writing long XML files, I can just review the requests, approve the
paramaters as valid, and push them out.  In fact, I can probably write
validators for the input, trust it, and allow people to
instantaneously generate code for deployment into production."

Neither of us was more productive, we worked as a team, separated
concerns, and now either:

  (a) have a lot of free time to talk about improved performance strategies
  (b) have happy customers who are less afraid that requests they
submit won't be handled in time.

Beyond that, if this is the first time we've done something like this,
we've done the most productive thing of all - we learned how to
leverage our combined resources to solve problems more efficiently
than either of us could on our own.

> The QA team's job is not to change code.  Its not just testing either.
> An important job is to see if programming standards are followed.  Just
> look at the Linux kernel--if you don't follow the standards, the patch
> is rejected.  Then the submitter has to redo it.  Now it takes another
> day to fix it.  That 500 lines/day is now 250 lines/day.
>
> Productivity is not just code output, it is accepted, tested code.
>

Depends on what you are doing. Productivity could be accepted, failing
tests, a redesign with adequate justification that works enough to
talk about, but isn't production ready, etc..

All phases of development are important, and QA is important to all phases.

> >> In your comments above, you automatically assume that the person
> >> producing more SLOC is producing lower quality code.  In many cases, the
> >> high SLOC producer also produces better quality code.
> >
> > If more is better quality, then why did you reduce the SLOC by 50% in
> > your FORTRAN anecdote?  Also, would that program not have been easier to
> > maintain before then if it had always been 20K lines of code instead of
> > 40K?
>
> That was a rewrite after all code was available and tested.  In that
> situation, you can better take advantage of redundancies.  In this case,
> the code was written in the mid 80s.  When I rewrote it, there was this
> radical new statement (for Fortran) called "include..." :)
>

woop, reminds me of when PHP got properties.

-- 
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/