I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing enough time in gaining that understanding early on means wasting far more time later.
IME, a huge amount of rework in modern software development results from diving into the implementation before the requirements were properly understood, a reasonable design was created and both were recorded in some useful form and reviewed by the relevant people to make sure everyone was on the same page.
We seem to have gone from one extreme to another with our processes. We realised that waterfalls that start with months of requirements capture followed by months of BDUF aren’t a great idea. But now we often seem to have one-paragraph tickets, maybe spend a few minutes thinking of some class names that look about right for each one, and then dive into coding. And then a week later we find that two developers working on three tickets have implemented the same concept four different ways and each of them was a different 75% of what the customer actually needed.
IME, a huge amount of rework in modern software development results from diving into the implementation before the requirements were properly understood, a reasonable design was created and both were recorded in some useful form and reviewed by the relevant people to make sure everyone was on the same page.
We seem to have gone from one extreme to another with our processes. We realised that waterfalls that start with months of requirements capture followed by months of BDUF aren’t a great idea. But now we often seem to have one-paragraph tickets, maybe spend a few minutes thinking of some class names that look about right for each one, and then dive into coding. And then a week later we find that two developers working on three tickets have implemented the same concept four different ways and each of them was a different 75% of what the customer actually needed.