Mark Needham

Thoughts on Software Development

Reading Code: Know what you’re looking for

with 2 comments

In the last week or so before Christmas I got the chance to spend some time pairing with my colleague Alex Harin while trying to understand how an existing application which we were investigating was written.

We knew from watching a demo of the application that the user was able to send some processing off to be done in the background and that they would be emailed once that had happened.

Our starting point was therefore to work backwards from the labels on the UI and finding which code got executed when the user submitted the task.

My initial approach was to find the entry point and then follow the method calls line by line, slowly building my knowledge of how the application actually worked.

Alex used a much quicker approach whereby he thought about how the code would be designed and then looked for the bit of code which proved his belief.

In this case we knew that the application had a 2 tier architecture and that it didn’t use any middleware which meant that it would more than likely be using the database as a queue to store the tasks to be processed.

Another colleague and I were then able to make use of this approach when looking at another piece of code.

It was being used to do pricing and we knew that there were different algorithms depending on which country you were in, which meant that we needed to look for anything country related to answer our questions.

Effectively we’re looking at the code with a hypothesis in hand and then trying to see whether or not what we see proves or disproves that hypotheses.

I need to practice a bit more but it seems to let you navigate code much more quickly and makes you much less likely to dive down a rabbit hole.

Be Sociable, Share!

Written by Mark Needham

December 29th, 2011 at 2:43 am

Posted in Reading Code

Tagged with

  • Vishnu Iyengar

    I’ve had both good and bad experiences with this. Many times it does save me time that I have a hypothesis and it gets validated. 

    But once in a while I expect something and I see it, and I do not realize there is additional code that does not conform to what I expect. I go ahead and make changes only to see it break under special conditions that were not visible to me because I jumped straight to a specific point.

    Ideally with well designed code, maybe this shouldnt occur. But it has occurred often enough that a hack has intentionally been introduced as good enough, that I have had to learn to become a bit wary

  • Hmm interesting. I’ve been wondering if maybe you don’t necessarily need a hypothesis, just a rough big picture which you can fill in as you learn more about the code.

    It’s effectively drawing a picture by starting with the outline rather than with the detail. Not sure if that analogy makes sense or not. I need to try this technique out on some code bases and see if I can understand them better.