How Software Gets Built

The process & the team.

2019-03-19

In order to understand how high-quality apps are developed, we need to learn about who the players are and how they fit into the process of making an app.

The goal of this post is that you can understand this table depicting how the high-level phases of development map to the expertise required at each step.

img

In explaining the process of building the apps we will explain what each role entails, so you can get a full picture of what is going on behind the scenes.

Scoping

In this part of the process the product manager and the app architect work together to balance the following priorities:

  • Creating a great user experience
  • Making the best use of resources
  • Setting up a solid infrastructure

In more concrete terms we are deciding what is the highest quality experience we can give users given our timeline and budget constraints that also sets us up for technical success. Combining the consumer focus of the Product Manager, the technical focus of the App Architect, a definition of what goes into the build is reached. To learn more about what goest into the planning of a product check out our tips for before the build.

Visual Design

Taking the requirements from the previous step the Product Manager collaborates with the Designer to visually represent what will be created. The most important considerations in this step are:

  • Usability
  • Brand Consistency
  • Alignment

The result of this step is a visual representation of the user-facing parts of the app. Iteration is key in this step as we have the most flexibility to make changes and clarify the requirements and user experience. A few key products at this stage are the wireframes, style guides, mockups, and clickable prototypes. Each has different levels of fidelity and all work as building blocks and alignment tools. To learn more about what goest into the design of a product check out our design post.

Technical Spec or Architecture

With all the functionality clarified with the user in mind, the Product Manager and App Architect reconvene to get specific on the engineering tasks that have to achieve our common goals. A few considerations:

  • Engineering roles and respective experience levels needed
  • Costs of development vs integration
  • Appropriate tools and technologies for the given task
  • Security

A successful app architecture is one that allows engineers to understand step by step what is expected of them to turn an idea from concept to reality.

Build

With a clear roadmap, the engineers get to work. Each engineer will receive the applicable set of instructions to their expertise:

  • Backend — Encoding the business logic and data transfer mechanisms as well as connecting to the web frontend.
  • Mobile — Creating the visual aspects of the mobile app and connecting to the backend.
  • DevOps — Deploying the different components of the application, making sure that the system is highly available and fault tolerant.
  • Quality Assurance — Continuously test functionality and give feedback to the Product Manager.
  • Product Manager — Handling unexpected use cases and relaying feedback on the implementation to App Architect.
  • App Architect (aka. Engineering Lead/Manager) — Reviewing code to ensure high quality and scalability, modifying requirements in response to feedback, and integrating the different parts of the system.

This is a very collaborative and cyclical process. The goal of the prior steps is to handle unknowns before the coding begins. It goes something like this:

  • Engineers: Implement from Requirements & Test
  • Architect: Code Review & Give Feedback
  • Engineers: Fix
  • Engineer/DevOps: Deploy
  • QA: Test & Feedback
  • Product Manager/Architect: Feedback & Requirements
  • Rinse & Repeat

The cycle can take as little as a week or as much as a few months depending on the scope of the requirements. Depending on the stage of the project and the level of definition of the prior steps, a longer or shorter cadence makes sense.

Launch

There are different levels of deployment: development, staging, and production. A developer using their finished product in their web browser is likely in their development environment. At this stage, no one else can have access to the app. The next level of deployment is the staging server, where testing of the features can be done in an environment similar to production, but without taking the risk of giving users features that haven’t been fully tested. The QA team tests here. Finally, the production environment is where features go when they are ready to be given to users. If setup correctly this process should run relatively smoothly, with automated testing and continuous integration and deployment. The first time we are launching an app DevOps and QA have to make sure the system is set up correctly for this workflow.

Now, here’s that table from the beginning again:

img

Hopefully, it makes more sense who the players are and how they work together to bring apps to life.

Bonus: Data Analytics

This cycle continues until the app gains traction. Once the product has had a chance to gather information on its usage a Data Analyst can start making use of that data to inform development and business operations. Until then the Architect and Product Manager collaborate to gather smaller scale data to inform improvements.

Conclusion

The process of engineering applications follows a very particular cyclic structure, there can be variation in how phases are divided, how long the cycle is, how many people are needed for each role, and how integrated or separated the roles are. A single developer and a team of 20 alike will go through this process of defining requirements, developing, testing, and redefining requirements as outlined above until the app has met the needs of the users it’s being built for. The ideal configuration will vary depending on the goals of the team as well as the development stage, but for successful products, it is imperative that the configuration of roles, cadence, and phases is clear to everyone involved.



Interested in learning more?

Check out our post about product market fit and sign up to get more awesome content about building software products.