Starting the development process from scratch might bring certain challenges for both client and dev team or a freelancer. This article is a little hint to product owners without the tech background. Furthermore, it will be focusing on what aspects need to be addressed in your product development path.
What do you Need to Know Before Hiring Devs?
Hiring a weak dev team or a freelancer might be fatal for your product. Eventually, non-qualified devs may undermine the idea of your product not to mention the quality. Let’s point out crucial factors:
Cost of services.
Surely, a client will not intentionally hire a weak team. However, the opportunity to save some money will be a predominant element in the decision making process. Therefore, the product owner might tend to choose not that expensive dev team which at the same time have lower rates and only with a few cases in their portfolio. As the saying goes: “Buy cheap, buy twice”, keep that in mind while choosing the devs that you will cooperate with.
The level of expertise.
First of all, you need to pay attention to the portfolio - which is the great indicator of devs’ reliability and professionalism. Take a look at the product that had been developed before. Examine its functionality and design. If it is possible to test the product (for example, by installing the app) - do it. You need to understand the level of skills of the dev team or a freelancer, which in this case will be shown by the great usability, functionality and user-friendly interface.
Ask for contracts.
In addition, you can ask the team or a freelancer to share the contacts of their previous clients. Therefore, you may ask directly about feedbacks and have a hint of the scope of tasks, deadlines and work ethic.
Conduct an interview.
Conducting an interview with the potential candidates is always a good way to check their proficiency in the product development process. You may ask: “If I am hiring tech devs without the understanding of the tech development, then how will I check on the candidates during the interview?” Don’t you worry, asking the questions about the strategies and prospects of business and product development will be enough. Devs need to be interested in the idea and strive to do their best for successful scalability and development of the product.
Development from scratch.
Keep in mind, that you need to choose the right tech team or a freelancer from the very beginning. Especially if you plan to develop a new product from scratch. In the case of uncertainty of the level of expertise and consequent change of devs in the middle of the development process will lead to launch delay as well as poor quality of the product.
Read our article Top 5 Startup Challenges and How to Deal With Them
Following the simple rules above, you will consequently hire a professional dev team. In that case, you will be sure that the development of your product is in good hands. Above all, you will know that the process from the very start to an end will be implemented by one team of developers. So you will be spared from the necessity to hire another dev team in order to finish the code writing process or what is more important to hire a team to do the code review.
For example, in our team’s practice, there were several cases when clients ask us to finish the project that has been already started. According to our approach, first of all, we ask the access to the code base. In order to finish the coding process, we need to review already existed code in order to have a full picture of the situation. Other cases are when a client deliberately asks the team to review the code pointing out of the mistakes of the product’s functionality and scalability. However, the practice shows that in both cases the code base includes a wide range of errors that consequently affected the smooth product experience.
So, you are about to launch your new product ...
You spent a lot of time planning and developing your idea, so currently being at the final stage of development or aftermath launching the product you expect to have a great feedback as a reward of your hard work. However, you may face certain difficulties, like adding a new feature to your product takes ages or functionality does not correspond to the initial idea, etc. Even though, without the tech background you, as a product owner, should pay attention to the code base of your app. Due to the fact, such issues must be an outcome of the errors and mistakes in the product’s source code. As a solution you need to ask your devs or hire a team from the outside in order to do a code review of the product and identify what exactly causes product’s errors.
So, what is the code review exactly? Why does it matter so much? Let’s figure out this together.
Code Review: The Reality of Successful Product Development
So, what is the code review exactly? You can imagine that the work of developers might not always be flawless due to the mental efforts and focus on coding practice daily. Thus, in order to eliminate possible mistakes, the code review is usually done. Precisely, the code review is a practice of spotting any mistakes in the code.
Code reviews will bring effective benefits that are working to assure the quality of work of the dev team, such as:
Code quality is more efficient and readable;
Well-documented software with adequate comments in the code and without defects;
The software which corresponds with enterprise coding standards;
Consistent end-user documentation;
Complete unit tests and scalability of the product;
Developers are able to teach and share knowledge based on code review practice;
To make a better estimation.
The dev team which is following a code review approach has all chances to build a successful product. Such a way of dealing with code base allow having a complete vision of the product development process.
Based on our practice with reviewing codes, our conclusion is quite disappointing due to the fact the code review shows multiple errors which crucially affect the ongoing project. Our approach is to write down, fix and explain to the client what mistakes we have found and how it will potentially influence the development process of the product.
The architecture and the code base of the product are equivalent to the building’s foundation. It needs to be strong and reliable from the very beginning to guarantee sustainable development with a long-term perspective. If the code review identified serious bugs in the code, the refactoring may take loads of time.
In particular cases, the process of refactoring might be even worthless to do. Keep in mind, that adding new features to the MVP version of the product, which were not mentioned in the initial tech specification is a great risk. Due to the fact, new features that were added in the middle of the dev process would make a dev team rewrite the entire code base. That might be explained that adding a new feature may overlap the existing ones or/and refactoring of a specific feature might affect the rest of them. The sort of chain reaction will not benefit the development process.
Case Study: Code Review Approach in Practice
There was a case when the client was developing a huge healthcare marketplace. His initial purpose was to add two more web pages to his project’s website, and no more. But it was just from the first sight.
Our approach is based on the full-stages understanding of new partner (client) so taking on board the new project which is already developed we always ask for access to code base so we can check the code itself. In this exact case that was a really good decision. As due to code review for his project, which he also ask for, we found our code base want to give us a chance to add new pages without breaking some existing flow of the app. And moreover, we want to be able to provide a rough estimation for this “easy” job. The code review was focusing on both the backend and frontend which responded for scalability and functionality of the whole product.
There were several crucial errors that were detected by a client, for example:
The main project code was filled with one commit, therefore there was no history of changes, which might be a tricky situation when adding new developers to the project;
The poor commits' naming was not responding to the changes made;
There was no Readme file and the dependencies in the project were absent;
There were no environments on the server (usually, you need to have at least 2 environments: dev and prod); meant all accesses were in one file;
Security of access to third-party services was violated. Consequently, storing such accesses under Git could be fraught with data leakage;
The API documentation was absent, too. So, the development and maintenance of the code was difficult to do;
The quality of code was negatively affected by the old version of code writings.
In addition, the Google Speed verification showed awful results. The web pages were optimized to 0 points from 100 possible, which meant that the web pages were not optimized at all, and the request of additional 2 pages development trying to promote the service, in fact wouldn’t provide the expected results. Consequently, the client was dissatisfied with such a result and could clearly see the reason behind why a web site failed at Google ranking.
In fact, we always use a complex approach in order to know the client’s requirements and what is more important to get to know his “pain points”. Such a model allows us to find the most perfect solutions to tackle specific challenges.
Regarding the mentioned case, our team followed code review best practices that is why a numerous weak points was identified:
The architecture of the app wasn’t meet Angular style guide requirements. Thus, the app wasn’t divided into modules, while Angular components were oversized. The codebase was not scalable.
The incorrect usage of RxJS streams concept was the reason for the potential memory leaks (due to an absence of stream’s unsubscriptions may significantly affect the app performance).
All data in the application was handled by components with local storage as a result of poor state management in the app. At the same time, local storage itself isn’t intended to store the app state. Therefore, there might be issues with security and performance.
The app size in production mode could and should be reduced, as example lazy-loading wasn’t implemented. Also fixing google audit issues could affect the performance improvement fairly good, especially in the case of mobile devices.
Basically, around 90% (yes, you heard it right) of unit tests just fails.
As you can see, to do a code review is essential if you want to launch a reliable product. The client may ask you do the code review as it was described above. However, we suggest you do your own code review every time you had a project. Subsequently, it will eliminate possible errors, the model will be standardized and it will be easier to modify the product or fix the bugs.
Our Solutions after the Code Review
In continuation of our case study with the code review, we would like to share our approach in solving mentioned problems.
In order to improve performance issues, there were added two additional libraries that were not used before (jQuery and angular2-moment). In addition, lazy loading was used for better performance. To be more precise, the user won’t load all libs on the app bootstrapping but would load it “on demand” on the necessary page. It helped to decrease the initial size of the app. Taking into account that storing application data might weaken performance and security, it was used javascript libs designed for that like NGXS, NGRX. They use REDUX pattern which allows flexible and convenient data management.
Architectural issues were eliminated by means of creating an own module for each page (previously there was no division to modules). There were no shared and core modules what makes the code harder to read and less scalable. As per Angular best practices, it was better to declare components, directives, and pipes in a shared module and to put singleton services whose instance will be shared throughout the application in the core module.
The dev team decided to use CSS to simplify and decrease the code size. In addition, the DRY (Don’t Repeat Yourself) principle and a lot of ts-lint errors were fixed throughout the project. The project contains a lot of commented-out code without description or TODO. This is allowed at the development stage but should be removed in completed components.
In fact, the coding style was not met with the Angular and Typescript style. RxJS issues were observed in the lack of stream’s unsubscriptions throughout the project, therefore, the subscriptions were accumulating in memory. That directly led to additional resources consumption and floating bugs. Another bad solution that was made by a client was using subscribe in subscribe, as there are many options in RxJS how to avoid that. i.e switchMap operator. That was considered a typical mistake when applying reactive programming pattern (that is actually RxJS) that results in uncontrolled floating bugs and excessive memory leaks.
Conclusion
While hiring the dev team or a freelancer for your new product development, you decide on your future project's success or a failure. Hiring the right dev team from the very beginning will spare you from the obligation to ask for a code review from the outside.
You need to choose skilled dev from the very beginning because changing developers in the middle of the product development is a great risk. Therefore, the rules to hire a professional developers are quite simple: do not follow the saying “buy cheap, buy twice”; check out portfolio of the future candidates and test the products that were developed by them earlier; pay attention to the interview process; ask for contacts from the previous clients, so you can ask about the scope of tasks and work ethic of the devs.
In our personal experience, we have different cases when a client asks us to finish the code that has been already started or deliberately asks the team to review the code pointing out of the mistakes of the product’s functionality and scalability. In both cases, the practice shows that the code base includes a wide range of errors that consequently affected the smooth product experience. According to our approach, we always ask the access to the code base in order to do a review, whether to finish the coding process or following the client’s task to check the code base. The code review allows having a full picture of the situation, not to mention it spot the possible errors that are the code.
Moreover, we suggest that health cooperation between a client and a dev team or a freelancer is suggesting to have a code review from the developers and detailed specifications from the clients. Those components are a basis of the effective and professional approach to product development.
In case you have left any questions or you have any suggestions, feel free to contact us and we will help you with any inquiry!
