Iterative Persistence

For example, we often set goals: I want to be successful, or whatever the goal is. All goals have that final destination, whether it’s getting to the top, or getting that job, that car, or that house.

I’ve noticed that we come up with a plan on how to do this, let’s say for the example the goal is getting into shape and being more healthy.

So we create a plan: Go to the gym every day and start eating healthy food. I’ve noticed that we put so much pressure on ourselves that we end up regressing and never attain our goals.

What are we doing wrong? Why does this happen?

After many years of working on my personal development, I’ve realised that we fail because we focus on the end goal too much when we should be focusing on doing the things that will help us attain the goal.

Many projects have failed in the software because of trying to deliver the entire solution in one big bang. Now you may ask what does software have to do with not attaining our goals? I’m a Software Developer, and I’m currently doing a course in Software Engineering. In this course, there’s an article by Barry Boehm “A View of 20th and 21st Century Software Engineering” in which he takes us through the evolution of Software Engineering by examining, process, approaches, trends, principles, methods, concurrent (agile), sequential process (waterfall), etc.

One of the main problems was (and still is) trying to design and spec all features needed for the software. This process was and still plagued with a lack of knowing the actual goal of the software. The client understands what they want, but translating this into a formal design, usually, items are missed and are discovered later when development has started already. Now that means going into another design session to see how these new pieces would fit, and this would be a back and forth; eventually, this project fails.

As software engineers discovered this problem, some changed the approach to an iterative process where some design is done upfront, key features are selected from a list, and developed in a sprint lets say 2 to 3 weeks. These feature the deployed after the sprint.

So now getting back to goals and why we sometimes don’t attain them. Like software, we need to adapt the plan initially to be more of an iterative procedure.

Conclusion

My conclusion is almost like software engineering we have to treat our goals the same. Set a goal, see the big picture, plan how you will achieve it. Put the big picture aside, focus on doing the steps in your plan, for example, if you want to get into the shape and go to the gym every day. Go gym every day for the next 3 to 4 weeks, don’t worry about how you are doing, and focus on getting to the gym every day. Once you’ve been going to gym every day for 3 to 4 weeks, you find that now your goal of getting into shape would have changed, now it might be; okay great I’m starting to get into shape, but I see that my gym will be more effective if I start eating healthy food. Now you have a new item added to your list, and you may plan accordingly. For example, you’ve also updated your diet to a healthy one every day you go to the gym. You do this for next 3 to 4 weeks later, your eating healthy, gyming every day but now you want to add on something else, well you repeat the iterative process.

I think you will have more success with this iterative approach than if you bundled up all the things you want into one significant goal example, this year: I want to get into shape, and I want to eat healthy food.