Our company develops a safety-critical software product and we hit on the idea of splitting development up into three distinct teams:
a specification team,
a coding team, and
a testing team that tests the code against the spec.
The teams are adversarial – they try to catch each other out – but also collaborative – once an attack is found they collaborate to refine spec, code, and tests.
This idea can’t be original, but I’m struggling to find concrete and specific references (especially bibliographic references) for this style of development. I would welcome the wisdom of the teeming masses. Thank you.
Some of this probably stems all the way back to Adam Smith and the division of labour (specialisation of tasks relates to cerebral as well as physical work).
But regarding your development framework - most modern project management and process/software development methodologies owe a great debt to the Deming Cycle
No references, totally anecdotal. When I was a programmer in the 90s, our company simply learned through experience that our customers found bugs that the coders never ran into, and that the reason was that the coders knew the proper inputs to enter. Similarly, the coders knew the proper logical sequence of steps, so they never experienced the results that occur when a novice does the steps in the sequence that THEY think is logical. So we had a team whose function was to try out the software, knowing as little as possible about how it is supposed to work.
In my local buzzword-parlance those three are Business Analysis, Dev Team, QA. That’s a pretty standard way of splitting up responsibilities.
In a small company BA & Dev might be rolled up together. But having a QA team is crucial. I’d be kinda suspicious of a coding shop these days that didn’t have a QA team.