Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: Setting boundaries in software development

by Your Mother (Bishop)
on Sep 27, 2013 at 14:54 UTC ( #1055991=note: print w/replies, xml ) Need Help??

in reply to Setting boundaries in software development

Enforced style, especially where it is automatic, can be good. So I say. With such a system, everyone can have their own little style quirks in one's own editor that won't constantly show up as meaningless changes in commit diffs. The temptation to bikeshed indentation or brace placement, etc, goes away, and the risk with having your own cperl-mode or whatever also goes away. Mostly, kinda, sorta.

Documentation cannot be automated (well). I think a Pod coverage test that fails when subs/methods aren't documented (or license/synopsis/etc is missing/erroneous) is fine and I appreciate it because I forget to do that most of the time without a test.

I also think your previous practice of allowing "loose" commits was the best choice. Nagging is preferable to locked doors at the dev stage. Hard barriers make for unhappy work, and as you mentioned: gaming the rules. (Auto-)guides and peer pressure are better/friendlier for group standards.

The real problem with setting boundaries, AKA PROCESS, is that it almost guarantees sclerosis. Process gets less flexible and covers more ground over time, blocking out possibilities for improvement and innovation in work flow. So revisiting and being open to revising or trimming boundaries is something to consider and reconsider often.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1055991]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2018-04-25 22:37 GMT
Find Nodes?
    Voting Booth?