What are the risks associated with adopting Better Architecture Driven Development (BADD) in a software project?

Adopting Better Architecture Driven Development (BADD) can lead to increased project costs and delays if not managed carefully. The main risks include lack of stakeholder buy-in and the potential for incomplete implementations.

Understanding BADD and Its Challenges

Better Architecture Driven Development, or BADD, is a strategy where the focus is on refactoring a system to improve its architecture before adding new features. This approach can streamline future development, but it comes with significant risks. One of the primary challenges is ensuring that stakeholders understand and support the initial investment without seeing immediate feature delivery. As Scott noted, "A risk of bad is the four most expensive words in the human language," referring to the tendency to expand scope unnecessarily during such projects ▶ 0:00.

Brad and Scott discussed how BADD could lead to a situation where the team gets stuck in a cycle of continuous refactoring without ever delivering new capabilities. Scott shared an anecdote about a previous project where the team attempted to modernize a system before building new features, only to be questioned by executives: "They just said, well, why are you doing it that way? Why aren't you going to modernize it first and then build it?" ▶ 4:51.

Stakeholder Buy-In and Communication

One of the critical risks of BADD is the potential lack of stakeholder buy-in. Business leaders often want to see tangible results quickly, and the upfront focus on architecture can seem like a delay in delivering business value. Scott highlighted the importance of aligning with stakeholders, stating, "I've been saying we can't get started until we write the requirements. And they've been like, well, why?" ▶ 19:57.

Brad and Scott emphasized the need for clear communication and setting realistic expectations with stakeholders. Without this alignment, there's a risk that the project could be halted midway if the perceived benefits aren't immediately apparent. Scott shared instances where projects were cut short, leaving teams with incomplete systems that were more challenging to maintain than before.

The Risk of Incomplete Implementations

Another significant risk associated with BADD is the potential for incomplete implementations. As Brad and Scott discussed, projects might start with the best intentions but can falter if not carefully managed. Scott recounted a scenario where a team attempted to upgrade a front-end framework but only completed two-thirds of the work, resulting in a more complex system with both old and new frameworks coexisting ▶ 27:08.

This risk is compounded by the fact that BADD requires a disciplined approach to ensure that the architectural improvements are fully realized. Without a clear plan and commitment to see the project through, teams might end up with a system that is neither here nor there, leading to frustration and wasted resources.

Balancing BADD with Feature Development

Brad and Scott explored the idea of balancing BADD with feature-driven development (FAD) to mitigate risks. They suggested an incremental approach where architectural improvements are made alongside feature development. This hybrid strategy, which they humorously dubbed "HAD," allows teams to make progress on both fronts without getting stuck in endless refactoring cycles.

Brad shared his thoughts on this approach: "You stack rank the stuff that's going to make the biggest difference to the developers' productivity and velocity, right? Like that's what this is all about" ▶ 27:50. By prioritizing improvements that have the most significant impact on development efficiency, teams can ensure that they are making meaningful progress while still delivering new features.

Conclusion

Adopting BADD in a software project comes with inherent risks, primarily related to stakeholder buy-in and the potential for incomplete implementations. However, by maintaining clear communication, setting realistic expectations, and adopting a balanced approach that incorporates both architectural improvements and feature development, teams can mitigate these risks. As Brad and Scott concluded, the key is to remain flexible and open-minded, continuously evaluating whether the chosen strategy aligns with the project's goals and stakeholder expectations.