Digging For Requirements

I think my favorite programming book of all time is The Pragmatic Programmer. It was the first introduction I had to being more intentional with my programming. There were certain types of programming patterns that felt good, but I didn't know why. This book taught me why those things were good, what name people had given to those good things, and showed me the next steps to take in those areas of good.

James Marcus Bach had a series of tweets on Tuesday that reminded me of the Pragmatic Programmer's section, "The Requirements Pit." I still haven't fully grasped the depth of the wisdom of this quote from the book:

Requirements rarely lie on the surface. Normally, they're buried deep beneath layers of assumptions, misconceptions, and politics.

Here's what James had to say on twitter:

Here's the typical pattern for requirements definition on software products:

"What do you want?"

"We want this!"

"You sure?"


"This is what that looks like."

"Oh, we didn't what THAT."

"Okay, what do you want?"

The purpose of testing is largely to force everyone to see the detailed implications of their vague daydreams.

This resonates with my experiences very well. There's especially a problem if you don't take the time up front to say, "This is what that looks like." Because the next opportunity for the end user to find out that what they asked for isn't what they wanted is after a bunch of time and money has been spent.


Comments !