The topic of planning in software development is a contentious one. Some argue that software is inherently too intricate to plan accurately, prompting the question of whether planning is even worthwhile. It’s not uncommon to see Agile methodologies being used as a shield to avoid planning. For instance, teams claim, “We focus only on the next two weeks, so extensive planning isn’t necessary.“ In my recent experiences working with various software teams over the past few months, I’ve observed that many of them grapple with planning challenges without fully realizing that planning itself is a major stumbling block for them.
So to get it out of the way: I’m in favor of planning. I think it is a necessity! How much planning is something we have to talk about but let’s take a step back first.
I have a passion for building and renovating, especially crafting custom furniture. While I may not consider myself an expert, I thoroughly enjoy the process. Imagine I decide to create a unique piece of furniture. Simply rushing to the nearest hardware store without any preparation is clearly not a wise approach. I must, at the very least, take measurements to understand what materials and components I need. The extent of upfront planning depends on the complexity of the project. If it’s something I’ve constructed before, I might feel more confident and could potentially skip some planning steps. However, when tackling something entirely new with numerous uncertainties, I find myself investing more time in meticulous planning.
As I said I’m not a professional. I don’t own all the necessary tools. Therefore, if the project requires tools I don’t own, I must research where to rent them and ensure their availability. As soon as external factors like tool rental come into play, it becomes even more imperative to dedicate additional time to planning.
Did I mention that I’m not a professional. So, off course, none of my projects work as planned. Most of them are over budget and overt time. To be candid, a substantial portion of these deviations can be attributed to mistakes I’ve made along the way. I can usually accept these errors, as they often stem from my own clumsiness, which isn’t easily mitigated by better planning. However, what truly frustrates me are the errors that could have been averted through more comprehensive planning. Experiencing this type of wastage in terms of both time and money is undeniably annoying.
Another thing I realized is whenever I messed up the timeline of my project and I had to take shortcuts all of those shortcuts where related to something that nobody could see from the outside. I never wanted anybody to notice my shortcuts. Everything should work and look nice. Nevertheless, these shortcuts often translate into additional effort on my part, even if it’s just being more cautious to prevent accidental damage. Most of the time it led to me taking it apart again and fixing it properly afterwards.
Something I learned over the years is that I have to plan in order to not mess everything up completely. The other thing that I learned is to identify the parts of the project where I have to plan very meticulously and where I can allow for a bit more improvisation. As I’ve mentioned earlier, my plans are not infallible, yet they do tend to be largely accurate most of the time.
Now let’s shift back to software development. We as software developers don’t want to write bad software by taking shortcuts all the time, at least I hope you and I don’t want to do that. However, when our planning consistently falls short, we often find ourselves compelled to resort to shortcuts. Naturally, these shortcuts rarely involve the core feature set we initially aimed to deliver. More often than not, we end up taking shortcuts in areas that we as developers care about. The code quality and the overall stability of our software systems. Consequently, when our planning proves to be inaccurate, the likelihood of our software’s improvement diminishes significantly.
I know planning can be challenging at time, especially with a lot of uncertainty. So we don’t want to plan everything from beginning to the end. If there ever is something like an end to a software project. We have to find the right balance where we plan the stuff that we currently work on in more detail while keeping the more distant future more vague. Nonetheless, it’s essential to remain vigilant in our ongoing assessment of risk factors, such as external dependencies or unknown territory.
An observation I’ve made is that the level of planning for our ongoing tasks is not well understood by a lot of teams. To revisit my furniture example, if you were to task me with building something within a two-week timeframe and presented me with a few pictures outlining how it should look and function, I would undoubtedly need to dedicate more time to planning to ensure its successful completion. I would not start building something immediately. I would try to break it down into much smaller steps. I would identify steps that depend on each other and create an order if things. I would plan it in a way so I would have a plan for roughly every day because two weeks or even one week is just too long of a timeframe. We can write a lot of code in a week. We can make a lot of mistakes in a week. And worst case it will take a week until you recognize that you made a mistake, which underscores that weeks are not the appropriate level of detail when it comes to software planning.
We have to take a more thorough approach when planning the tasks we intend to tackle next. As you may have understood by now, achieving perfect planning precision at all times is unlikely but also unnecessary. However, it remains vital that we strive for a reasonable degree of accuracy most of the time.
Imagine what happens if you work in an environment where your plans are mostly correct most of the time. People start trusting your plans. People start trusting you. The kind of trust that will place you in a remarkable position for negotiations. As software developers we want to able to negotiate at all times. We aspire to allocate more time for maintenance or refactoring to improve the quality of your software systems. To achieve this we have to negotiate with the business side of things. But without trust, negotiations are pointless because if your plans fail, the stuff you negotiated for will definitely be the first that gets tossed out.
If you find yourself in a position where your plans tend to falter more often than they succeed, it’s worthwhile to invest effort in unveiling the reasons behind these planning failures and exploring strategies for enhancing your planning process.
Begin your journey toward building trust by adopting a planning approach that consistently yields successful outcomes. This reliability in planning forms the foundation upon which trust is built—trust that your plans will mostly work most of the time.
Once you’ve established this trust, you can then engage in negotiations, leading to a positive transformation in your software system over time, rather than witnessing it rot.