News

The source code glut

• By Mike Gunderloy
• March 1, 2004

One way or another, I've run across quite a bit of software in source code form lately. A few data points:

• Some of the source code for Windows 2000 leaked a few weeks ago. No, I haven't looked at it, and neither should you. But it's out there.
• The open source movement, of course, has a political commitment to publishing source code. This will get you everything from operating systems to games to Web servers in source form.
• Between reflection and reverse engineering, much software that ships without source code is easily turned into something approximating the original source.
• Component vendors including Desaware and Developer Express are now routinely sellling source code with their products.
• Microsoft appears determined to make the Microsoft Developer Network larger than the rest of the Web put together, and to include code samples on every page.
• And, of course, there are the hundreds (thousands?) of developer weblogs out there posting snippets of code from time to time.

Given all this source code, I think it's fair to ask: is the development process improved by its easy availability? Should you even spend any time looking at all the sample code out there, or just learn the basic principles and write your own?

A good starting point is Scott Hanselman's Rule of Programming #0x3eA:

Just because code is on the Internet doesn't mean you should cut and paste it into your production system. Do you chew gum you find on the street? Give code you find on the 'NET the same amount of attention you'd give advice scrawled on a public bathroom wall.

Now, just because I said it's a good starting point doesn't mean I agree 100%. As in so many other parts of the developer's job, there are tradeoffs here. For example, one of my current projects involves putting together a little application for the PocketPC. The budget is limited, and it's been a while since I've done much work with the .NET Compact Framework. Given the circumstances, you bet I'm using code from the Internet. Ten minutes work with Google can produce code for creating date input controls or XML registry interfaces at least as good as I could write in a couple of hours. That's time (and money) saved for my customer, and even if you throw in time spent testing the code, it's still a win.

But there are those nasty tradeoffs. I've now got a project that, while it works, uses several different coding style and naming conventions in its various parts. I know that if a maintenance programmer looks at this work in the future, she'll say bad things about my skills. And I haven't bothered to work through all the API calls in the date entry control (why oh why isn't this exposed as a native control in the .NET CF?) But as a way of putting together functionality quickly, finding ready-made code is hard to beat.

I could make an analogy here about bolting a Pinto carb on to a VW engine and getting a running vehicle (yes, I've done that too), but analogies are notoriously slippery things. So let's stick to the source code itself. For the most part, the tradeoff here is one of speed vs. safety. Using the source code that you find on the street gets the product out the door more quickly. Using the source code that you write yourself gets the product done right. And the key point: much as we'd like to pretend otherwise, sometimes "quickly" really is more important than "right". The key, of course, is to know when those times arrive.

But to answer my own question, yes, I think development is improved by having all that source code piled up in the street, and it's worth taking the time to have a look at some of it (assuming you're not working on a project where code quality is absolutely critical, like embedded systems for medical equipment). Just remember to apply your own experience and common sense when deciding whether any particular piece of code can be incorporated as-is in your own projects, or whether it should merely serve as an inspiration to write your own.