Saturday, May 15, 2010

The Code is Not a Requirement Document

The other day I got one of the infamous requirements conversations that developers have every so often. It goes like this.

BA - And your change should not affect the existing behavior of the system.
Developer - OK, what is the existing behavior of the system.
BA - UM, look at the code
Developer - So what is the final result so I can look at the code.
BA - UM, look at the code
Developer - What should I tell QA to test
BA - UM, look at the code


The code is not a requirement document. Unless the code is very simple, you cannot effectively tell what the final behavior is because the code is not a final state, it's a state machine. It takes inputs in the form of data and delivers an output. Based on the inputs it can deliver an infinite amount of outputs. This is why we have bugs in our software. We don't intentionally write code that will break, its usually that some input in the software takes us down another path that we didn't expect.

Yes, I will admit that many times this is possible and even probable for a method, maybe for a class, but it doesn't tell us all the interactions of our code. There are a host of interactions, UI, database, middle ware, back-end processes, etc. Add to this the ability of callbacks, dependency injection or manipulation of the data somewhere other than in the code and it quickly gets complex.

Even if I can decipher the code, it might anchor me into a horrible solution. Maybe the code I'm looking at is the worst possible way to solve this particular problem, maybe there are simpler, easier solutions, its hard to step back and look at a problem once I see the current code as the "solution".

I use the analogy of a car in the parking lot. I can tell you a lot about that car, make and model, where it is parked. However, if you ask me to start defining rules of behavior, basically the requirements, I would start to struggle. It would depend on the driver, which way do they drive to work, maybe what time they drive to work. What is the average speed, the maximum? Do they make right turns on red? Do they take the long way, because there is always congestion on the freeway? I would probably get many of the rules right, but that because I know how a car works and some of the driving laws in my area. But if its code that I don't know very well, then all bets are off.

Am I complaining, maybe a little. But I do enjoy working with this level of detail, that why I do this and get paid for it. Its complex and messy and hard, but it's also fun. As much as I enjoy untangling some code, it doesn't tell me what the intent was or what the business is trying to accomplish. Looking at the code to see what the requirements are works in some cases, but most of the time we just need to do the hard work of hashing out what exactly it is we are trying to program.