Planning before the planning

--Originally published at Debugging My Mind

Yes, just when we thought just planning was good enough we have to tackle this new idea, preliminary planning, but is it really new?

There’s a lot of activities and processes when working that we do without much thought, that pass on as quick non important topic, but after some reading and a bit of reflection, it becomes clear that they are actually  way more relevant than they seem.

How many times do we start a project based on an idea, just to realize not everyone is actually fully attuned to it, I certainly have, a lot of the times we assume that everyone understands what we’re going to do, but it ends up causing some confussion and problems down the road, it even prevents potential improvements to the project due to not fully understanding the goal. We all find it silly to have to physically write the actual objective and vision of a project, but it ends up being more useful to understanding what we’re all going to work towards in the end.

In school work, we often don’t truly have an external group making the huge decisions for our projects, it’s mostly up to us (with a bit of feedback from teachers most of the times) to decide and do changes as we see fit or simply choose the features we need to include in our project. This ends up being messy most of the times, overestimating what we can add and leaving things out that we couldn’t complete or even changing our end goal depending on the final product we were able to create.

There’s definitely little to no preliminary planning in most projects we do for school, mostly due to time restrictions and the advancing nature of the work, where we’re being guided by our teacher, but there’s definitely a lot of opportunities to start making use of what we can and specially on what might definitely need it. I believe these planning tools work as guidelines of how much more preparations and documentation we can do to make the implementation part easier, but it’s up to us to recognize depending on the project, which ones we gotta use, which ones can be taken out due to time or goal and which ones end up being critical to make things easier, even then I do think it’s worth knowing and considering all of  them and how they make the difference between a programmer and a software engineer.