How to Build Fast Part 3: Engineers
October 21, 2020
This article provides guidance to help engineers “build fast”, specifically focusing on building an initial product to launch to users.
It’s all about trade-offs
Building fast requires having a laser-sharp focus on user impact. That means knowing where to invest time, and more importantly, where not to invest time.
Engineers make a ton of decisions—the code architecture, the technologies to use, whether it’s time to refactor, and many more. In order to make the decisions that best enable user impact, engineers need to understand the context of the project and communicate their perspective back to the team. Engineers should proactively discuss implementation trade-offs with their team:
- Which elements produce impact and which are nice to have?
- What are the timelines for different implementation options?
- Where is the quality bar? Are we aiming to be pixel-perfect? Cover all edge cases? (Note this answer likely changes depending on the feature and the stage of the project.)
Be accountable for timelines
Specifically when building fast, extra days spent on tickets can add up to delaying a launch by weeks, which is a significant cost before getting feedback from the market.
Alert the team if the roadmap is unrealistic
Be proactive and honest so that the proper discussions can happen, rather than hoping for the best, working unsustainable hours, and/or dropping the quality.
Flag when a ticket is taking longer than expected
Discuss with the team if spending additional time on the ticket is worthwhile, and if so, what will be adjusted or cut accordingly.
There are a lot of unknowns when building a new product. In order to move forward, some decisions need to be made without knowing all the details. Take some time to investigate, document the limitations and unknowns, discuss the options with the team, and come to a decision.
Ensure a shared understanding of what a task covers and doesn’t
If a ticket is open-ended and vague, it invites scope creep. Clarify the minimum requirements and keep an eye on overall priorities—ask yourself: is spending more time on the current ticket more important than starting the next?
Quick to write, easy to change
When writing code, think about how to make it quick to write and easy to change. Start with the simplest implementation, and plan for adaptability by ensuring the code is readable, well-named, and has good separation of concerns. Write appropriate tests so the team can make changes with confidence that they’re not breaking something else. Also, take advantage of source control—revert changes if needed and ruthlessly remove unused code since it remains in the history.
Address privacy, security, compliance upfront and throughout the process
Concerns raised from a security audit before launch can significantly delay the launch. Worse, if issues are not caught before launch, they can risk user data, cause the company to lose public trust, and even be grounds for legal action. At the beginning of a project, flag areas of concern and discuss them with a knowledgeable advisor. Repeat this process throughout the project as new concerns arise, and ensure there is time in the schedule to resolve any issues.
Take advantage of trusted libraries
Using trusted libraries can save a lot of time and help the team move quickly. Of course, investing in a library that isn’t a good fit can be costly, so take some time to research a library to understand if it really addresses the team’s needs or if it’ll cause more headaches than it resolves. Generally, if the functionality is core to the product and will change frequently, it makes sense to build it from scratch. If the functionality is unlikely to change after it’s built, such as authentication and analytics, an established library is a good choice.
Decide error handling defaults early
When starting a project, it’s easy to skip over error handling and just focus on the happy path. However, it’s a hassle to retroactively find all the unhandled errors and address them. Instead, agree early as a team how to handle errors and create common code, like a default error dialog and logging, and common documentation, like the error codes for each endpoint.
Align the eng team on the code review process
Code reviews can take up a surprising amount of time for both reviewers and authors, so it’s important to make that time investment worthwhile. Discuss as a team the expectations around formatting the change description, how long a code review should take, when approval should be given or withheld, and what aspects to actually review (i.e. is the code simple? Easy to adapt?). Code design and architecture should be discussed as early as possible to avoid wasting time in the wrong direction. Complex features can even be worked on by a pair of engineers to share deeper context and speed up the review and delivery. Although it may seem quicker to approve a change without discussing concerns, well-designed code will lead to higher sustained velocity.
To repeat, developing software requires making trade-offs based on the project and its objectives. An engineer building fast may make very different decisions from one project to the next. While the actual decisions may vary, this article highlights common areas for engineers to consider and discuss with the team.
Keep an eye out for the final installment of the Build Fast series for a Designer’s perspective.
Warning: Undefined array key "modal" in /home/customer/www/thoughtworks.dayshiftdigital.com/public_html/wp-content/themes/connected-2021/template-parts/newsletter-modal.php on line 2
Thu Dec 1
Global Day of Coderetreat Toronto 2022
Earlier this month, we hosted Global Day of Coderetreat (GDCR) at our Toronto office. After a three-year hiatus, we wanted to re-awaken some of the community enthusiasm when we hosted the event for the first time back in 2019. This year we planned for a larger event which turned out to be a really good thing as we nearly doubled our attendance. And in case you were wodering, this is how we did it.
Tue Nov 29
Art of Controlled Burn in Engineering Management
The idea of a Controlled Burn is simple; create a small fire that you fully control. The assumption is that were you to do nothing, a much larger disaster would occur. In agile, no team likes disruptions; rather, everyone prefers to work like well-oiled machines. This begs the question - can we apply a strategy that looks very similar to firefighters and utilizes controlled disruptions rather than waiting for a full-blown disaster to occur?