I think Documentation-Driven Design works really well for Libraries and APIs as your documentation is part of your product.
In other situations, TDD & BDD can be a better approach as they have a big impact on the design of the interfaces and objects as Anthony mentions. Documentation should not necessarily come first in these scenarios.
As the title mentions though: Documentation-Driven Design for APIs. Maybe it should state publicAPIs?
Great article though Frances! Looking through the Glow source code is always a pleasure: easy to navigate and easy to figure out what’s going, which is not necessarily true for other well-known libraries. A tribute to DDD. Let’s hope it catches on :-).
Gilles Ruppert
I think Documentation-Driven Design works really well for Libraries and APIs as your documentation is part of your product.
In other situations, TDD & BDD can be a better approach as they have a big impact on the design of the interfaces and objects as Anthony mentions. Documentation should not necessarily come first in these scenarios.
As the title mentions though: Documentation-Driven Design for APIs. Maybe it should state public APIs?
Great article though Frances! Looking through the Glow source code is always a pleasure: easy to navigate and easy to figure out what’s going, which is not necessarily true for other well-known libraries. A tribute to DDD. Let’s hope it catches on :-).