The source code glut
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
- 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
- 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
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
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.