Solutions reviews
What are solutions reviews? Why may you need one? Read this blog post to find out!
Recently I was listening to the podcast - DevTalk. In one of the episodes, guys were talking about the interesting concept - solution reviews. I started thinking - maybe it is a good idea?
As my mind was thinking about it I decided to give a lightning talk to my team about that specific topic. You can find this presentation here.
What are solution reviews and why they are needed?
Imagine that you get a new task to code. Everything works fine - you already know the answer. You code it without any problems. But then after a few weeks bugs from production started to come. As it turns out your solution wasn’t the best one.
How can this be avoided? By testing on staging environment - yes but it’s cost money and time. In code review phrase you may say - indeed but you already invested time in writing this code. Is there a better way?
What if you review your solution before even touching the code? So you know when it comes to writing that you chose the best solution? This is the moment where solution review comes handy.
How does it work? Developer before writing any code thinks about a solution - how to a fix bug, how to code user story. Then (hopefully) he/she comes with a solution or even a few solutions. Teammate takes these solutions and reviews them - I don’t need to be a full day review. If everything seems fine - then off you go and code! If not - propose a better solution.
It can be both beneficial for a novice in project or programming or a senior developer. In the first case, more experienced member of a team will look into this. In the second case - many senior developers think that they knew all of the systems that they work in. But second pair eyes can open new possibilities of regressions or performance degradation.
How solution reviews can be implemented
After discussion with my colleagues from work, I found out that solution reviews could take many forms.
You can start with estimating stories during planning. I always thought that estimating is for a business to know how many points we deliver each sprint. But there is another aspect - agreeing on the estimate. Some developer thinks that story is 3 points but another gives 5. There comes discussion and mental model of the solution starts to emerge.
You can write a few sentences on ticket comment field and CC another developer to give you a review. You can do the same in person or in a group of persons.
Lastly, you can make a pull request that describes solution and gives it to review. It comes really handy with new GitHub interface that allows you to request changes etc.
That’s all for today! What are your opinions on solution reviews? Do you use them or maybe not - please write in comments.