Pedro Arantesrose

From Reactive Planning Model to Natural Planning Model

Until some point, the project was manageable, but after some feature requests and bug reports, it became unfeasible. In addition, almost every bug fix or feature implementation broke other "uncorrelated" parts of the application. That slowed us down a lot because our client and his customers were using the software, and we had to rush to fix the new bugs (yes, we didn't have testing at that time).
Articles, June 16, 2021 (changes)
Reading time: 5 minutes
Photo by on Unsplash

Photo by on Unsplash

I work with software development. Two friends from university and me started a software house at the end of 2018. Our first big application started at the same time we founded Triângulos Tecnologia. Unfortunately, we didn't have much experience in software development when we began the project. As a result, we made mistakes in some parts of the project, from hiring, estimating the costs, ensuring application and architecture quality.

Reading Getting Things Done reminded me of the path we've been through these years creating software. I had that click, "Wow, I think I experienced this before" when reading about the Reactive Planning Model and Natural Planning Model. The main goal of this text is to share with you our experience, based on these planning models, and how you may save your time if you plan your projects well.

The Reactive Planning Model

It's interesting to detect the Reactive Planning Model when you don't have experience in planning. So let me share our path with you.

Every small software project starts perfectly. Very well organized, documented, without bugs, everyone with an immense amount of energy to make things happen. And this is expected because, well, the project is small. We have control over it. The issues appear when it grows and when the number of features and complexity increases. Imagine that we worked on the application for some months without effective management, and our client has already been using it.

Until some point, the project was manageable, but it became unfeasible after some feature requests and bug reports. In addition, almost every bug fix or feature implementation broke other "uncorrelated" parts of the application. That slowed us down a lot because our client and his customers were using the software, and we had to rush to fix the new bugs (yes, we didn't have testing at that time).

We were living doing the next actions. Implementation, a bug appears, the client warns us, we fix the bug. That was our cycle. This situation became unworkable until we finally assembled the team and said, "We need to get organized." So instead of starting coding to fix the newest bug, we organized our priorities and requests.

This organization relieved our tension for a moment, but the bugs continued to appear. Then the manager realized that our initial planning wasn't enough and suggested doing brainstorming. It was good. We had good ideas for ensuring software quality, such as creating more tests and documenting the application. The number of bugs decreased but continued to appear. Why? Because after some time, even though we know that tests are vital, our mindset was something like this, "We know that tests are important, but why should we spend time doing tests if it's better to release the feature as soon as possible?"

So we went to the next step of the Reactive Planning Model, the vision. We know that tests and documentation improve software quality, but what will we achieve if we do that? We'll achieve excellent software quality, customers will be happy, we'll have a good reputation, to name a few. That is the vision. Clear and concise. But again, it wasn't strong enough to make us do what we proposed on brainstorming. We needed the last step.

Finally, after a long time of struggles and learning, we've got the last step of the model, purpose, and principles. It's the why. "Why do we want to build good software?" "Why do we want to make our customers satisfied." "Why do we need to create tests and document well?" The "why" is the last step of this model.

After thinking about this project and others, you've concluded that your biggest problem creating software without tests and documentation is about time, and consequently, money. The time you spent creating tests and documentation while we implement the feature is much less than the time you'll spend fixing it some months later. And there are some reasons why this happens: you forget the main feature idea, you're working on another feature and have the context switching cost, the developer who worked on that feature doesn't work with you anymore, and so on. People generally don't realize the difference between these costs because of the hyperbolic discounting. A cost in the future seems small in the present.

Another principle is that it's risky to keep technical debts when working with software because you don't know your future opportunity costs. We can define opportunity cost as the value of the best-foregone option you could have chosen. For example, imagine working on a project with some technical debts, and a considerable opportunity appears to you. But, unfortunately, you can't take and don't have time to spend on this opportunity because you're full-time supporting the current project.

The Natural Planning Model

The Natural Planning Model has the same steps but in the opposite order.

  1. Defining purpose and principles
  2. Outcome visioning
  3. Brainstorming
  4. Organizing
  5. Identifying next actions

David Allen says that this sequence is natural for the brain to plan tasks. Once you do these steps in this sequence, you perform with better efficiency.

Once we've realized that we were working reactive, we've changed our processes to apply natural planning. The most significant upside is that we improved the quality of your applications and their maintainability, which leads us to save more time and money. Consequently, we can take advantage of the opportunities that we receive.

If you want to know more about how natural planning work with more details, please, check my notes about it and the summary of the book Getting Things Done.

Final Thoughts

It was a rich path we've been through because we've learned and experienced many things. It wasn't easy. This change that occurred to us was only possible because of a unique principle: time is your most important asset. Once you realize that, you work hard to use your time most effectively and create stuff that will save your time in the future. While Reactive Planning Model makes you build things that will consume your time in the future, Natural Planning Model doesn't.

Once you decide to adopt the Natural Planning Model planning in your file, the next thing you must do is answer the question:

What purpose and principles will guide you?

RecommendationsDo you want to see all posts instead?
Hyperbolic Discounting
This theory states that humans discount the value of a later reward, by the factor that increases with the length of the delay.
Zettelkasten, April 06, 2021
Natural Planning Model
It's the more effective way to think about projects and situations because it makes thinks happen sooner, better, and more successfully.
Zettelkasten, June 07, 2021
Reactive Planning Model
When a team starts a project without planning ahead, it's possible that the reactive planning model ensues.
Zettelkasten, June 06, 2021
It's a situation where a group of people meets to think about a problem and try to have as many ideas as possible.
Zettelkasten, May 13, 2021
Context Switching
Each extra task or "context" you switch eats up 20-80% of your overall productivity.
Zettelkasten, June 02, 2021
Opportunity Cost
Opportunity cost is the loss of the benefit that could have been enjoyed if the best choice was chosen instead.
Zettelkasten, June 03, 2021
Ideas in Open Loop
When you decide to do some task, obligation, or plan without executing it, the mind creates an open loop.
Zettelkasten, April 10, 2021


On Tuesday (not weekly), I publish my most recent readings and thoughts. Subscribe to my newsletter if you want to follow topics about #startups, #mental-models, #cryptocurrencies, and more. You can also check my past issues on Revue.

By subscribing, you agree with Revue’s Terms and Privacy Policy