A Modern Approach To Remote Software Development
What are the most common causes of failure for software development projects?
When we started researching various software development failures 6 years ago, we saw a common pattern. From the FAA’s AAS program in the 1980s to modern startups in the 2010s, the primary threats to business continuity are:
Technical failures/delays due to the lack of an adequate process for the review of requirements, architecture, and proposed code.
Key technical milestones could only be accomplished by a few team members because the technical documentation system did not facilitate efficient knowledge transfer to the entire team.
These threats have a significant negative impact on the maintainability, reliability, and performance of developed software. As well, they increase employee burnout and lead to delays in project timelines. Failure to counter these threats during the initial development of a software solution often dooms the software to failure for the rest of its service life. And in some cases, the company that makes the software.
How well has BRAVE performed?
We started testing that system 5 years ago with an all-remote cross-functional team from 11 countries. That team brought to market and maintained two SaaS platforms and three IoT products. The primary benefits were:
Team members requested fewer knowledge transfer meetings. Instead, they made use of written documentation.
Employees were able to maintain a better work/life balance
Key personnel moving on to a new opportunity had a greatly reduced impact on business continuity.
Shorter time between hiring new employees and their first production code commits going to live.
Team members were able to rapidly and efficiently switch between applying their skills to the maintenance of existing software projects and the creation of new software projects.
Minimum time to no meeting time was required when handing over tasks between developers.
Team members were able to quickly transition to working on maintenance and features for software projects they were not familiar with.
How does BRAVE work?
BRAVE procedures ensure that every software development task contributes to business continuity by utilizing meticulous engineering validation and a detailed documentation system designed to facilitate long-term maintainability.
Blueprint: An experienced engineer updates the software's detailed blueprint documents with the changes needed. If required, they create experimental code to verify assumptions.
Review: A second experienced engineer validates that the proposed changes in the blueprint document will accomplish the goal of the task, not create unacceptable business risk, and ensure the changes can be understood by another engineer.
Assemble: An engineer performs the needed software changes using the blueprint as a guide, which enables them to code in a flow state. For code that requires more skill to implement, an experienced engineer will write the code.
Verify: Secondary testing is performed by QA for end-user-facing changes or an experienced engineer for infrastructure changes.
Enact: An experienced engineer verifies that the blueprint documents match the actual state of the tested code, and then coordinates with dev-ops to deploy the changes, so they can benefit customers.
How can your team implement the BRAVE methodology?
We provide a consulting service where we provide workshops, 1-on-1 mentoring, and process improvement analysis. With everything we teach, we also provide actionable written documents like this for your team to reference. If you are starting a team, we can teach them good practices from the start and be available to mentor them in a long-term relationship. For those with an established team, we can help analyze the current processes and suggest improvements.
If you would like to learn more, please contact us at Info@SofSafe.cloud.