Subscribe to Posts
Subscribe by EmailOther People’s Code
Posted by Nicholas Brookins on 9 June, 2008As I mentioned in a previous installment, I had started the dreaded task of analyzing the source of the rdesktop project, 
to see how I might best integrate it into ToastControl. For non-programmers, ‘having the source’ often seems to be 99% of the solution, when in fact it can be closer to 10%, or I could argue even a liability sometimes. While it may seem like having the plans to a building - I don’t know of many architects that use their own system of measurement for dimensions (variable names), re-define the standard types of rooms and what they do (functions / methods), or hopefully none that use recursion (Frank Lloyd Wright meets M.C. Escher?).
The possible issues are many. First of all, rdesktop is a great piece of software and I have great respect for it, and owe thanks to the author, Matt Chapman. That could be part of the problem - what if this guy is a genius, and I’m not able to even comprehend his masterpiece?1 I risk not being able to figure it out, damaging my fragile binary ego. Even worse would be that he thinks he’s a genius, but falls somewhat short of the mark - creating an obtuse and abstruse monstrosity that seeks to reinvent software development at it’s core (you know, I’ll bet I can do better than this silly Boolean stuff…). For examples of this, look no further than the Daily WTF.
Very fortunately for me, it was none of the above. The code was well written, compact but clear. Even better is that I didn’t have to look far - after familiarizing myself with the project’s guts, I stumbled across a command-line argument that solved my problem outright. It did get me thinking however to all the times it wasn’t so easy, and how tempting it is to ‘just rewrite it’.
Guiding proper code reuse has been one of the more difficult aspects of managing a development team. I can think of many times that two teams or individuals concurrently solved the same problem on different tasks - overlap that could have been easily abstracted out and used by all. In other cases I have worked long and hard to design functionality in an application, just to find later that another has rewritten half of it to make a minuscule change - because they didn’t understand the rest and it was the path of least resistance - if not the most efficient by any means. Now I’ll take some of the blame - my code was probably not commented quite enough, I probably didn’t make the architectural intentions clear enough, and my variables were all Simpsons characters - each used multiple times in the same scope with differing prefixes and types of capitalization2.
Assuming reasonably well-written code, what can be done to make sure it gets used? It is tempting to do it yourself. We all know that writing new code is a lot more fun that figuring out someone else’s. In the commercial environment a lot of it comes down to communication and culture. This should be a major goal of leadership, not an afterthought. I think an internal wiki of sorts might work well to communicate what small modules are in the code. I’m not even talking about major segments - a lot of time could be saved just with the little 10 line methods here and there that maybe should have been added to static utility classes, etc. No one can be expected to keep the entire code-base for a medium-to-large application3 in their head, so an easy search for small snippets would be helpful. I recently took on the task of maintaining an application with one other developer, that previously had as many as 8 people working on it. I’d say were able to trim 30% of the code just by taking a second look through and enforcing better modularity. I’m sure many projects are much more cluttered.
Notes:
1. Arguably a true genius would make the code for an open-source project easy to understand, at the expense of verbosity or diminished geek-points.
2. Well not really, but I won’t rule it out for the future.
3. Except Steve Yegge and maybe Linus Torvalds.
June 17th, 2008 a.t 8:13 pm
Wow. Nice site. Call me. Or email me. Or something.
(I’ll bet you hate off-topic posts.)
May 28th, 2010 a.t 4:33 am
Sorry for the huge review, but I’m really loving the new Zune, and hope this, as well as the excellent reviews some other people have written, will help you decide if it’s the right choice for you.