Timeline for How to get developers to do code reviews in a timely manner
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 19, 2012 at 10:09 | comment | added | Murph | @SteveJessop of course you can truly agree that. And of course there are going to be exceptions (I happen to think the scrum observation is silly though - especially as the answer is obvious (-: ). I think the key is that there is no "one size fits all solution" I just proposed something that's simple and easy to understand and is relatively hard to bump of one's schedule (again depending on the environment) | |
| Dec 19, 2012 at 0:11 | comment | added | Steve Jessop | I say "let deadlines slip", I should have said "move deadlines". "slip" implies moving them after they're committed, i.e. failing, but it needn't be that way. You could instead plan for a period of slightly reduced productivity due to the inflexible new rule (and the inevitable inefficiencies caused by people trying to follow any new process -- if you're doing code review first thing then you'll miss the morning scrum meeting on days the code review takes too long, or whatever unique niggles your organization can throw into the mix). If it's a good rule you'll soon get above where you started. | |
| Dec 19, 2012 at 0:02 | comment | added | Steve Jessop | And the solution is tricky, but IME you have to find enough "space" to introduce a new working practice that is time-consuming but worthwhile. This requires foresight to identify slack time, a willingness to let deadlines slip as the price of introducing a worthwhile change, or both. TANSTAAFL. Like you say, once everyone is settled into the pattern they can make exceptions. Hopefully they do so based on a proper appreciation of the value of the general pattern. | |
| Dec 18, 2012 at 23:58 | comment | added | Steve Jessop | You can't truly agree that "first thing every day" rule in the first place. If someone finds a bug that costs the company X dollars per hour (or increases the risk of missing an important deadline by X percentage points per hour), and they happen to do so five minutes before you get in, then code review is not your top priority. Basically the problem is the clash between the desire to set simple rules, vs the fact that priorities are not always simple. The risk is that everyone will whole-heartedly agree the rule, and within 24 hours find some reason why today is an exception to the rule. | |
| Jul 26, 2012 at 9:16 | history | answered | Murph | CC BY-SA 3.0 |