Understanding Sofware Engineers and their quality of work.
To the Developers
Defining an effective code review can be subjective so we've decided to separate the cerebral model from actual implementation. The biggest challenge for most is to remain silent and take the feedback no matter how harsh it may be. The first instinct is to defend the solution but instead one needs to empathize with reviewers perspective in order to glean valuable lessons. This is how we learn. It's not easy for Engineers to have an external stakeholder come in and rip apart their code base and critique their choices. Listening is the key to Empathy.
To Company Technical Stakeholders
The biggest mistake companies make when addressing code quality is that many have a subjective predisposition to the term QUALITY thus creating more chaos when code breaks after it is released onto production; difficult to measure and often viewed subjectively.
It is critical to understand how challenging it is to measure each of the following criteria. There are no simple variables to view and measurement can be costly often requiring complex infrastructure. Speed and power can be easily measured whereas security is complex and difficult to estimate.
Areas to consider when measuring Internal (Code characteristics concerns for the developer only)and External (Extending from using the Software - UI side) Code quality
Breaking down the criteria
- Features
- Speed
- Space
- Network usage
- Stability
- Robustness
- Ease-of-use
- Repeatability
- Back-Compatibility
- Security
- Power Consumption
- Testability
- Portability
- Thread-safeness
- Compactness (Code redundancies - broken code)
- Maintainability
- Documentation
- Legibility
- Scalability
No matter how diverse, broad or niche your Technical Stack is, having solid code standard practice software developers across your teams can adhere to is a good starting point in order to start measuring quality output. Just make sure you know what is being measured. :)