ind-igo

Programming as Theory Building

Peter Naur

Peter Naur's classic 1985 essay "Programming as Theory Building" argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it's lossy, so you can't reconstruct

ind-igo

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

ind-igo

I contributed to the ZKOPRU Trusted Setup Multi-Party Ceremony.
The following are my contribution signatures:
Circuit: zk_transaction_1_2 
          Contributor # 204
          Hash: 9da9c45d d9f457b4 e3a2e2bf e6dae480
 50cbe5af 89c79286 c09e059c 5375ea57
 de202d6f bbf780c4 97d4fca1 9aac3512
 6dc282c8 b59008a9 58fc8223 1087b6c9