A bright lines is a rule designed to limit interpretation, usually by having specific and measurable standards. A simple example would be the speed limit. If you're doing 55 in a 54, you're breaking the law.
In contrast, a guideline provides directional boundaries while leaving room for personal judgement and interpretation. A programming style guide helps development teams increase code readability by creating consistent visual patterns, but there's room for the individual programmer to recognize that the default isn't appropriate and make a different choice.
Bright lines are simple to implement at the expense of losing all nuance. We want that nuance and we're counting on you to help us capture it. If you work at Expected Behavior, it's because we think you're a smart person dedicated to critical thinking, honest self-assessment, and continuous improvement. If you think the company guidelines are appropriate for your situation, use them. If you don't, don't.
That is not to say there are no boundaries. Guidelines lack the specific and measurable limits of bright lines, but there must be limits. That limit is the judgement of your coworkers. Let me explain with a simplified example from company history.
Once upon a time, two engineers were doing some significant work on DocRaptor. They fell behind schedule. Many months behind schedule. To speed up a major part of the project, they decided to skip a significant portion of the relevant safety checklist and deploy on a Friday afternoon. That Sunday, we had the longest and most expensive downtime event in company history. If they had followed the checklist, the project would not have been ready for a few more weeks (or more). If they had followed the checklist, the downtime would have been trivial (or might not have happened at all). Here are some questions you might ask yourself to decide if what those engineers did is acceptable:
- Did they make a mistake? Not all bad outcomes are mistakes. If all the available choices are bad, even the least worst choice will be unpleasant.
- If they made a mistake, was it a reasonable mistake? Sometimes more than one choice can seem good. If 100 reasonable engineers were given that same choice, how often would this mistake have happened?
- If they made an unreasonable mistake, was it out of unavoidable ignorance? Unknown unknowns catch everyone sometimes. Did they make all reasonable efforts to have the necessary knowledge or engage others with the necessary expertise?
It might sound heavy when written out like this, but it's really just a lengthy way of saying "individuals and interactions over processes and tools". We're a small company. Talk to people, be available for them to talk to you, listen, and respond to change.