Spell-checking an essay written in Sumerian.
Writing software is hard, but writing software that your end-user actually wants is even harder. This is something I’ve come across myself: figuring out what you think is required is easy, but getting continuous feedback from someone with a non-technical background is considerably more challenging.
An explanation was provided as follows:
“One of the reasons that the classic gather requirements, design, code, ship approach doesn’t work is that it is anchored by the concept that we know what the requirements are. But we rarely do. Your business users will have a vague idea of what they want to achieve, but they neither know nor care about the details. That’s part of our value: we intuit intent and convert it to code.”
In short, trying to get end-users to sign off on requirements they neither understand nor appreciate the details in, is like trying to get them to spell-check an essay written in Sumerian. “They’ll make some random changes to save face and sign it off to get you out of their office.”
Give them something that runs, let them use it and inevitably break it, then change requirements as necessary and add more functionality.
Thank you for reading! If it helped, drop a like and come back tomorrow :)
#PathToSWE
