We've reached the point where a chunk of work is ready to build. Before we dive in it's important to understand our view on tech debt and quality.
To most, tech debt is limited to the result of prioritizing speedy delivery over perfect code. To us it's anything engineering related that affects the team's ability to deliver customer value.
Our definition of tech debt shapes how we deal with it. We have a more broad view of tech debt than most. We also have a specific approach to fixing tech debt.
If tech debt exists in the code we are actively developing, it will be fixed as part of development. Thus, at Joyous, fixing tech debt actually becomes part of feature development.
There are many cases that we don't consider tech debt in this context. Here are two examples. The first is legacy code that meets near and medium term scale expectations. The second is code that follows old patterns. Particularly if there are no extensions on the near term roadmap for that part of the code.
Although, if it's near code that we are about to extend, then it may be tech debt. Why? Because it could pollute future patterns and standards.
The examples below help clarify what tech debt means to us.
We have a few conditions that we aim to meet for new features:
Much like a bank loan, there may be times when taking on some debt makes sense at the time. That's okay as long as you are comfortable with the cost.
We share ownership of quality across product and engineering. We don't have a team of QA analysts, instead we have just one. A senior analyst who helps champion quality across our entire team.
Different stakeholders incline towards some types of quality more than others. But we all view quality as a team effort, and we care about building a high quality product. We are happy to do anything to support each other in achieving this result.
The various types of quality that we focus on:
Once a crew begins work on a chunk, they will start to have a daily stand up. The product person, quality person also attend. And our stand ups are open to anyone. It is common for our Head of Engineering to attend all stand ups.
When we begin, the crew starts with the tickets labelled 'investigate'. As investigations complete the crew and product person will get together again. They will decide how to proceed given the constraints, and what a good solution looks like. This is often done as part of stand-ups.
The product person or crew will then create a series of new tickets to reflect the decision.
The front of the GitHub board includes two columns for Slices. The first column is a holding area for slices that have not started. When the first ticket for a slice is picked up, then the related slice ticket will be shifted to Slices in progress.
First part of the GitHub board
Figure 26 - The other build columns on our boards
There are seven stages that tickets will pass through during build time. Each is represented as a column on our project board in GitHub.
which tickets to start as they free up.
An engineer will conduct thorough manual tests and write coded tests before shifting the ticket to the next stage. In some cases it might make more sense to test later, in which case they create new tickets for those activities.
Of course end to end testing still needs to occur. Particularly for a large project such as V3.0. Here we use a combination of manual testing as well as automated front end testing using Cypress.
For entire chunks we invite our whole organisation to take part. One of our product folks and our QA analyst will work together to co-ordinate a series of tests.
We then use a channel on Slack in which everyone can report issues or concerns. Everyone can comment on issues here. Our QA analyst will reproduce and log valid issues as new tickets. We will add a label matching the type of issue, to help with future learnings.
Benefits of involving everyone in testing include:
At any point in the build stages we can and do revive previous stages. While there has been a lot of thinking up to this point nothing is final.
"When the rubber meets the road and we hit a pot hole we drive to the conditions."
If we see a potential improvement we will investigate it. We may change the design, or the pre-discussed solution. We agree the change between the relevant product and engineering folks. Then we feed the result back into build.