11 ms·

Somewhat tangentially: I note that most managers seem to equate hours at the keyboard with productivity. I have heard of some employees being monitored via the

Somewhat tangentially: I note that most managers seem to equate hours at the keyboard with productivity. I have heard of some employees being monitored via the notebook's video camera. Is it so difficult to define deliverables and pay for completed and tested work? The business value of any given function point is the same whether it took 100 hours to develop or 10 hours. Of course, more productive programmers would benefit under such an arrangement. Oh wait ... the problem is that requirements specifications are never clear nor complete enough and there aren't any tests to confirm correctness of the implementation.

5e92cb50239222b 5y ago
> Is it so difficult to define deliverables and pay for completed and tested work It is? It's a problem as old as the hills — how do you measure the amount of work done? I can churn out several new features in very short time, but then spend two days chasing a bug which results in a single-line fix. From the management POV this looks like I've been very productive for a few hours and then spent two days doing fuck all.
- mschuster91 5y ago
  Ideally you'd have a competent team lead that can evaluate whether people are bored out or overloaded with tasks and if their output quality matches expectations. JIRA, Trello or other tools are (usually) not used for the team's benefit, but as "actionable items" or whatever for clueless upper management.
- drran 5y ago
  The manager then can look at data and think, "Hm, these bugs are costly. What we can use to reduce number of bugs to reduce costs?" Bugs are a waste. Number of bugs can be reduced with better practices: peer review, various tests; better software: linter, automatic verifier, compile time checkers (-Wall + -Werror, rust), code generators, libraries; or additional business process: quality assurance. To improve something, your manager need to measure it first. You can propose everyday reporting of spent time instead of spying tool, e.g. "2h working on #1234, 6h fixing bug #23456", which is much more valuable to your manager than raw data. In my previous company, we reduced the number of bugs and time to fix by an order of magnitude, because we were able to see the effect of changes in tooling and development process.
numpad0 5y ago
> The business value of any given function point is the same whether it took 100 hours to develop or 10 hours. That's the point of paying proportionate to hours and not value of your output. There's some delta! You can try the value of deliverables model but you'll have to be quite irreplaceable.

5e92cb50239222b 5y ago

> Is it so difficult to define deliverables and pay for completed and tested work It is? It's a problem as old as the hills — how do you measure the amount of work done? I can churn out several new features in very short time, but then spend two days chasing a bug which results in a single-line fix. From the management POV this looks like I've been very productive for a few hours and then spent two days doing fuck all.

mschuster91 5y ago
Ideally you'd have a competent team lead that can evaluate whether people are bored out or overloaded with tasks and if their output quality matches expectations. JIRA, Trello or other tools are (usually) not used for the team's benefit, but as "actionable items" or whatever for clueless upper management.
drran 5y ago
The manager then can look at data and think, "Hm, these bugs are costly. What we can use to reduce number of bugs to reduce costs?" Bugs are a waste. Number of bugs can be reduced with better practices: peer review, various tests; better software: linter, automatic verifier, compile time checkers (-Wall + -Werror, rust), code generators, libraries; or additional business process: quality assurance. To improve something, your manager need to measure it first. You can propose everyday reporting of spent time instead of spying tool, e.g. "2h working on #1234, 6h fixing bug #23456", which is much more valuable to your manager than raw data. In my previous company, we reduced the number of bugs and time to fix by an order of magnitude, because we were able to see the effect of changes in tooling and development process.

numpad0 5y ago

> The business value of any given function point is the same whether it took 100 hours to develop or 10 hours. That's the point of paying proportionate to hours and not value of your output. There's some delta! You can try the value of deliverables model but you'll have to be quite irreplaceable.