The quickest way to understand code that someone else has written is to perform a code walkthrough. I've been hesitant of approaching the PhD student for help as I appreciate he has his own demanding schedule right now, and a multitude of activities to juggle - commence doctoral thesis write-up, complete final experimentation, write Post Doc grant proposals, apply for Departmental extension money, write that elusive first journal article. Nevertheless, if I was to remain on track, I'd need a little help from a friend.
I think he could see the frustration brewing in my eyes and kindly agreed to help. The exercise was only intended to be an hour, but once the code walkthrough began, it was like opening Pandora's Box and a cascade of tricky code surfaced. Time flew by with animated discussions on why code was written in X way instead of Y way, and also referenced the underlying Biology involved with the system, and any abstractions/assumptions built in to the simulation due to lack of firm Biological understanding - the disease in question was first discovered in the mid-1800's and we still do not understand how it actually manifests itself in humans, so a little artistic licence in the simulation is surely acceptable! Two and a half hours later the walkthrough, which had then manifested itself into an impromptu demo of the simulation through the graphical user interface (GUI) was done.
My understanding had increased exponentially during the morning, and I must confess to feeling that I'm back on track with the schedule. The UML diagrams that I've generated as part of the reverse engineering process to understand the code were great to convey interactions, sequences and activities of code modules, but couldn't fully come to life until I'd received a little help. Implementation against schedule now seems much more promising.
Now it's time to design code amendments and actually start building an updated simulator.
No comments:
Post a Comment