Software Design Indecision

I assert that being indecisive is a terrible trait for programmers and building software. ❗

There is a timeless illusion that if we spend a little more time planning, we will uncover more issues prior to writing code, and that for some reason, uncovering issues (or rather, learning about the problem) during building said software is some type of failure. Wrong. The failure is staying within the analysis paralysis phase with the naive hopes that we will plan it perfectly this time.

You might think I’m not saying anything new, and this is all what agile is attempting to address.
Have you worked in tech companies recently?
RFCs and quarterly planning come to mind as the most egregious examples of where this failure mode springs up. Now I’m not saying RFCs and quarterly planning are inherently bad. Rather, people take them to the extreme in the hopes of finding comfort within the plan. The only comfort you will find is from building something tangible in a proof of concept that you can demo to your team.

It’s not uncommon to see an RFC for a minor feature take a week or two to write. A week or two to discuss. And while we umm and ahh about the solution in terms of theory, we learn little of the reality. Imagine spending a week on a proof of concept instead. Imagine how much more of the problem space you would actually understand alongside the constraints of the systems you are working with. Imagine the confidence that would give you to deliver better software, sooner, more effectively. 💪

“Working software over comprehensive documentation”
“Responding to change over following a plan”
Advice backed by experienced developers regarding the nature of software development published 23 years ago, yet we still think we’re the special ones. The ones who will plan it “right” this time.

Here’s a plan that doesn’t fail:

  1. Build one piece 🔨
  2. Observe that piece integrated within the system 🔍
  3. Determine the next step. Repeat. 🔁

If you need something less general and tied to working within a tech/product organisation:

  1. Try to uncover a customer problem. Talk to your customers directly. There’s plenty of user interview platforms.
  2. Build one small piece addressing that problem. Have self control, your baseline is what exists in production today. Not what could exist in the perfect solution.
  3. Release and observe that modest, humble, simple soluton (take the hint, keep it basic) integrated within the production system. This will prove whether what your users said in the interview matches the real world (when they actually need to pay).
  4. Determine the next step. Refine this problem? Address a different problem? Either way, take action based on what you learnt.

I’m not asking you to stop planning. I’m asking you to plan a little. Build a little. Repeat.