Recently I happened to hear three different people talking about three different things, yet they all seemed to be conveying the same underlying message. Basically, each different message stated that, to do something correctly, you really need to understand why you are doing it. You must understand the context of what you are doing as we are constantly adjusting and making decisions. If we do not understand the context, we are much more likely to make incorrect assumptions and decisions along the way leading us to a suboptimal outcome.

Define Problems
I recently attended the Practical Product Management seminar given by Pragmatic Marketing (a great course that I highly recommend for anyone involved in the process of determining product direction). The course is based off of their Pragmatic Marketing Framework which lists all the activities associated with product management, but basically says that defining market problems is the cornerstone of product management. After all, if your product is not effectively solving a problem that your target market is experiencing, you probably won’t sell much product. This seminar is typically followed up with their Requirements That Work seminar which puts emphasis on writing requirements that define market problems, not specifications for solutions to problems or even worse, specifications to things that we haven’t even tied to a problem. Putting this emphasis on the market problem ensures that the context of the problem flows throughout the development lifecycle. Everyone that works on that requirement will understand the problem and have that context because it is documented right there, front and center.

Understand Goals
Mark Needham recently wrote a post on his blog entitled Writing off a badly executed process. In this post Mark describes a post he read in which someone had a bad experience with pair programming and has thus more or less written it off as a poor process.

Something that I’ve noticed that I do too frequently is seeing a practice being executed in a sub optimal way and coming to the conclusion that there’s a problem with the practice itself.

After giving several good examples of the above, he comes to the following conclusion…

I’m coming to the conclusion that it would be more effective to look at the goal the practice is trying to achieve first and see if we can change the way we’re executing the practice to achieve what we want.

This is a very keen observation. If you don’t understand that goal of a practice, how do you really know if it will help you or not? If a practice is meant to solve a certain problem and you aren’t experiencing that problem, then the practice probably won’t help. Also, if we don’t understand what the practice is supposed to help with, we may make assumptions and decisions that conflict with that goal and thus not get the most out of the practice. We must understand the context of the practice.

Document Intent
In my last post I talked about a few ideas from a presentation entitled Does Your Code Tell a Story given by Alan Stevens. One of the thoughts that Alan discussed that I didn’t cover in my last post was to document intent. He brought this up when discussing a quote about writing from Brenda Ueland, “Be bold, be free, be truthful”. He pointed out that to be truthful in coding, we need to document intent. What he was really talking about was ensuring the comments in our code provide context to the next person who will be reading it. Don’t just document the technical details of what a class, function, or block of code is doing, but ensure to document why and the context in which it is expected to run. This can provide a lot of useful information. If you have a function that you are writing to be used in a given context, state that so that when a developer is looking for very similar functionality to be used in a different context, she will know right away that this function was not written with that context in mind. Does it mean she can’t use it? Of course not. But it does give her some context and maybe a heads up on some issues she could have with it. It will also help her if she decides she wants to make some changes to that function as she will know the original context for which it was written and account for that.

Not only that, but let’s say it’s time for peer review and your peer is looking over that function. He is having trouble following it and senses there is an issue. If he can see the intent, the context, right at the beginning it could greatly help him out. “Oh, that’s what you’re trying to do…why don’t you try it this way?” Alan compared this to military plans. Every plan includes a section at the beginning documenting the commander’s intent, what is the purpose of the operation and the desired end state. Are we trying to take over the fort or simply blockade the opponent inside? Everyone knows that as the battle unfolds the details of the plan may need to change, but they all know and understand the commander’s intent, the context. Our code can evolve in much the same way and having that intent clearly documented will help identify if the code is still satisfying the intent during that evolution.

Conclusion
I have always been a big advocate of understanding your context for many of the reasons pointed out above, so it was nice to hear this same message from three different places all around the same time. Bottom line is, if we don’t understand why we are doing something, be it implementing a feature, trying a new practice/process, or writing a block of code, there is a decent chance we will make some incorrect assumptions along the way leading to a suboptimal outcome. We can avoid that suboptimal outcome by simply taking a little extra time up front to ensure we have context and understand the why.