You Built What I Asked For, But…

Image source: Adobe Stock / nd3000.

At Adobe, one of the most common things we get asked is, “How do I do this?”

It makes sense. After all, my group is a bunch of solution architects — specifically multi-solution architects. But time and again, I find the question is putting the cart before the horse and here is why.

Early in my career, I was fresh out of college and had been assigned a project. It was to build a custom solution on how to integrate various data sets, layer on rules, do some cleansing, and finally report with what-if type analysis. It was a huge challenge for me as I was learning while I was developing. I didn’t really know the best way to do things, nor the size of the project that had been handed to me. But I went about my job gathering requirements, documenting, getting sign-off, building out a section, delivering, getting sign-off, and moving on to the next piece. I would repeat this process multiple times throughout the project.

As we got to the end of the project, I was doing a final walk-through, being very proud of myself for what I had built. I had received sign-off all along the way, and this was really more of a formality. We got to one part and the client asked me if they could change this one thing. I thought about it and said no. To do what she wanted it would change the data model, all the queries and transformations sitting on top. This was a massive change. I explained as much to her, but she was quite adamant about it. Not having built up any good communication skills yet, things got a little heated. Finally, after much debate about what she had asked for and signed off on, I pulled out what I thought would end the argument — the requirements doc. I flipped to the page in question and pointed to the specific area outlining the original request. I felt quite triumphant that I had not only won the debate, I had followed our process perfectly. I was right. The client read the page for a minute and got quiet. She slowly looked up at me and she said one sentence that will remain with me forever: “You built what I asked for, but not what I wanted.”

WHAT!? I had no clue what she was talking about. She asked me to build it and told me what to build. Why would someone ask for something they didn’t want? I had no answer for her. I had no way of comprehending the fundamental gap that exists between what business users say and what a developer hears.

Years later every time I hear “How do I do this?”, I think through all the possible combinations and ways of solving it and then her voice creeps back into my mind. I then find myself asking the critical questions:

1. Why do we want to do this?
2. Let’s assume we can “do this,” what will you do with the results?
3. How real-time do we need these results?
4. How do we iterate and/or reuse this for similar use cases?

Each of these will help cross some options off the list, and others will help prevent building a one-off solution. But one thing I’ve learned — no solution is perfect. And while that is true, what we can do is gather the best information we can, document our assumptions, lay out pros and cons with a recommendation at the end based on what we know at that point in time. Systems change and so will the business, but if we don’t do our due diligence, then we will build what someone asks for — not what they wanted.

So, when someone asks, “How do you do this?”, well, it depends — what are you trying to do?