[thelist] setting team standards and guidelines

[Hassan Schroeder]

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