10x Code Quality in 15 Minutes Or Less
Demo the changes before merging to develop a super power.
10x your code quality with this one simple trick:
It’s so easy I can’t believe I have to write about it.
It’s not the Holy Grail but the results are magical.
Background info: Getting software to Production uses repeatable process called the Software Development Life Cycle. It’s similar to this:
Step 1: Requirements
Write down the changes requested by the user.
Step 2: Development
The developer changes the application to meet the requirements.
Step 3: QA Testing. Find bugs, go to Step 2.
QA Testing verifies the requirements are met in the context of the application.
Step 4 UAT Testing. Find bugs, go to Step 2.
UAT (User Acceptance Testing) verifies requirements are met in the context of the user. Does the change solve the need or problem for the user?
Step 5: Production Push.
Deploy the application for the user to enjoy.
Developers use Requirements to build something that (they hope) solves a need for the user. Herein lies the first problem: writing fool proof requirements is hard and tedious. Perfect requirements don’t exist.
The developer is a developer, not a user. Developers commonly have a poor understanding of the business domain. Said another way, we don’t understand the problem our software solves for the user.
Developers are terrible users. They have a great understanding for how the application works. But, they’re terrible users. And they’re working from imperfect requirements.
Code reviews get all the attention. Yet, running the code is what matters. Running code is what users pay for.
Steps 1 and 2 are a blackhole for time and meetings.
-creating stories
-refining stories
-meetings with the users
-meetings with the product team
-code reviews with the dev team
Step 3 causes the most stress. Step 3 is where teams feel the most pain. It’s where managers lose their minds. Bless the QA team.
Teams waste staggering amounts of time reworking changes from bugs and missed requirements.
QA finds issues, bugs and missed requirements. Each time, the ticket is returned to the developer for additional work. The overhead quickly adds up and is a source of context switching for everyone. More meetings can happen.
Time wasted moving tickets between Development and Testing is lost revenue and extra expense. Ticket churn aka kickback must be the biggest enemy of the team. Kickback is a Key Performance Indicator (KPI) that your team should be measuring.
There’s a simple and easy way to reduce kickback. Reducing kickback means increasing code quality.
I call it “The Functional Review”.
Demo the changes before merging your pull request.
Take 10-15 minutes with your BA or QA to review the requirements and the application changes.
“This is how I understood the request. Here is what I made.”
Do this BEFORE merging the PR so the developer can address silly mistakes (like typo’s), update error messages, find edge cases or anything else that is discovered.
You will be amazed at the big and little things discovered while the developer still has the code on their machine and loaded in their mind.
Do this for the big changes. Do this for the little changes.
10x your code quality just by showing it to someone before the deployment.
Simple. And easy.