I wanted to pause for a moment in order to reflect on one of the more interesting things I heard from a student last week. I often begin my open source classes by asking students why they are there. What is "open source", I want to know, since most haven't done it before, and I'm curious why they've chosen to learn it. Often I'm told that people want to learn new technology, gain experience, add interesting projects to their resume, etc; all excellent answers.
But this time, one woman put up her hand and said something I don't usually hear: "I want to learn how to maintain software." Amazing. What a thing to be aware of while still in school. My experience is that most students (and professors) haven't had to deal with programs outside the context of an assignment; and assignments are never maintained. Get something working (anything!) and hand it in before the deadline. That's how software's built, right?
Truth be told, a lot of it is. In much the same way that we do when creating our built environment, the demands of software projects require us to borrow heavily, and incur large amounts of technical debt. "If you're not embarrassed by your software, you waited too long to ship." Catching up with that debt, iterating on your product, getting feedback from users, dealing with security issues, adding localization data, updating against shifting APIs, evolving regulation--software is never finished, and software can't possible continue to work without being maintained.
This last point can be hard to understand if you don't work on software. It's not hard to understand why, since we prefer buzzword-compliant and aspirational descriptions of technology to what it's really like. Let's be honest, "smart TV" sounds a lot better in the marketing material than discussing how none of the software will work with existing services, or your new phone, in 3 years. In 2019 all of our devices are now smart in a way they didn't seem to be 20 years ago. Very little changed with regard to how we build software in that same period.
I'm really fed up with the current fetish for INNOVATION, the worship of NEW, and the complete lack of honesty about the future and where this tech will be in 2 years. We've been fooled by a conjurer's trick, and mistaken fast for smart: computers do things quickly, not intelligently. Your computer, and all of its software, are incapable of adjusting to the changing environments in which they are used. What they do, they do quickly. But doing the wrong thing quickly is not smart. Unless you point things in the right direction, moving fast doesn't get you where you need to go. At this point I don't even need to give you examples, every one of us has been burned at some point already.
Keeping software tuned to the current demands of users, and the ecosystems in which it runs, is something we need to talk about more. It doesn't happen by prefixing a product name with SMART. Rather, we have to carefully cajole legacy software into working with new code. It's hard to do well, and it's an ongoing need.
For my students learning open source, there exists an interesting opportunity to get their hands dirty working in new and old code simultaneously. Another of my students this week told me how excited she was to work on the Apache Web Server, because she was so curious how you kept a project going across decades. I understand what she sees here, and it's the same reason I keep coming back to the web and web browsers as my own source of inspiration. Technology that doesn't vanish after being suddenly INNOVATED into existence has the potential to become core infrastructure, and change society. To me, that's really exciting.
Working to maintain software is an incredible way to learn how both the old and the new work. You end up having to understand both worlds, and it makes you a strong developer as a result. "Surely someone has solved this already." They have. "Surely there's a better way than this." There is.
Not all software needs to live forever. There's a lot of code I'm happy to never have to use again. The code that does last does so for reasons worth exploring. Increasingly, that code is also open, and accessible to those who would come and get involved. It has to be, because trying to maintain code for a long time is a team sport. For example, I loved reading this week about the work in the Linux Kernel to prepare for the year-2038 bug.
If you want to learn about how to maintain software, get involved with open source software and learn how they keep the lights on year after year. That's what I'll be doing this term.
On that note, I'm particularly interested in finding good projects for my students to work on that involve helping to maintain vs. create new tech. There's been lots of talk of the need for this recently, and it is only going to increase. I'd love to have better visibility into projects that need help doing this kind of work, beyond the "help needed" and "good first bug" labels everyone uses. If you have a need, and want some people to join you in maintaining something, get in touch. My students are looking for projects.