My notes on the TRPB methodology.
This is the part where you go through what you want to build. This is the most important step, if you get this wrong you could build your self into a corner, so to speak. It also gives you an opportunity to get an intimate understanding of the project.
This step is all about covering all the bases, it’s a chance to explore and find opportunities within the project. It will further laminate the chance of de-railing.
In this step you will create a realistic plan to achieve your project. You should now be able to estimate and figure out which parts are toxic on time and money and which are not. Big or small tasks should be planed, as it allows you to figure out what should be done. While you build something it’s easy to stray or lose your train of thought. At such an event go back to your plan or todo-list and get back on track.
Build your project, big or small. If it’s big then you should probably split it into project modules and repeat all the steps in “TRPB”. If it’s small I recommend stubbing out your project first. Sketch it out. Write pseudo code. etc. Then Once you have even more intimate knowledge of the project, go a-head and start coding it for real. The reason we take so many pre-steps is to avoid forking / refactoring the final code. As the final code will be hard to maneuver into a different direction when it is in it’s finalizing stage. Doing so much pre-work limits the need for making v.2 right after v.1. It also lets you find the local maxima in the project / idea. Pretty good Local maxima article by Mathew Sanders
However small your task is, doing the 4 steps will save you from frustration and stress. Be it a new feature, a refactoring, an app, or a home project. The thing is that coding is easy while the project is new and pristine. It’s a-lot harder and more demotivating to change it once it has matured. Sometimes impossible due to the shear size / complexity of the project.