Simple code review.
Problem: The main problem here was a non-technical founder needing to judge the readiness of the code base of his product. We speak to a lot of people who are building products who are not IT professionals.
What they do: PictionUs is a private media platform. It was designed to help you keep all of your important memories in one place, without having to expose them to the world.
Solution: A simple code review. Non-technical Founders generally want a trusted third party to make some kind of judgement on their project. The purpose here is to ensure that no one is being exploited due to a lack of technical knowledge and inversely, those without technical knowledge are making reasonable demands.
Here we had a startup founder with a bold vision and a technical partner who was coding it up. These kinds of projects can have an element of trickiness because of the pride that developers have (rightly so) in their work. It can sometimes be seen as an attack on their work.
The Context and Challenge.
Seeing behind the interface.
Here we needed to be careful to frame up the situation that showed the benefits of a third party review. Ideally we were going to identify any deficiencies in the code that might be causing sub-optimal performance to offer positive direction.
Project background and description
The timeline was relatively loose in terms of demands so we set it at our end. Being a start up, there was an element of budget sensitivity so we presented a proposal that would produce the desired result without breaking the bank.
The overarching purpose of this job was to give the founder confidence in the unknown, the technical sufficiency of his product.
Not a developer.
The problem was simply that our business based customer was more on the business than the technical side, which makes an assessment of the code base almost impossible.
The product was coming up to launch and there was a strong desire to ensure that the product could handle significant traction.
Project goals and objectives
The goal here was to present any problem areas that required investigation and to indicate the overall quality of the code base.
Process and Insight.
Tell it in plain English
In this instance our technical team methodically worked through the code to ensure that it was written in such a way that seemed efficient.
So, not too many unnecessary actions or functions being triggered. We also ensured that the code was generally well factored and organised.
Additionally, we also load tested the software to ensure that the code base would hold up under stress, in order to carter to the concerns around ability to handle traction.
A simple, 2 page, plain english document was produced. This document was a simple summary of what we found, the state of the code and the areas that should be looked into.
We wanted this document to be as digestible as possible and not require any technical explanation.
Here it was almost all good news. The code looked to be built with a decent level of efficiency with a few minor areas of investigation.