the "to don't" list

As part of a research project I’m currently involved in, we are developing a simulation of a particular theory of genetic regulation.  We are building the simulation in an “agile-ish” manner, in that we are producing a minimal functionality “version 0”, and are then going to add further biological-relevant functionality incrementally once v0 is released.

Being as agile as possible, we are adhering to the YAGNI (you ain’t gonna need it) principle, and implementing strictly the bare minimum needed.  However, this being research, we keep talking about, and getting excited about, all the potential later versions.  In order not to get confused about what goes in v0, and to document the good ideas for later versions, we've instituted a to don’t list.  This is a place to record these ideas that are not going into v0, but which we may, or indeed may not, use later.

We are developing our simulator using the CoSMoS approach, which enjoins us to list the assumptions we are making, as material for the argument that the simulator is “fit for purpose”.  The (negation of) the to don’t list forms a very nice source for assumptions we might not have thought of otherwise.  If the to don’t list has an item “do X”, it means v0 hasn’t done X, and so there is the assumption that X is not necessary for v0 (and potentially, for every other version, if we never decide to implement it).

So, in research meetings around the whiteboard, as well as saying “YAGNI” when someone comes up with an idea, we now say “that’s one for the to don’t list”.