Floris Huetink

GitHub LinkedIn Twitter

Back to the feature

Step one in a code review: read the code. But what if I told you your review results might improve by prepending a “feature review” step?

Where I work, everybody requests and conducts code reviews. Lately, I noticed my review results differ from the results I get back from co-workers. Most prominently, in my reviews I seem to put:

This puzzled me: should my reviews focus less on end users and more on the code itself? My answer turned out to be “no”. The rest of this post explains why.

Naming things

Literature on code reviews (Wikipedia, 1, 2, 3) does not mention the end user perspective – actually running the application, and trying out the feature to see whether things work as intended.

So, what to call this other part then, a feature review maybe? This turns out to be a term not all too commonly associated with programming. There’s a StackExchange question mentioning it as an addition to code reviews, but no definitive answers there.

To be sure, we do have names for this type of feedback. Two terms pop into my mind:

QA and UA are mostly considered as steps taken after code reviews have been performed. While useful as extra safeguards, it’s not the same as including this perspective into the code review process itself.

In lack of a better name, we’ll stick to feature review for the rest of this post and define it as “reviewing a feature’s usefulness from an end user’s perspective”.

Example: user management

How do code reviews and feature reviews relate? This is perhaps best demonstrated with an example. (This example is a simplified version of a real situation encountered at work.)

Say we have an application with a feature request from a customer:

Administrator users should be able to create and activate new (non-admin) users

This feature has been built and is now ready for review. The current implementation is designed as follows:

Code review

Reviewing the programming code might reveal things like:

Feature review

Trying out the feature as an administrator might reveal issues such as:

Is it doing the job?

The code reviews suggests code improvements given the current design. The feature review, on the other hand, suggests design improvements given the requested feature. Put in another way:

For me, the well question should always be answered first: if the current version of the feature is not doing a good job, don’t even bother optimizing the code behind it. Chances are the current code has to be rewritten anyway.

This is also illustrated in the example. The feature review suggests separating creating a user from activating it. This enables administrators to resend activation mails. Adding this functionality should be considered before implementing the code review optimization of sending the e-mail in a background job.

Conclusion

While a code review may suggest it is about code only, such a limited perspective can lead to optimized code that does not work well for end users. Avoid this trap by first reviewing a feature from and end user perspective. Play around and check if everything feels right and works as expected. If so, go ahead and dive into the code for further inspection. If not, fix the feature first – and the code later.

October 10, 2015