One of the biggest criticisms of agile development is the lack of big design up front (BDUF). This leads to inefficient implementations, poor performance, and ever-changing internal structures — or so the arguments go.
Agilists opposed to BDUF argue that spending too much time designing early in the development cycle is largely a waste of time. There are too many unknowns, too many variables and even a few invalid assumptions. You can’t come up with a good design when faced with all this uncertainty.
Some folks get very emotional in their arguments. That level of emotion usually results when you take someone’s statements and push them to the extreme.
For example, BDUF doesn’t have to mean not writing a single line of code until every aspect of the system design is specified and documented. Likewise, agile techniques don’t mean skipping design sessions entirely and jumping right into code development.
Those extremes would surely result in failed projects more often than not.
Good agile development teams spend a lot of time on design. They don’t do 80% of the design up front though each sprint has design time built into it. The idea is to start with a known, proven architecture such as model-view-controller and build on it as needed.
Some will argue that there are times when a completely new and different architecture has to be invented and BDUF is mandated. There will always be special situations. I’d argue that when something needs to be invented before you can begin implementation, you are doing research not development.
Research requires special techniques beyond the scope of software development. Once the research is complete, the software implementation can begin.
It’s time to stop being defensive. Instead, we need to focus all of our energies on improving the art and science of software engineering.