NYCPHP Meetup

[Ben Sgro]

Hello again, 

Great points all, Keith, Nicholas and Dan. I've read both 'Joel on software'
and 'Best software practices' which speak of many items I am having issues
with.

I began last month keeping track of every task assigned, the amount of time
and why something took longer than anticipated. I often find I waste 40-60%
just becoming familiar with the code, or finding some strange 'feature' that
Was depedenent on a script I just changed. With 'backward compatibility'
support no comments and duplicate code, script changes are similar to
mind-field sprints.

So, I have been preparing for a bit now, and I know the general mindset
among my fellow developers is that they do want 'more structure'. I've often
Heard and been in discussion with others regarding these very same issues.

>In the end, people generally want to do things the "right way", but they
>don't always know what that is - and they don't always like being told
>that they're wrong.  The hardest part of this will be introducing it to
>them gently in a fashion that doesn't put them off of it.  Don't focus
>on proving that you're right - focus on selling them on it.  Make them
>feel good about it, and make them feel good about supporting your ideas.
>I know, icky, but it works, and it's a rare skill in a technical person.

Well said.

>Depending on your situation, the security of the system can also be a
>source of leverage, effectively auditing and securing a system is much
>easier when it is cleanly laid out.  Any system dealing with client details
>(especially financial details) can be a huge liability if it is not
>effectively secured.

Turns out, since there is no one function used for input validation, I
easily performed SQL injection attacks on nearly any form, plus url params.
Very bad stuff.

>This is also a great idea, a little confrontational at first but very
>useful if there are a few stragglers once the majority are on board.

I am hoping this will hold true. This has motivated me to start with my
peers and hopefully management will realize it is helping everyone, it's a
win-win situation.

Thanks again, 

- Ben


Ps: Majority rule, doesn't work in mental institutions!


-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On
Behalf Of Nicholas Tang
Sent: Thursday, August 17, 2006 10:55 AM
To: NYPHP Talk
Subject: Re: [nycphp-talk] General Q; Programming Jobs & Expectations

I think, more often than not, you'll find that shops have poor practices
and barely readable code.  That seems to be the norm.

There's obvious value, of course, to having standards (even loose ones)
and structure (even a casual one) and to having best practices.  I think
selling your fellow developers on it won't be that hard - but you need
to get them to see the big picture, the long view, not just "but I've
got this project due tomorrow and I don't have time for comments!".  As
long as you are practical and take their concerns into account, they'll
listen.

As far as management?  From my experience, the best way to convince them
is to put together a business case.  It doesn't need to be on letterhead
and bound into a leather case, but it should provide a summary of the
project, and a fairly realistic view of the costs (and there will be
many, in terms of re-coding, documentation, etc.) and the benefits -
time saved in debugging, by avoiding recoding, etc.  Even better, break
it down step by step, for each aspect of the project, and show them how
each change will impact things.  At the end, give them an easily
digestible summary (yes, another one!), and keep it neat - tables or
charts are good.

Also, I'm a big fan of the skunkworks concept - next project you get,
write all of your code cleanly, document it, use includes, make it
modular, etc. and get the people working with you on it to do the same.
As you finish it, and get into debugging, adding features, etc. document
both how long it took you to write and how long it takes to maintain.
Document that vs. the messy stuff.  Chances are you'll have clear
numbers to support you and an actual practical example to present to
people.

In the end, people generally want to do things the "right way", but they
don't always know what that is - and they don't always like being told
that they're wrong.  The hardest part of this will be introducing it to
them gently in a fashion that doesn't put them off of it.  Don't focus
on proving that you're right - focus on selling them on it.  Make them
feel good about it, and make them feel good about supporting your ideas.
I know, icky, but it works, and it's a rare skill in a technical person.
;)

Nicholas


> >  From: talk-bounces at lists.nyphp.org 
> [mailto:talk-bounces at lists.nyphp.org]
> On
> > Behalf Of Ben Sgro
> > Sent: Thursday, August 17, 2006 9:51 AM
> > To: talk at lists.nyphp.org
> > Subject: [nycphp-talk] General Q; Programming Jobs & Expectations
> > So, my question is: Is it unreasonable of myself to have 
> expectations of
> > 'engineered' code or is this (current job) just the way things are.
> >
> > Is it crazy to think I can change things from the bottom, 
> by writing the
> > specs and speaking with the other programmers to reach a 
> consensus on
> 'best
> > practices' and create 'grassroots' support? Should I just 
> 'suck it up' and
> > put in my time, then move to another job?
> >
> >
> >
> > I've been consulting along with my fulltime work for about 
> 2 years now,
> and
> > I believe that is what I truly enjoy, being my own boss.
> >
> > But I do need a paycheck every week, so this is not yet a viable
> > alternative.
> >
> >
> >
> > Thanks for your time, I am eager to view your responses!
> >
> >
> >
> > - Ben
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
> >
> >
> >
> _______________________________________________
> 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
> 
> 
> _______________________________________________
> 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
> 
_______________________________________________
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