January 2016
Volume 31 Number 1
[Don't Get Me Started]
Moving Forward, Looking Back
By David Platt | January 2016
.jpg "David Platt")
We’ve just passed the winter solstice here in the northern hemisphere. The days are dark and cold, but they’ve started getting longer, albeit minutely. This is the month named for Janus, the Romans’ two-faced god who looks both forward and back. This time of year and this god have lessons for us geeks.
In our industry, we’re constantly looking forward. What’s new today? What’s in beta for release next quarter? What has Microsoft announced for next year? We rarely look back.
But what happens to programs written with last year’s whiz-bang tools, or with the tools from the year before? These legacies often remain in service longer than we expect or want. As Y2K taught us, they continually need maintenance, bug fixes, adjustments to external changes. But as their technology ages, finding someone able and willing to work on them gets increasingly difficult.
I recently read that Larry Zottarelli, the last original programmer who worked on the Voyager 1 and 2 spacecraft, is retiring. NASA’s Jet Propulsion Laboratory (JPL) will need a new programmer for some very old code.
I remember the Voyagers’ launch in 1977, when the planets aligned for a grand tour. I remember marveling at some of their discoveries, such as volcanoes on Jupiter’s moon Io, and the moon Prometheus that shepherds the F Ring of Saturn.
Voyager 1 has left the solar system and entered interstellar space. Voyager 2 will follow soon after this column runs. They’re both still sending back data, though their radio waves now require 17 hours to reach us. Their plutonium thermoelectric generators should last another decade. What will they find? What will they tell us? No one knows, but I bet they’ll need some changes to their software.
That means that JPL needs a geek to write them. I’m tempted to brush off my rusty FORTRAN and apply. Could I become a steely eyed missile man?
The JPL won’t be getting a new, young guy. “[Voyager] was state of the art in 1975, but that’s basically 40 years old,” said Suzanne Dodd, JPL’s manager of the Voyager program, in an October 2015 online Popular Mechanics article (bit.ly/1Of9FuW). “Although some people can program in assembly language and understand the intricacy of the spacecraft, most younger people can’t or really don’t want to.”
We see the same progression in the Windows world. So many different technologies have blazed like a comet into the sunshine of a Microsoft Professional Developers Conference. Their tails light up the heavens for a few years, then fade as newcomers shoulder them aside. But their durable nuclei persist even as they recede into darkness. (For the ultimate example, see my columns on Visual Basic 6, at msdn.com/magazine/jj133828 and msdn.com/magazine/dn745870.)
Remember how the entire Microsoft world was neck-deep in COM for about 10 years? I wrote four books and many MSDN Magazine and Microsoft Systems Journal articles about it. COM is still used, or perhaps used again, for gluing together some of the internal components of Windows 10. But my .NET students have barely heard of it, let alone programmed it. When I assign them to access a COM server from their .NET program, they click the wizard buttons as the Microsoft documentation instructs them to, but without understanding what the system is doing. They’re helpless when they hit my booby trap: a COM server written in VB6, but without the VB runtime DLL on which it depends. (“Error code 0x80004005 : Operation Failed.”) It takes the starch out of them very quickly, tearing them down so that I can start building them back up in my own geeky image. (Student: “Platt, you’re a sadistic bastard.” Me: “Um, yeah, what’s your point?”)
I am currently consulting on a project requiring an archaeological dig through multiple generations of software: It’s the .NET Framework on the surface, but has a lot of COM underneath, some implemented via the Microsoft Foundation Class Library and some via raw C++ (which isn’t supposed to matter, but does). It has raw Win32 code in certain places. It uses .NET Remoting for communication. Few developers have the breadth of experience to tackle such a project. The pool shrinks every day as older ones retire or die, and the younger ones start with Microsoft Azure and never look back.
I’m starting a company to help clients with this type of project. I’m calling it Graybeard Software, at GrayBeardSoftware.com. (OldFartSoftware.com was taken.) Ping me if you need this kind of help, or if you can help me help others. If I’m not steering Voyager toward the Oort cloud, that is.
David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.