Timeline for How do I measure employee (software developer) performance based on bugs created?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 13, 2018 at 10:25 | history | edited | Lunivore | CC BY-SA 4.0 |
Updated link to Esther's article
|
| Jun 10, 2014 at 23:26 | comment | added | Lunivore | Don't measure individuals at all, unless you want hero-like behaviour which disrupts the ability of the team to deliver. Instead, pay them enough money to take the issue of money off the table (Dan Pink, Drive), and use things like 360 feedback solely to help them improve. | |
| Jun 9, 2014 at 8:34 | comment | added | Krunal | Hi, then how the performance should be measured? What metrics should be included in KPI? | |
| Apr 1, 2012 at 10:11 | vote | accept | meetpd | ||
| Mar 30, 2012 at 10:41 | comment | added | Lunivore | @Rup Why would you throw an exception in a debug build? It's going to throw a null at some point anyway, right? I'm happy just to leave it, work out what went wrong when it does (and write some unit tests so that my team-mates can work out how to use the code I wrote correctly!) | |
| Mar 30, 2012 at 9:58 | comment | added | Rup | Sure e.g. for unexpected nulls I'd assert or throw an exception in a debug build so it can be caught and fixed. I'd just make sure the release build didn't crash if it got an unexpected null at runtime. | |
| Mar 30, 2012 at 9:30 | comment | added | Lunivore | @Rup If your team doesn't have control over the code then that's a fair way to play, but see Eric Evans' "Domain Driven Design", ch. 14 onwards, for different ways depending on trust, downstream / upstream, etc. If you have control over the code then either it can meaningfully be null (so it's expected) or you fix the bug as a team. Don't add code to cope with mistakes (failing gracefully notwithstanding), just fix the mistakes. | |
| Mar 30, 2012 at 8:28 | comment | added | Anthony | @Rup Failing gracefully is always in my top 3 goals, so we're eye to eye on that. But bugs will happen, and if affects your paycheck, you're going to be more focused on failure-is-not-an-option instead of failing gracefully. | |
| Mar 30, 2012 at 8:23 | comment | added | Rup | @Anthony OK, maybe everyone else means something different by "defensive coding" - to me it's not "don't do it cleverly just-in-case" but rather assume that you'll get unexpected nulls and cope with them, that all function and API calls can fail and you need to check all results, and that you should never just crash in front of a user but fail gracefully giving them a chance to recover their work instead. | |
| Mar 30, 2012 at 4:50 | comment | added | Anthony | @Rup: I think another way to think of defensive coding is "shy coding" or "cowardly coding". I've spent countless hours making sure that I didn't write something too fancy and modern, for fear that it would break in IE or an off-browser. This didn't lead to clever backward-compatible solutions, but instead time lost writing less-modern and less-powerful code for fear a CEO might still be on IE6. The converse is the "git-er-dun" approach where developers write something they know will work but isn't integrated or scalable, it just meets the baseline scope. | |
| Mar 29, 2012 at 16:21 | comment | added | Shannon Severance | I would add the following to the predictions: Increased strife between testers and developers, including but not limited to: Increased argumentation over whether it is actually a bug. Developers claiming that multiple bugs reports are duplicates when they are not. | |
| Mar 29, 2012 at 15:32 | history | edited | Lunivore | CC BY-SA 3.0 |
Typo'd Esther's name, whoops!
|
| Mar 29, 2012 at 15:13 | comment | added | Lunivore | @Rup It's more code that developers have to read through in order to understand what the code is doing - and code that will never normally be used in production. All it does is say, "Oh, there's a bug, and it isn't in my code so it must be in yours." It's a habit from blame cultures, and collaborative teams with collective code ownership don't need it. Treat every piece of code you write as a liability. Less is better. | |
| Mar 29, 2012 at 14:55 | comment | added | Rup | "defensive programming, which will increase the maintenance costs" - defensive programming is when you check all the return codes, check everything for null, etc. isn't it? How will that increase maintenance costs? OK it might mean you need to write more test cases for coverage but that's a one-off cost up-front. | |
| Mar 29, 2012 at 13:20 | comment | added | Lorenzo Dematté | And I am surprised nobody cited Dilbert yet... dilbert.com/strips/comic/1995-11-13 | |
| Mar 29, 2012 at 13:17 | comment | added | Lorenzo Dematté | I second everything. I would like to add that developers are smart people; more than that, they LOVE to outsmart the others (the system, a computer, etc..). The best devs are challenge driven. In a team where I worked the PM forced this kind of metric. Everyone was so interested in "beating the system" that work eventually become to a halt, with many working on a sw to predict how to maximize their score... | |
| Mar 29, 2012 at 11:03 | comment | added | Lunivore | What @marcin-niebudek said. Also, add common sense. I found one team whose bug count went up despite their efforts to fix them. It turned out the users had spotted they were fixing the bugs and started reporting more of them. | |
| Mar 29, 2012 at 10:06 | comment | added | Marcin Niebudek | +1 for @Lunivore answer and I would add one thing. The most interesting metric regarding bugs (IMHO) is the number of bugs that slipped into production. But... You should use it not to evaluate individuals but to spot problems in how the quality process works in your team. So think in which ways you can lower that number. You have lots of means: better tests, CI, training your devs, etc. Use it not to imply penalties but to improve. | |
| Mar 29, 2012 at 7:36 | history | answered | Lunivore | CC BY-SA 3.0 |