For a long while my default approach when I came across a new code base that I wanted to change was to read all the code and try and understand how it all fitted together by sketching out flow of control diagrams.

Only after I’d done that would I start planning how I could make my changes.

This works reasonably well but it’s quite time consuming and a couple of years ago a former colleague (I can’t remember who!) showed me another technique which seems to be more effective.

Rather than trying to understand how all the code fits together we briefly skim it to get a general understanding but don’t drill into the specifics.

Instead once we’ve got a general understanding we make changes to the code and then either run the application or run the tests to see if it works as we expected.

There’ll often be a couple of cycles before we understand exactly what changes we need to make and I’ve found that reverting the code after each attempt works quite well.

When we change the same bit of code for the 2nd/3rd/4th time it takes a fraction of the time it did on the 1st occasion and we’ll often spot improvements that we can make which we didn’t notice before.

I’d recommend this as an exploratory tool if you haven’t already tried it and as an added bonus it’s much more fun than statically analysing code and trying to figure out how it’s mean to work!