Your Code Will Be Dead in Ten Years
But Your Ideas (Hopefully) Won’t Be
I make a bet with every new Ph.D. student who joins my lab that none of the carefully crafted code they write during their time as a student will matter in a decade. The frameworks will vanish. The APIs will be deprecated. Even the programming language might become irrelevant. Some students take this badly. They’ve spent years honing their coding skills, building systems, and learning to architect elegant solutions. Surely that matters?
It does, but just not in the way they think.
Much of computer science, particularly in technical HCI and visualization research, is fundamentally engineering research. We build things. We implement prototypes. We write code, sometimes thousands of lines, to bring our ideas to life. This implementation work is real, substantial, and time-consuming. But here’s the misconception that trips up almost every student in the beginning: they conflate their research contribution with their software implementation. These are not the same thing. Your implementation is a validation mechanism, not the contribution itself.
Think about it through the lens of the scientific method. When you propose a hypothesis, you need to validate it. In engineering research, if you claim your new interaction technique is faster or your novel visualization is more accurate, you prove this through validation. Sometimes that’s an empirical user study with participants. Sometimes it is a deployment in the field. Sometimes it’s formative interviews. But don’t forget that the implementation itself is also validation: it proves your idea can actually be realized in working code. This is why video figures in HCI and visualization papers matter so much. They provide tangible proof that a prototype exists and works. And yes, sometimes you need the implementation in order to conduct other types of validations.
Consider the canonical visualization paper: proposing a new technique for a specific data type. A student might spend months building an elegant implementation: carefully architecting the rendering pipeline, optimizing performance, and crafting smooth interactions. That engineering work is impressive. In fact, good implementations can sometimes be the difference between acceptance and rejection. But when the student writes the paper, they often make a critical error: they describe the technique and implementation as one inseparable thing. This is a mistake.
The technique — the abstract idea, the design principles, the theoretical framework — should stand alone. Readers should be able to understand your contribution without wading through implementation details about rendering engines or interaction handlers. Yes, some implementation aspects might be essential to making the idea work elegantly. Mention those in your implementation section. But never lose sight of the fact that the implementation is validation, not the core contribution.
This separation helps everyone. Readers can evaluate your idea on its merits without parsing boilerplate descriptions of UI components and algorithms. Other researchers can reimagine your technique in their own contexts more easily. If someone wants your actual code, a GitHub repository serves them better than a dense implementation section ever could.
Unless you build the next D3, Vega-Lite, or reVISit (or Webstrates, DashSpace, and Spatialstrates, to discuss systems closer to home) — systems that define how communities work for years — nobody will care about your specific implementation. This isn’t cynical; it’s realistic. Systems papers face an uphill battle at top conferences. Reviewers routinely undervalue the engineering effort they represent. This doesn’t mean we shouldn’t write systems papers when the system truly is the contribution. It just means most HCI and visualization work contributes a bright new idea, not its particular implementation. The implementation is merely the vehicle for validating that idea.
So when you sit down to write your paper, ask yourself: what’s the contribution here? Is it a novel technique, a new framework for thinking about a problem, or a theoretical insight? If so, describe it abstractly first. Then show you implemented it. Show it works. Show it’s practical. But don’t let implementation details obscure the idea that will outlive your codebase.
Because ten years from now, your code will be dead. But if your idea is good enough, someone will have reimplemented it in whatever platform comes next. That’s when you’ll know your contribution actually mattered.
