4 ms·

Is "one in, one out" a silly rule? e.g. you can only add a new step to a process if a step is removed from another.

by jbert 18y ago

mechanical_fish 18y ago
Is "one in, one out" a silly rule? Yes. ;) When do you institute the rule -- on day one, in which case it is functionally equivalent to "do not have any checks"? On day 13? Day 7386? What is the quantum of a "check"? Is Sarbanes-Oxley one "check" or a collection of hundreds of "checks"? Does the limit apply department-by-department or company-wide? Your sysadmins will naturally tend to employ a lot more formal checks (most of which are hopefully enforced by tiny Perl scripts) than your R&D prototyping team. Do you force the sysadmins to compete with the accounting department for a quota of checks? Do you incentivize sysadmins to evade checks by getting tasks reassigned to the R&D prototyping team, which (alas) can't afford to have any checks? The last thing you want to do is encourage teams of lawyerly meta-checkers to run around enforcing rules about rules. That's costly, squared.
- jbert 18y ago
  "When do you institute the rule?" When you realise you have a (potential) problem. It stops it getting worse. "What is the quantum of a 'check'?" More tricky, certainly. That's a potential big problem. "Does the limit apply department-by-department or company-wide?" Whatever makes sense. The idea of the exercise would be basically to: - build an appreciation throught the organisation that checks have a cost - provide a (albeit imperfect) mechanism for exercising some control over it Something doesn't have to be perfect to be of use. "The last thing you want to do is encourage teams of lawyerly meta-checkers to run around enforcing rules about rules. That's costly, squared." That's just ISO9001, isn't it? :-)
run4yourlives 18y ago
Well yes, because that assumes that there is some magical amount of checks that must never be exceeded. Some checks are extremely valuable and should be added based on their merits alone.
- alextp 18y ago
  That's the point I was trying to make. Something like "always commit and run the tests before going to production" makes a lot of sense, and should be mandated. Even something like "three signed copies of an authorization form" makes sense for some projects if, for example, the cost of damages (say, lost data, downtime or annoyed paying customers) is big enough. Measuring this, though, is the hard part. It's like trying to do the math behind "no silver bullet" and estimate communication costs (too many unknowns and conditional dependencies).
  - eru 18y ago
    How about just measuring how many bits it takes to describe the checks (perl code etc + informal text). Do not make any hard and fast rules - just monitor this metric.

Is "one in, one out" a silly rule? e.g. you can only add a new step to a process if a step is removed from another.

by jbert 18y ago

Is "one in, one out" a silly rule? e.g. you can only add a new step to a process if a step is removed from another.

Is "one in, one out" a silly rule? Yes. ;) When do you institute the rule -- on day one, in which case it is functionally equivalent to "do not have any checks"? On day 13? Day 7386? What is the quantum of a "check"? Is Sarbanes-Oxley one "check" or a collection of hundreds of "checks"? Does the limit apply department-by-department or company-wide? Your sysadmins will naturally tend to employ a lot more formal checks (most of which are hopefully enforced by tiny Perl scripts) than your R&D prototyping team. Do you force the sysadmins to compete with the accounting department for a quota of checks? Do you incentivize sysadmins to evade checks by getting tasks reassigned to the R&D prototyping team, which (alas) can't afford to have any checks? The last thing you want to do is encourage teams of lawyerly meta-checkers to run around enforcing rules about rules. That's costly, squared.

jbert 18y ago
"When do you institute the rule?" When you realise you have a (potential) problem. It stops it getting worse. "What is the quantum of a 'check'?" More tricky, certainly. That's a potential big problem. "Does the limit apply department-by-department or company-wide?" Whatever makes sense. The idea of the exercise would be basically to: - build an appreciation throught the organisation that checks have a cost - provide a (albeit imperfect) mechanism for exercising some control over it Something doesn't have to be perfect to be of use. "The last thing you want to do is encourage teams of lawyerly meta-checkers to run around enforcing rules about rules. That's costly, squared." That's just ISO9001, isn't it? :-)

run4yourlives 18y ago

Well yes, because that assumes that there is some magical amount of checks that must never be exceeded. Some checks are extremely valuable and should be added based on their merits alone.

alextp 18y ago
That's the point I was trying to make. Something like "always commit and run the tests before going to production" makes a lot of sense, and should be mandated. Even something like "three signed copies of an authorization form" makes sense for some projects if, for example, the cost of damages (say, lost data, downtime or annoyed paying customers) is big enough. Measuring this, though, is the hard part. It's like trying to do the math behind "no silver bullet" and estimate communication costs (too many unknowns and conditional dependencies).
- eru 18y ago
  How about just measuring how many bits it takes to describe the checks (perl code etc + informal text). Do not make any hard and fast rules - just monitor this metric.