In over 20 years of building software, I’ve seen a wide range of project styles. Some projects are well-planned, some are chaotic, and then there’s the most common style of all, wishful thinking with a deadline. It usually goes like this:
- Start with vague requirements. The initial brief is so high-level that it could describe ten different products. Details? “We’ll figure them out later.”
- Discover the product while building it. As development progresses, new “must-have” ideas keep popping up. Scope changes aren’t an occasional thing; they’re a way of life.
- Hold developers to an impossible standard. They’re told to fully understand the business domain, fair enough, except the people giving the requirements often don’t understand the full picture themselves.
- Lecture about quality. In the final stretch, after the requirements have shape-shifted a dozen times, we suddenly talk about “quality” like it’s been our north star all along. As if you can throw darts at a moving target and still hit the bullseye.
- Blame the builders. When the product feels rushed or messy, the finger points at the development team. The process that created the chaos? Rarely questioned.
It’s a strange paradox; we demand precision from the people developing, yet we tolerate uncertainty from the people defining the requirements. We expect quality, stability, and polish from a process that is anything but stable.
I’ve always believed great software comes from clarity, stability, and disciplined execution. Without those, it’s not really software development; it’s just wishful thinking with a deadline. A product born from improvisation, released on schedule because the calendar says so, not because it’s ready.
So here’s a thought: stop pretending quality can magically appear at the end. Quality starts where the conversation starts. If the vision is clear, the requirements are solid, and changes are intentional rather than chaotic, the development team can actually deliver something great.
To all, my intention isn’t about assigning fault. It’s about getting everyone in software to face the same truth. Otherwise, we’ll keep adding chaos to a scrum board, calling it “agile,” and pretending velocity equals progress.