Coding in Feature Driven Development

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.


, , , , , , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: