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 refactoring. The main argument against
refactoring 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.