Recently, I attended a talk about “Mikado Method”. Let me summarize what this is all about. When adding a new feature to an existing code base, you often start with a rough idea and you think everything will be nice and easy so, you start touching the first class. See that your change breaks the code. You move on to the next class to adjust it, which breaks further code. You touch more and more code, and after a few hours you end up in a mess, which might take you days to recover from.
This situation is what you try to avoid using Mikado Method. You start with pen and paper; you shortly sketch what you are planning to do. You start touching the first bits, until you realize this will break another area of code. You realize what you will need to adjust in order to fix this, and you write it down as step 2 on your note. Now, the interesting part – you revert the changes from step 1 and instead, you start doing the necessary prerequisites for step 1 by attempting step 2. Again you will realize, this will break something, which you will have to adjust first – so you write down the next step and again you revert your changes.
Continue doing this until you have reached a step that will compile and not break your code. Then in reverse order, follow the steps on your note.
This is a very organized approach, which will help you to not end up in a mess, not seeing the forest for the trees. However, this approach needs a lot of practice. In the beginning, you will have to constantly repress your urge to just do a change straight forward, without reverting every attempt. I have only tried it with a very small example so far. I guess when accustomed to this reverse style of working, the organized form of this approach will end up saving time instead of wasting time.