2

Having Code Review and Pull Requests (for both application and automation code) is great... but in some cases I am seeing a lot of rubber-stamping approvals leading to low quality code. These share the following characteristics:

  • No changes
  • No comments
  • Approved in a few minutes
  • Code improvements were missed

When I personally submit or review code in pull requests - I expect comments about it to form several conversations. I've experienced this in other shops I work on. In some cases it took days or weeks to get the code approved. In a couple of rare cases I've even experienced it be longer than a month, but that was an outlier. I trust in the power of the group to create better shared code.
However I see that many developers that I work with do not instinctively use that approach.
How can I encourage a culture of quality for code reviews?

How can encourage quality code reviews that may take time given that developers are working in 2 weeks sprints and feel that:

  • They don't have the time to do this
  • It would make this miss their current deadlines
  • They would not be able to get as much work done during the sprint
  • Management expects them to continue delivering at the same pace seen previously
3
  • Excellent question in my view..! Commented Jul 8, 2018 at 11:53
  • Despite I like this question as it is well-formed and raises an important problem, I am not sure it fits our community in the best way. I mean this probably better fits SO since it is not enough of skilled developers here, hence you will not get the full variety of authoritative opinions and the value of the question might not be so great as it could potentially be.
    – Alexey R.
    Commented Jul 9, 2018 at 17:55
  • That 's a great point @AlexeyR. i feel it belongs on both in some ways. quality isn't an abstract concept in software engineering and it means to me that a site named Software Quality Assurance should talk about it. However for sure, most of our audience - or at least the audience we'd like to have... are on SO. Commented Jul 9, 2018 at 23:40

2 Answers 2

1

Does the code reviewer with coder go through the motion of going over code together and ask questions(from a checklist) in a fix time slot along with the group of 2-3 developers(not from the same team,i.e. objective spectators)?

I find it invaluable to create a shared sense of quality mindset in the team. If the team is geographically distributed, it can be done on video conference calls.

The advantages I see:

  • It is fixed time boxed.
  • It is done by a agreed upon standard checklist , so all know the expectations.
  • As the immediate/other teams participate, everybody gets to know the expectations over and over again with each code review.
  • Though one is an active reviewer, other can raise comments too(if required).

Also, implement pair programming. It is great concept for improving the code quality in the first place.

4
  • This really sounds like mob review, and if you're going to that effort, why wouldn't you just mob program to start?
    – ernie
    Commented Jul 8, 2018 at 21:29
  • I also mentioned pair programming which is an idea to start writing the quality code, to begin with. Commented Jul 9, 2018 at 1:40
  • It is different than mob review as it does not require the whole team but few representatives from within the team and few from outside to give the objective view. Commented Jul 9, 2018 at 1:42
  • Also once it is becomes a process with same checklist , it becomes more & more faster to close it as all people involve know the clear expectations. Commented Jul 9, 2018 at 1:43
0

Lead by example, make them believe that going slower on the short term will make them go faster on the long term. Find a companion and start a movement.

They would not be able to get as much work done during the sprint

They rather slow down with crappy code and defects in the next sprint?

Most teams I worked with had Peer Code Review in their own chosen Definition of Done. If they do not add this step due to reasons you give, what I would do is remind them every time when issues arise. Could we have prevented this with a code review?

Maybe code reviews are not the answer. I think it mainly helps with sharing knowledge, not better code perse, nor finding defects. If you truly want to fight for better code, inspire developers to read or watch Clean Code. Human readable, focused on adaptation and refactoring using a test-first approaches.

Maybe swarming helps to increase quality and shipping more stories in row.

It would make this miss their current deadlines

Meeting deadlines is not their primary job, but building a software solution that can be adapt to changing markets is, making sure they do not get into an halting grind. Did the team set the deadline? I always love how we think taking shortcuts to make deadlines is a good idea. Unless your going to die after you hit this imaginary line and or unless another company is stealing your market fast, maybe the team should seriously push back and say the deadline is not realistic and we cannot commit.

Management expects them to continue delivering at the same pace seen previously

Going fast in the short term is never a strategy to go fast in the long term. This is the productivity gap, making a mess now means you slow down, the teams pace will only become slower, adding more people will make you go slower. Building adaptable clean code is the only thing that will keep your pace steady over time.

That's what happens to projects they start out fast, but then after a few weeks they slow way way down. Because there is a mess building in the code ... Management made promises based on the speed of the first few weeks ... but the scare productivity gaps keeps growing, the harder they work the slower they go.

enter image description here

Watch: https://cleancoders.com/episode/clean-code-episode-1/show (topic starts at 17 mins)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.