Understanding Product Development Process

In my earlier blog Technical Terms Every Founder Needs To Know!, I shared about the technical terms that non-tech founders need to know as they start their journey. Extending the topic further, I am sharing here the technical understanding of the development process for the non-technical founder. This can also be considered as the things you need to plan on the day your development starts.

Understanding and setting these things will also set up the right process and environment for predictable development. Setting these things up or asking for them from your development team makes you a savvy founder, taking control of your project.

👉 Setting Up Project Environments

As the name suggests, the project environment is the space where your project executes. Once the developer has developed the particular code, he then would be putting it on a test environment where the code runs and the developer can check for bugs. Once the segregated module is tested, it is then tested for integration- connecting it with the rest of the software and APIs. Once that is done successfully, the code is then deployed to the main server (production server). This is where real users can now use the platform.

So in summary your product goes through the cycle of development, testing, integration and launch (production)!

There are different project environments required for each action so that each action can be separated from the other and as a team as well as a business owner one knows the progress as code moves from one stage to another.

Thus, keeping the above in mind, one needs to set up the following environments.

Development and Self-testing

This is where a developer writes the code and would usually be his own machine and may be some cloud space for testing. The developer can himself test use cases or the code can be passed to the QA person who would test on his machine.

It is important that testing is done by another person and not just the developer as the developer may just consider the scenarios which he has taken while building the code and not the boundary cases. A dedicated QA can go deeper in testing and can also check the code with different manual and automation tools.

Once the tester is satisfied, the code moves to integration testing.

Integration Testing

During Integration testing, the developer tests the product with different 3rd parties that the product may be using like Facebook, Google maps or any 3rd party SDKs. All such 3rd parties provide their own testing environment and test data to test.

Staging

After getting satisfactory results, the developer then sets the product on a staging server which is where the product gets tested with real data. Testing with real data is important to make sure that you have not ended up with just a common or best case scenario dataset. Setting up a proper staging environment is crucial for proper testing and hence success. The staging environment should be set on the same server as the production is so that any issue with your server is found and rectified too.

Production

This is where your live application runs and as you may have guessed, your code is finally deployed to the production server where it becomes part of your main application. A production deployment process set up in advance makes the process repeatable and predictable. The more, everything is tested in advance, the lesser headache for you at the launch.

👉 Setting Up Code Repository

A code repository is a place where your code resides. When a developer writes code, they would upload the code into the repository. It is also called Source control.

In contrast to saving code on their own drive or on a Google drive, a code repository provides many advantages such as

• Branching of code which means your code is divided into sections and changes can be done to one section at a time and merged with other branches once work is done easily.
• Version control which means in case of issue one can go back to the earlier version.
• Access control on who accesses what.
• Scalability to add multiple people or teams to the project.
• Integration with various project management and communication tools like Jira and Slack make you and your team effective.

Given these advantages, code repository is must for managing and storing code as your product develops. Popular Code repos are Github, Bitbucket and Gitlab.

One often asked question is the difference between GitHub and Git.

Git is the version control system that you use to manage code. GitHub is the platform on which you use Git.

Fig: Project view on Github

•  Control- System to record changes over a period of time so that you can fall back to any of the past systems in case of any issue faced.
• Commit- To put code into the Git. This has to be done explicitly. Code does not saves automatically
• Fork- Creating a new copy of Other words that would often be used related to Code repository are
  • Repo- The directory or storage space where your code lies
  • Version- The full repository
• Clone – Copying the repository on your own computer
• Branch- Copies of the program made to make changes. Unlike Fork, these copies are part of main program and would not have independent existence
• Pull Request- The act of merging a branch with another branch or the project file
• CodeCommit- Saving your code into the repository

Practices such as branching and Fork are used by developers to take a specific part of code and limit their new work to that only so that in case of any update going wrong does not impact the whole code. Imagine, if you were building a webpage without the ability to undo or redo facility. Anytime if you write something wrong, you have to start new- how difficult would it be?

Branching is the undo and redo for developers.

So a typical flow is that the user would create a new branch of the code. Add new code to it or make changes. If they like what gets built, they can add it to the original code. If they do not, they can just delete the branch and they still have original code intact.

Here is a snapshot of how a project looks like with its branches and files.

Fig: Project code Files Arranged into Different Branches and Files on Repository

Keeping the practice of branching code also allows the team to insert good practises like code review, code checks etc on these smaller daily activities. Like you can create a rule that there should be a code review before every pull request or the code should pass through certain tests, at every pull request. If there are any issues found, the developer can fix the issues and then redo the pull request procedure.

Additionally to make sure that code is regularly being worked on and changes are visible, code commit frequency can be set up in the team. Unless a code commit happens, the team can never know what is being worked upon. One of the early signs of project failure is the irregularity in code commits. When you do not even know if developers worked on the code or not, or the developer told that he/she is working but there is nothing to show for 2 weeks, understand you are already in trouble.