Posts Tagged ‘FDD
Coding process in FDD is not as exciting and challenging as it is in XP (eXtreme Programming). This happens because by the coding time the features have been extensively discussed during Process One, iteration kick-off meeting, design review meeting. Classes and methods are defined by now, their purpose is described in code documentation. Coding often becomes a mechanical process.
Unlike XP FDD strongly discourages re-factoring. The main argument against re-factoring here is that it takes time and does not bring any value to the customer. The quality of code is addressed during code review meetings.
FDD encourages strong code ownership. The main idea is that every developer knows the owned code and better realizes the consequence of changes. FDD fights the problem of leaving team members from the different angle:
- Sufficient code documentation simplifies understanding somebody else’s code.
- Developers know what other people’s code does, since they reviewed the design.
- Developers will look at each other’s code during code review.