I'm personally very sympathetic and interested in avant-garde, experimental software development methods like this. I understand that most devs reading this is mortified and doubt about my sanity, but I <i>do</i> unironically use extremely, stupidly limiting techniques like this. For example, in my current project (working on an automated theorem prover) I have this rule that development happens in epochs. I write code in file theorem_prover_v1.rs, I run some unittests, run some tests, take notes. Copy the file to theorem_prover_v2.rs and attempt to rewrite the whole thing based on the previous form. Every line is critically examined. As many lines are attempted to be modified as possible. Do we need this type? Is this mathematically sound? Can I really justify that this abstraction is necessary? [1] It's an extremely inefficient and slow process, but a lot of software engineers don't appreciate that development efficiency--although <i>usually</i> among the most important factors of the success of the project--it's not necessarily <i>the only</i> important factor for all projects, and it is <i>worth</i> experimenting with methods that are intentionally inefficient but has promise to improve something else. You don't like it, you can always go back to Agile or whatever else you do at your day job.<p>Art progresses with extreme restrictions. The same way Schoenberg put seemingly absurd restrictions in his music ((very roughly) don't repeat the same note before playing every other note etc...) to create something radically novel, we as software developers can do so to advance our art as well.<p>[1] This method is the anti-thesis of the common "never rewrite a working program" software development methodology. Here, the experiment is to see what happens if we always rewrite, and never add or modify, i.e. refactors are never allowed, instead if things need changing we need to re-design the whole thing top-bottom with the new understanding.