![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
This is a question for professional coders and managers of coders and anyone for whom the phrase "transitioning from waterfall to agile" is clear. You wanna point my friend your way? Feel free.
Background: five developers who have worked together for 10-25 years in a mainly waterfall environment, but where each essentially owned code and did all the adaptions and maintenance etc etc etc. Last code review was for stuff on the mainframe.
New project started in July where the team must conform to coding standards, more complex implementations and architecture, complicated project versioning and so on. We have a New Guy who is saavy to the modern stuff. Morale is mixed. Some folks are very frustrated because they're used to getting the requirements implemented and done (well! and working! and right!) but they're used to doing it their own way (and turn over is so low that the cost of this behavior has never been a management motivator to change it). Some are happy to be learning new (marketable) techniques.
Code review is a strongly encouraged part of the mandated standards.
I understand how code review is a Good Thing. "What's that?" "Oh, i'm decorating the method with the validation aspect so blah blah blah...." Folks can learn. There are so many automated tools that check the styles, review for possible bugs, evaluate whether there are enough unit tests that the code should be pretty scrubbed. this blog entry on code & complexity describes that after all that scrubbing "...the primary reason we formally review code is to subjectively comment on other possible ways to accomplish the same functionality, simplify its logic, or identify candidates for refactoring."
At this point, i don't know that we have a team that's ready to think about refactoring their code, partly because they are spending much of their time refactoring and adding onto inherited code. The goal for me as a manager is more that more folks gain confidence in the work they are doing. While a review is threatening (as i've ascertained by the revulsion some express) it may also help folks feel more confident about the work they're doing.
I'm trying to imagine the process of review in a way that is efficient (not having five folks and a manager and an analyst all go over the code together) and effective.
Right now i am thinking of having my egoless senior coder (he's confident, he takes criticism well) review his code with my most junior coder (so she can learn) and New Guy (because he's our expert).
Should i be there?
Should this be informal: i suggest to A to gather B&C together when his code is scrubbed right before he's ready to commit?
Can this be done with a webex? Because we have lots of working at home folks.
Should there just be a regularly scheduled code review block twice a week and they who are about to commit review each other's code together?
Do you have happy code review stories?
Background: five developers who have worked together for 10-25 years in a mainly waterfall environment, but where each essentially owned code and did all the adaptions and maintenance etc etc etc. Last code review was for stuff on the mainframe.
New project started in July where the team must conform to coding standards, more complex implementations and architecture, complicated project versioning and so on. We have a New Guy who is saavy to the modern stuff. Morale is mixed. Some folks are very frustrated because they're used to getting the requirements implemented and done (well! and working! and right!) but they're used to doing it their own way (and turn over is so low that the cost of this behavior has never been a management motivator to change it). Some are happy to be learning new (marketable) techniques.
Code review is a strongly encouraged part of the mandated standards.
I understand how code review is a Good Thing. "What's that?" "Oh, i'm decorating the method with the validation aspect so blah blah blah...." Folks can learn. There are so many automated tools that check the styles, review for possible bugs, evaluate whether there are enough unit tests that the code should be pretty scrubbed. this blog entry on code & complexity describes that after all that scrubbing "...the primary reason we formally review code is to subjectively comment on other possible ways to accomplish the same functionality, simplify its logic, or identify candidates for refactoring."
At this point, i don't know that we have a team that's ready to think about refactoring their code, partly because they are spending much of their time refactoring and adding onto inherited code. The goal for me as a manager is more that more folks gain confidence in the work they are doing. While a review is threatening (as i've ascertained by the revulsion some express) it may also help folks feel more confident about the work they're doing.
I'm trying to imagine the process of review in a way that is efficient (not having five folks and a manager and an analyst all go over the code together) and effective.
Right now i am thinking of having my egoless senior coder (he's confident, he takes criticism well) review his code with my most junior coder (so she can learn) and New Guy (because he's our expert).
Should i be there?
Should this be informal: i suggest to A to gather B&C together when his code is scrubbed right before he's ready to commit?
Can this be done with a webex? Because we have lots of working at home folks.
Should there just be a regularly scheduled code review block twice a week and they who are about to commit review each other's code together?
Do you have happy code review stories?
Tags: