BDUF (Big Design Up Front) has been decried by many agilists, including myself. With any project, trying to specify lots and lots of interlocking decisions is risky because as soon as one decisions has to be changed, all the other decisions that depend on it must be adjusted as well. Many folks I have spoken with have been involved with large projects where one or two month in, the initial specification was obsolete and almost useless.
In this post, I am attempting to address where architecture is defined on an agile project. I am going to create several broad categories for the purpose of mental digestion. This is not an exhaustive analysis. Rather, it is a thread of my experience. In this post, I’m not addressing class design or method design. I’m addressing broad software design (architecture) and where its place is on an agile project. Consider the following broad environments:
- Teams of 3-5 developers, shared analyst/customer
- Teams of 8-25 developers, dedicated analysts
- Teams larger than that
Before I break them down and address each individually, I have to divulge that I have never worked on a software project that could be considered “large”, i.e., over 200 people. For those projects, I’m sure there are plenty of patterns, but my experience is not in that space.
2-5 developers, shared analyst/customer
In this type of environment, you may have a dedicated architect, but it is likely that you don’t. The types of systems that this small of the team can build and maintain are limited; therefore, the architecture might be something the senior developers can tackle. There is a lot of wiggle room in this space given the context. If all of the developers are junior, then you need an architect who can make some high level design decisions so that you don’t end up with ad-hoc software. Most likely there is a senior member of the team who can perform architecture work during normal development cycles. It is likely that there is no pain created by doing just-in-time architecture
8-25 developers, dedicated analysts
As the projects get larger, the number of communication conduits between the developers increases to a point where communication is a burden. It becomes harder and harder to get all of them around a whiteboard and perform just-in-time architecture. In this environment, it often, not always, becomes necessary to define some level of architecture up front. When I use the term “up front”, I am referring to some time before a developer attempts to put the functionality in code form. With the way Headspring works, this is anywhere from 1 hour to 100 hours before a developer pair looks at what is needed to be done. The development team gets a head start on the iteration because instead of beginning by parsing requirements, they are given specifications which have been created recently in the context of the larger system. With the smaller team, the specifications happen on the fly, and they are often conversations or simple whiteboard drawings. In the slightly larger teams, the architecture has to be communication to more people, so architecture artifacts and diagrams are necessary. Software specifications start to become necessary.
Teams larger than that
I won’t speak to software projects with hundreds of developers on the same system because that is not where my experience lies. I will address, however, the forces I know are in play as the team grows larger and larger. The number of communication conduits increases exponentially. With 50 developers, you have so many paths of communication that you start to split the team up into sub teams. Architecture is so much more important because designing and communicating the architecture is so important to keeping the software consistent. Because the architecture needs to be communicated more broadly, it has to be defined earlier in the process. This is more architecture up front (ADUF).
Overall Idea
Every system has an architecture. The tool of the .Net platform, Visual Studio, provides a default architecture, which is 2-tier, single layered. If you don’t like that architecture, then you are on your own to adopt or define an alternative. If you are using an alternative, when does that get defined in an agile project, and how much is defined when?
Architecture happens. Smaller teams mix it in everywhere. Larger teams have a larger coordination overhead, so it has to be defined in a more structured environment. The “when” and the “how much” fluctuate with the situation, but architecture is always there.
In the reaction against BDUF, I have seen the full pendulum swing to the other extreme of NDUG (No Design Up Front). Many have witnesses this as well and have called for “just enough design up front”.
The lesson I am trying to share here is that when communication and coordination become a challenge, more architecture has to be defined in a structured manner before the larger body of programmers start whipping out code. When Agile principles are applied to a software development project, software is delivered in small, incremental pieces. With these repetitive cycles, the project is naturally broken up into a rhythm of delivery. With each cycle, the requirements need to flow into specifications that need to flow into working software. In small teams, that process can be fluid and ad-hoc, often verbal. As the number of developers increased, it creates the need for more structure around communicating architectural decisions. This communication need creates the need to do more architecture ahead of each iteration.
Practical Experience
A process I have seen work quite well when a project with 8-25 developers has a dedicated architect (or architecture team) that works ahead of a development iteration. They process the roadmap (requirements) and create specifications at a detailed-enough level that the development team can estimate the work. Then, the specifications are consumed by the development team. At the other end is software.