7 ms·

Focusing on poor metrics such as “issues closed” or “commits per day” I once worked at a company that used an offshore company to work on certain modules of a

by joeax 10y ago

Focusing on poor metrics such as “issues closed” or “commits per day” I once worked at a company that used an offshore company to work on certain modules of a large project. They would commit code that my team would have to then code review. We'd see things like large IF-ELSE blocks with minor differences among the conditions (sometimes just one char). I know everyone hates this. Turns out their internal metric was lines of code per day, so they'd bloat the shit out of everything.

Clubber 10y ago
There's an old quote I read and I keep it with me. It was for CEOs and it says, "You get what you incentivize." The hardest part of managing a group of people is incentivizing exactly what you want, yet so many people don't spend an ounce of thought tuning that properly. There's other people who believe process will fix everything, yet don't bother tuning their process. Many companies have fallen because the CEOs incentivize net without incintivizing quality, i.e. gut the company, get your bonus and get out.
- devoply 10y ago
  Code should be reviewed, preferably by a different group of people who wrote the code, metrics are only useful for people to manage themselves. Upon review there should be immediate feedback to people who wrote it and if they continue to make the same errors, then you should eventually get rid of the person who wrote it. Making up stupid systems of control to "incentivize" people as a method of management is the stupidest thing rationalists ever cooked up. It destroys internal motivation and discipline.
  - Clubber 10y ago
    >is the stupidest thing rationalists ever cooked up. Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have much value that I've found, unless your team is fairly junior. Senior guys know what good code looks like, even in a crunch. If you hold forced, unsolicited code reviews with senior developers, you are really just throwing away money and aggravating people. It's just another half thought out process. A better incentive, in my opinion is: if you release a complete codebase with 0 medium and above defects by X date, you get a free week off, or something of significant value. A free, company branded desk clock doesn't cut it. (that's happened to me before). If a company is trying to save money by hiring the cheapest offshore developers they can, they are still really just throwing away money and aggravating people. lol. That is a perfect example of a poor incentive: cut costs without any regard to the resulting cuts in quality. Anyone can make a turd cheaply, but that's rarely what businesses really want.
    - devoply 10y ago
      A reviewer soon understands that senior devs are producing good code and stops investing time on reviewing their code. If they are doing their job properly. But again it comes down to internal motivation and self management on their part.
      - Clubber 10y ago
        Yes, sorry I should have been more explicit. Initial reviews have value (is this guy full of beans or does he know what he's doing), but constant reviews of senior developer code do not. If you've hired anyone you have to constantly do reviews for, you've probably hired the wrong person. I mean they should get what you are looking for after a month or two.
        LnxPrgr3 10y ago
        I know exactly zero developers senior enough to have gotten over writing bugs. I know I've written bugs that happened to pass all my tests only to blow up in somebody else's face, sometimes after surviving years of production use. Code review would've at least had a chance to catch them early—so long as you treat it as critical analysis of program logic and not just a screen for generic goodness. IMO if your code reviews are glorified manual style checking, you're doing it wrong.
        Clubber 10y ago
        >I know exactly zero developers senior enough to have gotten over writing bugs. No one was arguing that. Code reviews aren't for bug discovery, though that can sometimes happen. It's a very inefficient way to discover bugs. Developers should test their code for bugs before completing the task and submitting to QA. QA is a more thorough than development bug / unit testing and includes integration. Betas (if applicable) are the final source of pre-release bug discovery. Spending a bunch of time on code reviews to find bugs. IMO code reviews should do two things: 1. Make sure the developer knows how to develop and is not being sloppy and not following whatever standards are set (comments, etc). They are essentially training wheels for new developers to the organization and junior developers. 2. Make sure the code represents what the developer thinks it does (sanity check).
  - joeax 10y ago
    That's what I had to do. My manager told me of this metric (set by the higher ups in a contract with the offshore company) along with "there's nothing we can do." I essentially became the code repository sheriff. Eventually I was spending too much of my time refactoring their code and not enough on my own. Then deadline creep set in for me and I had to just let it go.
  - watwut 10y ago
    How do you check up on that reviewer? In you system, he has power to fire people, decide all standards+code style+architecture by himself and force that upon everyone else. All that with no accountability nor responsibility.
  - watwut 10y ago
    How do you check up on that reviewer? In you system, he has power to fire people, decide all standards+code style+architecture by himself and force that upon everyone else. All that with no accountability nor responsibility.
- pmarreck 10y ago
  Basically the same idea as http://www.duperrin.com/english/2014/06/23/quote-tell-how-you-measure-and-i-will-tell-you-how-i-will-behave/ http://www.duperrin.com/english/2014/06/23/quote-tell-how-yo...
- retreatguru 10y ago
  At our company we focus on intrinsic rewards rather than extrinsic rewards. We want people to feel good about the work they do, giving them the space and time to write quality code. We don't track any metrics such as commits or loc, heck we don't even track hours worked. We are much more interested in everyone, especially coders, focusing on what value their work brings to the end users. And how that syncs with the company's vision. During code reviews one of my favourite things to see is deleted code!
  - laurieg 10y ago
    You don't track hours worked? Do you have more or less fixed working hours? Otherwise how do you stop people staying a long time to impress the boss?

by joeax 10y ago

Clubber 10y ago

There's an old quote I read and I keep it with me. It was for CEOs and it says, "You get what you incentivize." The hardest part of managing a group of people is incentivizing exactly what you want, yet so many people don't spend an ounce of thought tuning that properly. There's other people who believe process will fix everything, yet don't bother tuning their process. Many companies have fallen because the CEOs incentivize net without incintivizing quality, i.e. gut the company, get your bonus and get out.

devoply 10y ago
Code should be reviewed, preferably by a different group of people who wrote the code, metrics are only useful for people to manage themselves. Upon review there should be immediate feedback to people who wrote it and if they continue to make the same errors, then you should eventually get rid of the person who wrote it. Making up stupid systems of control to "incentivize" people as a method of management is the stupidest thing rationalists ever cooked up. It destroys internal motivation and discipline.
- Clubber 10y ago
  >is the stupidest thing rationalists ever cooked up. Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have much value that I've found, unless your team is fairly junior. Senior guys know what good code looks like, even in a crunch. If you hold forced, unsolicited code reviews with senior developers, you are really just throwing away money and aggravating people. It's just another half thought out process. A better incentive, in my opinion is: if you release a complete codebase with 0 medium and above defects by X date, you get a free week off, or something of significant value. A free, company branded desk clock doesn't cut it. (that's happened to me before). If a company is trying to save money by hiring the cheapest offshore developers they can, they are still really just throwing away money and aggravating people. lol. That is a perfect example of a poor incentive: cut costs without any regard to the resulting cuts in quality. Anyone can make a turd cheaply, but that's rarely what businesses really want.
  - devoply 10y ago
    A reviewer soon understands that senior devs are producing good code and stops investing time on reviewing their code. If they are doing their job properly. But again it comes down to internal motivation and self management on their part.
    - Clubber 10y ago
      Yes, sorry I should have been more explicit. Initial reviews have value (is this guy full of beans or does he know what he's doing), but constant reviews of senior developer code do not. If you've hired anyone you have to constantly do reviews for, you've probably hired the wrong person. I mean they should get what you are looking for after a month or two.
      - LnxPrgr3 10y ago
        I know exactly zero developers senior enough to have gotten over writing bugs. I know I've written bugs that happened to pass all my tests only to blow up in somebody else's face, sometimes after surviving years of production use. Code review would've at least had a chance to catch them early—so long as you treat it as critical analysis of program logic and not just a screen for generic goodness. IMO if your code reviews are glorified manual style checking, you're doing it wrong.
        Clubber 10y ago
        >I know exactly zero developers senior enough to have gotten over writing bugs. No one was arguing that. Code reviews aren't for bug discovery, though that can sometimes happen. It's a very inefficient way to discover bugs. Developers should test their code for bugs before completing the task and submitting to QA. QA is a more thorough than development bug / unit testing and includes integration. Betas (if applicable) are the final source of pre-release bug discovery. Spending a bunch of time on code reviews to find bugs. IMO code reviews should do two things: 1. Make sure the developer knows how to develop and is not being sloppy and not following whatever standards are set (comments, etc). They are essentially training wheels for new developers to the organization and junior developers. 2. Make sure the code represents what the developer thinks it does (sanity check).
- joeax 10y ago
  That's what I had to do. My manager told me of this metric (set by the higher ups in a contract with the offshore company) along with "there's nothing we can do." I essentially became the code repository sheriff. Eventually I was spending too much of my time refactoring their code and not enough on my own. Then deadline creep set in for me and I had to just let it go.
- watwut 10y ago
  How do you check up on that reviewer? In you system, he has power to fire people, decide all standards+code style+architecture by himself and force that upon everyone else. All that with no accountability nor responsibility.
- watwut 10y ago
  How do you check up on that reviewer? In you system, he has power to fire people, decide all standards+code style+architecture by himself and force that upon everyone else. All that with no accountability nor responsibility.
pmarreck 10y ago
Basically the same idea as http://www.duperrin.com/english/2014/06/23/quote-tell-how-you-measure-and-i-will-tell-you-how-i-will-behave/ http://www.duperrin.com/english/2014/06/23/quote-tell-how-yo...
retreatguru 10y ago
At our company we focus on intrinsic rewards rather than extrinsic rewards. We want people to feel good about the work they do, giving them the space and time to write quality code. We don't track any metrics such as commits or loc, heck we don't even track hours worked. We are much more interested in everyone, especially coders, focusing on what value their work brings to the end users. And how that syncs with the company's vision. During code reviews one of my favourite things to see is deleted code!
- laurieg 10y ago
  You don't track hours worked? Do you have more or less fixed working hours? Otherwise how do you stop people staying a long time to impress the boss?