Customers

By Rene Rodriguez

I was recently reading Karl Seguin’s “Foundations of Programming” ebook when I came across a sentence that reminded me of my first software development consulting job, eons ago. At the time I had been going to graduate school and took a break to think about my dissertation (which I ended up not finishing, but that’s another story). I was back home, had landed a part-time teaching job at a local college, and was looking for something else to do. My brother was a consultant with several customers in town; he had written an application in Clipper for DOS (bonus points if you know what I’m talking about) which he adapted to each of his customers. So I asked my brother if there was anything I could help him with. He told me the brother of one of his customers wanted a little program about lotto combinations. “Cool!”, the mathematician in me said. So the guy told his brother what he wanted, who in turn told my brother, who told me. Yeah. I know what you are thinking and you know where this is going, but the program looked so simple I couldn’t believe the description I got was anything different from what the guy wanted.

What the customer wanted

I finished the program after a couple of days of hacking away with Turbo Pascal. I agreed to meet with my brother’s customer and his brother to deliver it. I demoed it to them and he said “that’s not what I wanted…”

“What do you mean?”

He proceeded to show me his notebook, filled with number combinations, frequencies, graphs, and more, and explaining to me what he wanted the program to do for him. After the meeting I was angry, mostly at myself for not taking the time and caution to talk directly to the guy in the first place, which brings me back to the sentence I mentioned at the beginning:

The client knew far more about his or her business than I did. Not only that, but it was their money and my job was to make them get the most out of it. As the relationship turned more collaborative and positive, not only did the end result greatly improve, but programming became fun again.

And that’s exactly what happened: we met a few times afterward, developed a great working relationship, and programming the requested changes was fun to do.

The lessons I learned, work together with your customer and respond to changes, have served me well. I haven’t encountered a software project that didn’t require customer input and changes as the project progresses. Furthermore, I found out I was empirically Agile, as these lessons are embodied in the Agile Manifesto and are core to the Agile methodologies. If you are interested in reading more, one of my favorite blogs on Agile is James Shore’s “The Art of Agile” , which advocates XP and contains very valuable bits of information on the programming craft.