Why is BDD so compelling? - Cucumber Tutorial

- [Instructor] Why is it that many organizations are turning the behavior-driven development from managing their software development cycles? The emergence of BDD came about from the failures of the traditional model of software development. This new paradigm was necessary to overcome some of the pitfalls that development teams had encountered over and over again. While the benefits of BDD might sound interesting in theory, having an example of what can go wrong when we don't keep the goals and desires of a client in the foreground helps us to understand the consequences of development based on poor communication of requirements. As an example of how BDD changes our understanding of project management, let's take a look at how BDD changes our understanding of project management with a real world case study of what goes wrong without BDD. At the 2017 CukenFest conference, scrum master Sheetal Patel gave a keynote speech where she detailed the transformation that occurred within Vanguard Group. For some context, Vanguard Group is a large mutual fund with over five trillion dollars in assets. With an organization of approximately 14,000 employees, 2,000 of these are dedicated IT professionals. Vanguard Group is a purely virtual company with around 370,000 logins and 30 to 60,000 transactions per day. Their web infrastructure is critical to their business model and is managed by over 200 agile teams. A number of years ago, before their implementation of BDD, they were handed a project that dealt with critical brokerage transaction calculations. It was a large and complicated project, where someone had already done the estimate and committed them to a delivery. There was a lot of work to be done and not a lot of time to do it in. The development teams utilized agile principles for the creation and testing of their code. And by the time they were nearing the end of the development cycle, they had over 1,000 test cases. During final regression testing, the product owner decided that she would like to take a look at the product. She played with the system and informed their team that one of the brokerage calculations was not working properly. There was a trade type that was missing from the calculation. Making a change to the software at this point was an incredibly difficult task considering that the brokerage formula itself was so complicated, and that they had created a monolithic application where everything was tied together. When a change was introduced, there was a rippling effect that influenced everything else. However, they were informed by the product owner that the change was necessary and the application could not be utilized without it. They had no other choice but to implement the change in a time crunch riddled with anxiety, scrambling to test the changes they introduced. They did not have the time necessary to test everything thoroughly, but they did the best they could before they pushed it out to production. So what went wrong? At that moment, they realized there was something crucial missing in the equation of their development life cycle. Vanguard was making changes to their software they weren't confident in, resulting in stress and anxiety, and there were too many moving pieces to test everything efficiently. In order to transform the way that they tested and developed code, they had to understand the problem first.