But The Requirements Just Changed

Or at least someone told you they did. But did they really change? Or do you just understand them better?

Here’s the thing. If you go to your user, not the stakeholder, not the purchasing agent, not the product owner, but the user, and get them to describe the problem they need to have solved, it won’t change much. They may come up with more problems as you talk, but problems rarely change or go away by themselves. As you build up your ubiquitous language with the user, you’ll get more detail. As you provide the user counter-examples you’ll find out what they don’t want. As you understand the problem domain better you’ll see the solution space more clearly.

And that will lead you to recognizing that you need to build something other than what you first thought you needed to build. You’ll realize you were initially wrong. Or more accurately, initially you weren’t quite right.

But the real requirements, the problems you’re trying to solve, haven’t changed.

I’ve been doing software engineering for a long time now. And almost every time I thought the requirements had changed, what actually happened was that I learned more details about what the problem really was and constraints I had to keep in mind as I built the solution.

This has been true when doing tradeoff analysis for the US Air Force. That was a multi-variate optimization situation. As we optimized, we learned more about the constraints we had to optimize within. We learned about new factors we needed to consider, and we learned that factors we thought were important really weren’t. Those weren’t actual requirement changes. What changed was our understand of what the requirements meant. We thought we knew at the start, but we didn’t.

It was true when making games. The requirement there was easy. Make it fun. The trick there was understanding what fun was. Because it was different for different games. The market for a Star Trek game had its definition of fun. Simulation lovers had different ideas. Fun was different for different kinds of simulations. Flight game fans had one set of ideas. Rail fans had a different one. Even in the flight genre there were differences. Sure, there was some overlap in the demographics for Falcon 4.0, Microsoft Flight Simulator, Combat Flight Simulator, Crimson Skys, and Fighter Ace. Even across those games there were very different ideas of what fun looked like. We started with what we thought was fun, but only through extensive and continuous conversations with users did we understand what they thought was fun.

It’s still true when building infrastructure tools for internal customers. The more we talk to our customers, the better we understand what their pain really looks like, and what we can do to solve it. We look at our metrics, hear a complaint or two, and think we know exactly what our customers want. And yet, when we build it and share it with them, they explain to us exactly where we’re wrong. So we meet them where they are.

In all of those cases, and others, what the users wanted and needed, the problems they wanted us to solve, weren’t changing. Just our understanding of them. And in some cases, their understanding of what was possible¹. In all cases, we learn together. And use that learning to really solve the problem.

In fact, about the only time that software requirements have actually changed on me has been in school. And in those cases, there was no user. There was no problem to solve. There was just a professor telling us to write some code that did a certain thing. Then, later, they would tell us something new. And we would have to solve the problem again, acknowledging and incorporating the new knowledge. It wasn’t deeper understanding of the user’s problem because there was no user, and there was no problem to understand. Just a set of requirements to meet. That’s not software engineering. That’s being a code monkey in a feature factory. And that’s something I avoid, because it’s not fulfilling, I don’t learn anything, and above all, it’s not fun.