cLabs

> In debating up-front vs. emergent design, we need to consider where our design accountability is?

Unit testing can help tremendously with this.

The hard part with accountability is that there are so many paths through the code that need to be guarded against. “If I change class C to help with X, how many other paths (used by end-users) already have a stake in this class?” Where is this knowledge? If it's in a document (req, spec, javadoc, code comment, etc.), will we go read it? If it's in a document and we read it, will it be accurate and up-to-date? If it's there, we read it, we find one that's not up-to-date, how can we reverify all the other documentation to make sure we can trust it? Documentation is a poor accountability mechanism, or an expensive one.

Communication (pairing, ad hoc design meetings, etc.) are pretty good, because our collective memory is a pretty good store of this information, but it's limited and not always dependable. But it's pretty cheap, too, so do it.

If it's in a unit test, that was run within the last 24 hours, and either passed or was fixed if it failed, we know that at least what the unit test specifies is accurate and up-to-date. We can make the change with a new unit test, re-run the suite, and if all the unit tests agree, then we have a near guarantee that what we've done is safe.

Really, the question should be, “what are our design accountability mechanisms?” moreso than “when do we do them?”. The answer to when should be “as much as possible, all the time.” ... though the various mechanisms will have some influence over when.