My notes on the TRPB methodology.
Think (25%)
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.
Research (25%)
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.
Plan (25%)
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 (25%)
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
Conclusion
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.
Note:
The learning phase (Think, Research, Plan) plays a key role in your ability to execute efficiently. When you have learned sufficiently, connecting the dots become easier to get right. Basically wire up all your brains neurons to become a domain expert on the subject to solve. You might be able to execute on insufficient learning, but at the risk of executing on the wrong things. The result might be less elegant and harder to iterate on. The learning phase is also ephemeral, make sure you execute when your brain is still immersed in the subject.
Note 2:
While iterating is a great way to build things. It may also produce false positives. You want to make sure the end goal can be achieve at some point. So make sure your not iterating just to add things. Iterate also means removing things towards the end goal. The end goal can be it’s own meta exploration.