FDD is many things but you can distill it down to these two things.
1. It says you take the time to establish a clear target to hit first. This is the essence of the startup processes. The modeling process is an informational/analytical activity to give enough understanding so that a project baseline can be set; a baseline with good coverage and good accuracy. The PM view of that is being able to answer questions such as "how far along are you" and "how far is there left to go." The developer view of that is the understanding and context for construction; see see point 2 next.
2. It says you take the time to establish what done or finished means. This is the essence of the framework or setup for the construction phase; for continuous incremental delivery of client valued features. The features list and how it is used is key. There is being able to enumerate what "x" is. That is, to enumerate the features for the work to be done so there is visibility of the construction for all project roles (meaning this visibility is just as valuable to the developers doing the work as it is to the PM or stakeholders wanting to track the work). And then to define what done or "finished" means. That is, feature x is finished. For example,
- feature x meets the syntactic coding standards
- feature x meets the semantic coding standards (e.g. our approach to memory management, or our approach to ordered collections, and so on)
- feature x meets the internationalization standards (assuming I18N is a requirement)
- feature x passes design and code inspection
- feature x passes all unit tests (which means the unit tests are constructed for it as well)
- and so on
- oh and by the way, that feature x also performs the necessary function
This is the incrementalism. Working code is the best measure of progress. Working code in FDD means when a feature is finished, it should not need to be touched again unless there is a defect. This last point is fundamental and understated in most FDD writings. At each step, for each incremental delivery, you actually have something not just pieces of things. If the feature "calculate the total of a sale" is done it is finished according to all the criteria established for finished (such as those listed above). It really is done and won't need to be touched again. That's what's in the build and that's how the continuous incremental delivery in an FDD project works.
You don't have bits of function delivered but that still need refactoring for standards conformance, or for architecture conformance, or for I18N, etc. You have a client valued function - a feature - that doesn't need any more work; that is "finished."
