LDUF is the process of modeling a small subsystem before coding, and BDUF is also a process of modeling, but in BDUF, the whole system needs to be modeled before implementation. BDUF can also be an anti-pattern for many reasons, but LDUF (or many occurrences of LDUF within a project) is often helpful.
BDUF occurs in one of two categories:
- A document of the high-level architecture, which determines the key features of architecture, but the rest of the things are unspecified and/or unclear.
- General documentation should describe everything from high-level architecture to the smallest detail of the system. These documents are often incoherent as there are no automatic ways to cross-check them.
LDUF can be precise and concise, and many programmers/architects can check/verify LDUF and detect any inconsistencies.
Generating and changing BDUF is often hard and expensive. It requires teams of analysts, consultants, and architects, and support from many layers of management. LDUF is light and informal—often, a programmer can do a mock-up, and if it's checked, it can be checked by a small team.
These are the main aspects of LDUF:
- Highly informal; it can be made by yourself or with a small team of programmers.
- Code is created in a small subsystem, which can be as small as even one class, function, or package.
- Often not prescriptive—the results are to be used as advice, not requirements.
BDUF is prescriptive—the code must be consistent with the paper project; all exceptions require management intervention. Additionally, it is anti-productive for many of the reasons mentioned in the preceding points.