Software Development Process At JTC

In this blog, I want to share how we approach software development. JTC is an engineering company where each product engineer takes complete ownership of the feature from development to deployment and monitoring and take great pride in building great software products.

Before we start the actual development, one of our engineer (usually tech lead) gets together with the project owner (usually the customer) to understand the problems that need to be solved and solution that needs to be built. Once those are finalized, the work is converted into user stories (we follow behavior driven development) and entered into JIRA. We then begin to start executing them.

STEP 1: Sprint Planning

We follow the agile methodology. It all starts with sprint planning. Team members get together on a particular day of a week (Monday in our case), talks about new user scenarios that need to be enabled as well bugs, if any, that needs to be addressed. The work is estimated in story points and planned (factoring any upcoming time offs) for the sprint. Our sprint is usually a week long. All the work is managed in JIRA.

STEP 2: Development and testing:

We use Gitflow branching model and Github for source control. For every task, bug, or story, we create a feature branch. Ex: Consider a story in JIRA: SEQP-10 — User should see an error message if they entered the wrong username or password.

git hf feature start SEQP-10/error_message_wrong_username_password

We use Hubflow (a set of helper scripts) that does all plumbing work to enforce Gitflow branching model. Once all the changes are made and automated tests are written, changes are committed.

STEP 3: Committing changes

Before a commit can be made locally, our bot ensures that changes follow coding standards and run all automated tests to ensure the changes do not break existing scenarios. In case it breaks, our system does not allow the commit.

At this stage, the engineer who made the change goes to Github and raise a pull request (PR). With each PR, they write a detailed description of the changes made, document manual test cases ran, automated tests cases added, and various devices the changes were tested. S/he then assigns relevant engineers to review the code. Our system automatically deploys just those changes to a new endpoint (for web-based projects). Each PR goes through a detailed code review. Here are a few things a reviewer looks for:

1. Reviewer tests the changes on the endpoint to make sure it does what it was supposed to do.

2. Proper comments have been added to the code.

3. Variables and functions are named correctly.

4. Proper validations and null checks are in place.

5. Relevant automated test cases have been added to cover the new code path.

6. Proper error logging is done to ensure we can debug the issue in production in case an issue occurs.

7. The code is architected correctly and follows SOLID design principles.

8. Think about all various scenarios these changes might affect.

9. Does user experience make sense? Is it responsive? Does it render well when user zoom in or zoom out?

10. Performance implications (time and memory)

Once the reviewer approves the changes, the PR is merged and the developer moves on to next tasks. Note that we do not have a separate QA team and our engineers own everything from building the feature to testing and monitoring.

STEP 4: Release

As soon the changes are merged, our system auto deploys them to a staging server. At the end of the sprint, the product owner (often our customer) verifies the changes. Once the changes are verified, we release them to production. We have set up monitors on our servers and if there are any errors, bug or crashes that happens, our team gets immediately notified on a Slack channel. Yes, we use Slack for our team communication.

The project team members do a daily standup to talks about the progress they have made yesterday, what they plan to work on today as well as any blocking issues. This makes sure that everyone is on the same page and any blocking issues are surfaced early on.

If you any suggestions, questions or comments about how we do things or ways we can improve, please leave a comment.