5 ms·
I feel that the situation proposed in the article is a completely false dichotomy. It's a myth that a good team sits in a meeting room for 4 days and codes a p
by furyg3 13y ago
I feel that the situation proposed in the article is a completely false dichotomy. It's a myth that a good team sits in a meeting room for 4 days and codes a perfect product in one swoop on Friday. At the same time, paying someone in KLOCs is probably a guarantee that you'll have a bad time.
This is an issue I struggle with on a regular basis, as we outsource a lot of our development work. We work on a project basis, but work very closely with our partners to help them make good estimates, maximize capacity, and minimize their (and thus our) risk. I don't want people to work overtime, nor do I want them under-committing.
My experience is that watching someone's commits, even from far away, is actually a damn good indicator as to how capacity is being managed on a project. Every project is different, but coders code: if they're not committing frequently and regularly, it's time to check in.
Human beings normally don't have flat productivity, so activity spikes are normal. But low activity in a period means there is not enough work and/or there will be a large spike later, which for me means risk.
- chris_mahan 13y agoEven if what they commit does not solve the customer's problem? I'd rather have a coder spend 3 days thinking and 10 minutes coding with one commit than spend ten minutes thinking and three days coding with 300 commits. Coder productivity to me is "is the user of the software more effective in their job?"
- weixiyen 13y agowhat if they commit once every 3 days and it's super trivial.
- chris_mahan 13y agoWell, if their trivial change in 3 days makes the customers more effective in their job, then that's fine. Remember: the best code is no code.
- weixiyen 13y agowell I suppose that really depends. When there is little to no code and the feature remains incomplete, then it's pretty bad.
- furyg3 13y agoYes, the end goal and final judgement of success is to have your fix/change implemented in the best way for the price you are willing to pay for it... of course. I'm just saying that in my experience good work actually looks and feels like work, in terms of commits and deliverables. If it looks like nothing is happening, it probably isn't. Overtime as it was mentioned in the article, on the other hand, is a very untrustworthy indicator of quality work. Managers too easily think that it's a sign of aggressiveness, commitment, perfect capacity estimates (cost savings), etc. But it can just as easily be a sign of bad planning, resource issues, inept management, internal politics, etc. Managers have to answer the question: is my development team being used most effectively? They need some indicators. Looking at the commits and deliverables isn't perfect, but it's much better than looking at the number of hours someone is sitting in their chair, or ensuring they are adequately stressed out.
- dreamfactory 13y agoBear in mind that LOC is an ongoing cost not an asset.