3 ms·

I think always is overstating things a little, but you are right that you have to be very aware of perverse incentives and, the more process you bring in, the h

I think always is overstating things a little, but you are right that you have to be very aware of perverse incentives and, the more process you bring in, the higher the likelihood that your process will interact in strange, unexpected ways to create those perverse incentives.

btilly 14y ago
If you think that always is overstating things a little, can you give me an actual example of an actual process at an actual company that creates no possibility of perverse incentives?
- SoftwareMaven 14y ago
  "All commits should have a message and commit messages should be explanatory." This is an actual process in my group at the company I work for. Process doesn't have to be heavy and invasive. And what's the alternative? Zero process? Everybody has to "wing it" all the time? I can't see any possibility for a perverse environment there!
  - btilly 14y ago
    Who defines what "explanatory" means? And what is the resolution if there is a disagreement? I, personally, am happy with a commit message like, Refactoring needed before #12345 can happen. I've said what I was doing, and why, and presumably in your ticket system there is a ticket 12345 that has more detailed explanation. Other programmers will disagree. "Explanatory" means different things to different people, and complex arguments can erupt. (Conversely if your commit essay lacks a concise first line to show up in blame, is that explanatory? Should you always have a ticket #?) Furthermore there is a type of person who enjoys asserting power through language lawyering. That kind of person will see that policy as a golden opportunity to acquire influence, even though the cost may be unnecessary conflict to little point. If such a person manages to assert control of a process element like that, you can easily get a type of teamicide that drives away good developers who don't want to deal with the BS of figuring out whether their essay was good enough to avoid an email lecture. As for the alternative, I thought I was clear on that. Large groups cannot work without process, small groups can mostly get by on common sense. The imperfections of processes do not change their necessity in many cases. But if you, personally, do not enjoy dealing with process, then you should find opportunities to work in more congenial small groups.
artsrc 14y ago
You can question whether the perverse incentive will be exploited. For example lets say the rule is that "C# code must be compiled before it is run." The incentives are to declare code compiled when it is not, to declare that you are not running code when you are, and to declare code to not be written in C#.
- btilly 14y ago
  The additional perverse incentive is to extend the rule by banning all languages that do not have an equivalent compilation step. Which means that scripting languages are not available.
  - SoftwareMaven 14y ago
    You can extend anything to an absurd degree. That does not make it a strong argument.
    - btilly 14y ago
      What makes you think that extension is absurd? I based that on a real example!

btilly 14y ago

If you think that always is overstating things a little, can you give me an actual example of an actual process at an actual company that creates no possibility of perverse incentives?

SoftwareMaven 14y ago
"All commits should have a message and commit messages should be explanatory." This is an actual process in my group at the company I work for. Process doesn't have to be heavy and invasive. And what's the alternative? Zero process? Everybody has to "wing it" all the time? I can't see any possibility for a perverse environment there!
- btilly 14y ago
  Who defines what "explanatory" means? And what is the resolution if there is a disagreement? I, personally, am happy with a commit message like, Refactoring needed before #12345 can happen. I've said what I was doing, and why, and presumably in your ticket system there is a ticket 12345 that has more detailed explanation. Other programmers will disagree. "Explanatory" means different things to different people, and complex arguments can erupt. (Conversely if your commit essay lacks a concise first line to show up in blame, is that explanatory? Should you always have a ticket #?) Furthermore there is a type of person who enjoys asserting power through language lawyering. That kind of person will see that policy as a golden opportunity to acquire influence, even though the cost may be unnecessary conflict to little point. If such a person manages to assert control of a process element like that, you can easily get a type of teamicide that drives away good developers who don't want to deal with the BS of figuring out whether their essay was good enough to avoid an email lecture. As for the alternative, I thought I was clear on that. Large groups cannot work without process, small groups can mostly get by on common sense. The imperfections of processes do not change their necessity in many cases. But if you, personally, do not enjoy dealing with process, then you should find opportunities to work in more congenial small groups.

artsrc 14y ago

You can question whether the perverse incentive will be exploited. For example lets say the rule is that "C# code must be compiled before it is run." The incentives are to declare code compiled when it is not, to declare that you are not running code when you are, and to declare code to not be written in C#.

btilly 14y ago
The additional perverse incentive is to extend the rule by banning all languages that do not have an equivalent compilation step. Which means that scripting languages are not available.
- SoftwareMaven 14y ago
  You can extend anything to an absurd degree. That does not make it a strong argument.
  - btilly 14y ago
    What makes you think that extension is absurd? I based that on a real example!