Document Driven Development – The History


Since the first software development projects, we have generated documents as artefacts – more often as a project deliverable than providing more than minimal effect on the project direction.

For waterfall projects (and the parts of agile projects that remain waterfall) the documents are the glue across the SDLC. They are still artefacts and rarely resemble the product. Without the engineering principle of a feedback loop, document artefacts become out of date and untrustworthy.

The agile manifesto says that working software is preferable over documentation. Listen to the programmers sigh with relief now that they can code and not write or check documentation. How do developers on an agile project know what to write? By documents and verbal transfer from earlier parts of the project – often following a waterfall model. We have architects writing the spec document from finished and partly finished code and testers discovering what the system really does for both testing and documentation.

Documentation has been the most hated part of any project. Everyone hates to produce it, hates to read it and avoids trying to keep it up to date.

Documents as artefacts are not document driven development.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s