Matt Keally's Blog

In all my previous programming projects that I’ve done on my own, I’ve always remembered exactly how everything worked: what every function and variable did and how every data structure and class interacted with each other.  In a way, I was able to store and compile the entire source code in my mind and know exactly how it would work.  With my current project, I can no longer do that.  The code is just too big and I can only remember pieces of it.

I think I’ve got about 10,000 lines that I’ve written for this over the past few months, which easily surpasses anything I’ve worked on before.  Nearly every week I’ve made significant changes to existing code and added in a lot of new stuff.  Something of this size in a constant state of change is a new challenge to me.

Consequently, I’ve taken a lot of steps to keep everything organized since I can’t do it in my head.  Since the code is mostly in Java, I’ve done my best to take advantage of its object oriented nature.  I try to keep things as loosely coupled as possible so that when I’ve got to make some modifications, it doesn’t screw everything.  I’ve made use of Java packages to group stuff together that has similar functions.  On top of all that, I’ve put the project into a Subversion repository so I can always go back to old stuff and so that I can work on it from multiple machines without it being a huge headache.

Of course, this is standard procedure for any programmer, but until now it’s never been absolutely necessary for any projects I’ve worked on alone.  During my internships, I had worked on stuff that was in the tens of thousands of lines, but it had been contributed to by other people.  Good programming practices made sense since other people would be working with my code and vice versa.  With what I’m working on now, it’s almost as if some of the stuff was written by someone else.  I’ll come across a method that I wrote two months ago and not remember much of how it worked.  I feel like a one man programming team.  I recall an interview of Bjarne Stroustrup that complained about grad students that would work on their own projects and write terrible code, not expecting that later on it would be needed for another project or possibly released to others.  I’d rather not fall into that trap since the stuff I’m working on now will likely see plenty of use in the future.

Increased comprehensiveness is one reason they say that Extreme Programming is so valuable — having someone else there with you really helps in making something that not only works, but is built in such a way that everyone can understand it.  Some people, including myself, can often write something that is almost completely unintelligible to others.  Knowing this is one reason I like to avoid cramming several actions into one line, for which I’ve gotten grief from others about being “verbose”.  I’d rather be verbose, but understandable than concise ambiguous.  I’ve never understood why people brag about writing a program in as few lines as possible, usually in some loosely-typed scripting language.  For part of this project, I had to use someone else’s MATLAB script to convert some trace data.  Of course, they crammed the conversion code into about fifteen lines that took me forever to figure out what it did (partly because I’ve never used MATLAB).  Not wanting to revisit that, I translated the code into Java in a more drawn out format so it would integrate well with the rest of my project.

I’m sure there are plenty of things I could do to make my code more better than it is now, but it’s hard to improve when there isn’t someone to give you feedback.  I can learn from my successes and mistakes from previous projects when working on my current project, however.  It seems as if most good programming practices don’t matter so much when the code size is small, but when a threshold is crossed, they seem to go from irrelevant to absolutely necessary.