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.
|
|---|