Searching the specification for the btrfs file system i stumbled once more over the catchphrase: “The code is the documentation”. This implies that changing the code changes the specification.
Does this approach make sense while working on a file system that will be used from various drivers or applications?
I can understand that a smal group can split the job and everyone works on her own task. But how should this work with a larger group, spread over several places?
(btrfs spec would still be welcome)
5
I can understand that a small group can split the job and everyone works on her own task. But how should this work with a larger group, spread over several places?
Well if you think about it, it works the same way that all distributed development projects work. The developers uses tools (e.g. distributed version control) and procedures that are tried and tested for this kind of situation.
And the evidence is that this approach really does work … if done properly.
One thing that works in the favour of the “the code is the spec” approach for a file system, is that a Linux file system only requires a single master implementation. From the developers perspective, there is no need for multiple implementations of (say) BTRFS, and certainly no need for independent (e.g. clean-room) re-implementations. If you look at it from their point of view, there is no value to them in writing a spec, setting up a committee to manage changes to the spec, and constraining themselves to conforming to the spec.
jmoreno comments:
For something like a file system, I would expect a reference implementation and/or a test suite, which would be the documentation.
You could say that the master implementation is the reference implementation, and the master test suite is the reference test suite. The only issue is that the test suite will have been designed as a functionality test suite for the master (reference) implementation rather than as a compliance test suite for all possible implementations of a (hypothetical) spec.
7
I disagree: The tests are the documentation/specification. The code is the documentation of how it was implemented.
Tests are stable, long lived, publishable and legible by most (you don’t publish the test code, just what is being tested). The implementation is impermanent, or at least there is no requirement or expectation that it be permanent, and code is not realistically publishable (only developers can decipher it).
My team uses Spock testing framework, which can publish reports. We publish these reports as our specifications – the name of the test describes the behaviour. Whenever a spec change is requested, we create a test that captures the desired behaviour, then code to make that test go green (BDD).
Btw I can recommend Spock.