2 ms·
The biggest problems is that no "law" or "rule of thumb" of software engineering is always right. So "debunking" by finding an exception isn't really useful.
by YZF 13y ago
The biggest problems is that no "law" or "rule of thumb" of software engineering is always right. So "debunking" by finding an exception isn't really useful. The best answer to most of these questions is: It Depends (tm). There are situations where the right person making the right calls makes a huge difference and there situations where anyone can make a call that would turn out reasonably OK. There are situations where buggy software has little impact on the business and there are situations where it can result in bankruptcy. This is partly why this is difficult to research in any sort of rigorous fashion and why we should definitely maintain some degree of scepticism to any broad claims.
x10. Anyone here do the TopCoder Algorithm SRMs? There's clear evidence of x10-ish performance difference between the "red" coders and the average coders in there. Does that always apply? No. In certain situations can certain developers blow the average away? Absolutely yes. This is true for things other than software development.
The author talks about "engineers of equal experience". No such thing. There are no two single developers with "equal" experience.
Bug fixes. It's a no-brainer to see the cost of fixing an issue by the same dev in reasonable proximity to when the code was written is a lot cheaper than someone else fixing that bug 6 months later. It's also a no-brainer to see that the cost of fixing a bug in nuclear reactor control software that can cause a core meltdown is cheaper before the core actually melts down. In between there is a lot of grey area but I think there's a lot that can be applied while still being safely in the no-brainer region, that is our intuition, that is our learning/pattern recognition over years of software development.
- SilasX 13y agoExactly: the test of a heuristic is its average case performance, not its worse case. If you select for finding a really bad case in "proving" it wrong, that's not very informative.