The 50,000-Word Letter: Why Software Takes Time

If you’ve ever sat in a boardroom and wondered why a seemingly simple feature update is taking months rather than days, you aren’t alone. To the uninitiated, writing code looks a lot like typing; and we can all type fairly quickly.

The reality is rather different. To help non-technical colleagues understand the rigour required, I often ask them to imagine they are writing a letter.

This isn’t just any letter. It needs to be perfect. I’m not talking about “business-standard” perfect; I mean that a single misspelling, a semicolon where a colon should be, or even one extra space between words renders the entire document a total failure. It simply won’t be read.

Now, make that letter 50,000 words long.

You must express your ideas with absolute precision, covering every possible nuance of the subject without adding a single redundant sentence. It has to be understandable to a layman, yet stand up to the scrutiny of a world-renowned expert.

But you aren’t writing it in isolation. You have ten stakeholders, all with differing opinions on what the letter should say. Some of those opinions are contradictory. You also have six co-authors; each of you is responsible for a different section, but the narrative must flow so seamlessly that the reader cannot tell where one person’s work ends and another’s begins. Managing this complexity requires the discipline of a flight crew, not the heroics of a lone genius. And if one author changes one word on one page, you need to check all the pages to make sure they still make sense in light of that change.

Finally, you must include illustrations. These must be aesthetically pleasing to everyone, or they’ll complain to you personally about your “poor taste.” And, before you’ve even put pen to paper, I need you to tell me exactly what time on what Tuesday three months from now you will be finished.

That is a fair approximation of building a relatively simple piece of software. For a platform that operates across an entire organisation, you can increase that complexity by two orders of magnitude.

I’ve sat across from C-suite colleagues who have expressed deep frustration that predictions of “readiness” aren’t always 100% accurate. Yet, these same colleagues, when asked to document their requirements for a project, often tell me it’s “too complicated to write down” and that they need to explain it in person.

The irony is usually lost on them: if a requirement is too complex to be written in plain English, imagine the difficulty of translating it into the unforgiving, hyper-logical syntax of a computer. Computers do not do “nuance” or “you know what I mean.”

The good news is that we have become very good at managing this. Skilled product builders and engineers have developed techniques, from agile methodologies to automated testing, to figure out exactly what is needed and ensure it meets the mark. We are also now in the era of AI augmentation, which helps us handle the “typing” and the boilerplate more efficiently than ever.

However, the core challenge remains. Software is not a manufacturing process; it is an exercise in extreme logic and collaborative communication. When your CTO asks for time, it might not be because they’re writing slowly. They may be ensuring that the 50,000-word letter doesn’t fall apart because of a single misplaced space.