[thelist] setting team standards and guidelines

[Martin Burns]

Yeah, I'd agree with Hassan.

Work out what your True North is (ie unreadable perfection) - you want to be able to 
Never unrecoverably overwrite each others changes
Merge code
Be able to find build breaking problems almost instantly
Keep code manageable (2000 line methods: probably unhelpful)
Be able to regression test new code without pain
Release features as soon/late as they're ready rather than work to artificial deadlines
Etc etc
And then get the team to come up with why you can't do that now, and solutions that are closer to the goal. Reaching it in one step isn't necessary, as long as you keep taking steps towards it.

Read W Edwards Deming - A Bad System Will Beat A Good Person Every Time

cheers
Martin





On 24 Apr 2012, at 19:23, Hassan Schroeder <hassan.schroeder at gmail.com> wrote:

> On Tue, Apr 24, 2012 at 9:38 AM, Jeremy Weiss <eccentric.one at gmail.com> wrote:
> 
>> Basically, they have a room full of developers who each do things in
>> their own ways. There's no set guidelines for how things are done.
>> Some code in vim on the dev server while others check code out of the
>> svn and code locally. Some commit things back at the end of the day
>> regardless of stability, others only commit stable code. There's no
>> guidelines for when to branch or merge code.
>> 
>> Does that help explain things any better?
> 
> Yes, and it does sound painfully broken to me :-)
> 
> That said -- those seem like artifacts of a lack of team focus. But to
> play devil's advocate: so what? What problems are being caused by
> these inconsistencies? If you can point to a group goal that can't be
> achieved, the solution should be pretty obvious (e.g. we want to do
> a daily feature release, but we can't because the main branch is
> sometimes broken, so let's agree to only check in working code).
> 
> If there's no such goal, there's no reason to change my preferred
> (comfortable) work style -- so maybe that's the bigger problem.
> 
> There's always more than one way to do things, and "best" always
> depends on context. Guiding the team members to come up with
> a *working* solution to a problem that's preventing reaching a goal
> enhances the likelihood of adoption (as well as fostering a mindset
> of continuous process improvement).
> 
> FWIW, and good luck!
> -- 
> Hassan Schroeder ------------------------ hassan.schroeder at gmail.com
> http://about.me/hassanschroeder
> twitter: @hassan
> -- 
> 
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
> 
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !