1:21 pm on March 11th, 2015
Why Non-Techie Product Owners Should Do Code Reviews
Owning a Product
Whether your title is Founder, Product Manager, Product Development Manager or any other product or project position, if you think of yourself as responsible for a software product, then you should be doing code reviews at some level.
Many people may disagree with this statement - and I can understand some of the arguments, but in my experience, you don't know what is being done unless you look at the code. And even if you are not a programmer - there is a lot to be deciphered. This post will look at a few types of red flags even a business person can find by doing periodic reviews.
So let's step back for a moment... I am going to assume that the majority of people reading this post are startup founders who are hiring out the development of a product. You may have a development manager who works in your company or you may have outsourced your development to a group either on or off shore. Whatever the case may be - if you are the founder or the technical cofounder - some basics that you should know about and have in place are the following:
- Source Code Repositories must be in your control and in your companies name (I would recommend Github or Bitbucket)
- Assignment agreements must be included as part of any development contract - even if you are an open-source project (if contracts are local - make sure they use the term "work for hire")
- A good ticketing system should be in place for managing development and this should also be in your control and paid for by your company (A great tool for this is Jira.)
So if you have the basics covered, let's talk about process. If you are like most shops these days - you are likely approaching product development in an agile way - with sprints, regular demos and regular deployments. So how do code reviews fit in, and why are they important?
For a product owner here are a few things that a code review can tell you:
- What code libraries are being used and referenced?
- What APIs are being called?
- Are configurable settings being hard-coded into the system?
- How and where are messages (like errors, notifications, auto emails) being stored and can the business access them?
- How are your business rules being tested?
I'll stop with that list for now and walk through each with an example and how you might look for it. A code review by the product owner is not the same as a typical geek to geek code review. Sometimes you can do it by yourself (if you know the tools) and sometimes you'll want your project lead to walk you through it. Let's dive in...
So what code libraries are being used or referenced? This has significant business risk - so you'll want to be sure to ask this question and to look for new ones being added to the project. If you are using Github or Bitbucket for your source repository -you can set yourself up as an admin and you can actually see the changes as they are being updated to your code base. A lot of times you will know that a new library is setup because you'll see a new name introduced. For example, let's suppose your team decides to implement Kendo UI which is a popular .net toolbox. Assuming your team is outsourced, they may have all the licensing in place - but you will want to be certain... and you need to know that if you bring the development in-house at some point, you will need to pay for that library - and the pricing may be a surprise to you. By doing a code review - you can catch that sort of choice and at least make a conscious decision with you tech lead before going too far down the path. I make it a policy in all my contracts that inclusion of any new dev tool or library must be approved prior to using it. This example is a good one - the only implication really is cost. A very bad implication is if your developers included a library that has a license incompatible with your business model. If you are not familiar with software licensing start by looking at wikipedia.
Configuration variables hardcoded... this one is a bit harder for the non-techie manager to find. Typically you will want to chat about this on the front end and then have your dev lead show you the config file. A good example of this may be pricing for site registration, or perhaps it is the access level names - what if during planning you call your levels 1, 2 and 3 - but when you take it out to the public, you want it to be Gold, Silver and Bronze. Those sorts of things are best kept in a config file so that if you want to change them - you can easily - without it being a matter of changing it everywhere it shows up in your system. This is a matter of good architecture and it is not often found, so you have to be a stand for this sort of maintainability. In the long run, it will save you time and money.
Messaging is a big deal - and it's something that is often left out of initial requirements. These days you have a lot of options about how to implement it - there are SAAS services with APIs that you can use or if your needs are simple, you can build it yourself. Typically, however you will want to implement an SMPT API - and again you need to own that account and understand how you can access the reporting associated with those transactional messages. Other types of messages are on-screen notifications and errors. Similar to the configuration variables above - you want to make sure these are separated out from the code that runs them. That way a change to your message does not touch the business rules for when that message shows up. This just keeps it cleaner because on screen messaging is a huge part of selling and up-selling your product - so the more you can abstract the content out from the code, the more flexible and quick it will be to change it later.
This last issue is really the hardest - but could be the most important. If you don't know what unit tests are - you should look them up - because as a business product owner they are your friends. Not all developers do test-driven development, and I don't necessarily recommend it for all products or parts of products. That said - if you have ever had to create a matrix to explain how different users of your product should have different permissions for different functions within your product - then you should be asking to see the unit tests. Unit tests are ideal for defining and testing the business logic of your app. The more complex your business logic is, the more you need to define the different use cases for your developers. If you have a use case defined - then you can usually read the unit test code to make sure it is saying what you intended. Unit tests done right are readable by the lay user. You'll definitely want your dev lead to walk you through these - but it's easy and well worth it.
I hope this brief introduction to code reviews for non-techies has been helpful. I know that it is more technical than you may want to be - but if you really own a software product, then part of your job is to either become more techie or bring in a technical partner that you really trust to be looking out for your business.