
You build the new functionality, and if commands don't work you change them.You prototype in the actual product (very agile!).You start with something that works and compiles immediately.Replacing and Reconnecting all the old bits with new bits one by one.Start building the from inside the corpse of the old script.

Textastic vim bindings series#
Let's break that down and implement it here in a series of Example Scripts. Once everything works I give the GUI one last brush-up to make everything feel coherent and polished. I build the DSP engine, and if bits don't work I change them (and the accompanying aspects of the UI). I prototype in the actual product (very agile!). I don't prototype in another environment. But this fundament on which I'm building has been evolving since 2016 and countless months have gone into it already :) This allows me to start with something that works and compiles immediately. Then start building the product from inside the corpse of the old product, replacing and reconnecting all the old bits with new bits one by one. I take a mature, stable product (in this case Ruismaker Noir) It's difficult to say how much work goes into a product though, because I take a Frankenstein approach to app development:

around Xmas and NY when I was off from work for 2 weeks). But some periods are relatively slow (I take a long time to come to a concept, articulate the value proposition, vision and rough UI model) and other periods I work on it much more intensively (e.g. even someone with back pain and a bad wrote on the Mononoke thread: I've been working on it over the course of 3 months. It follows what many developers use and I have heard it called the "Agile Method". Present as a model for making a complex Mozaic script. Has disclosed his development process and it matches what I would like to
