# For systems, research is development and development is research

DevFeed: [For systems, research is development and development is research](<https://devfeed.tech/articles/for-systems-research-is-development-and-development-is-research-25081.md>)

Original publisher: [Read original article](<https://databasearchitects.blogspot.com/2023/01/for-systems-research-is-development-and.html>)

Author: Viktor Leis (noreply@blogger.com)

Published: 2023-01-23T12:13:00Z

Content type: opinion

Language: en

Sources: [Database Architects](<https://devfeed.tech/sources/database-architects.md>)

Topics: [systems](<https://devfeed.tech/topics/systems.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software](<https://devfeed.tech/topics/software.md>), [DuckDB](<https://devfeed.tech/topics/duckdb.md>)

Tags: [database](<https://devfeed.tech/tags/database.md>), [developers](<https://devfeed.tech/tags/developers.md>), [development](<https://devfeed.tech/tags/development.md>), [duckdb](<https://devfeed.tech/tags/duckdb.md>), [software](<https://devfeed.tech/tags/software.md>), [systems](<https://devfeed.tech/tags/systems.md>), [writing](<https://devfeed.tech/tags/writing.md>)

## AI overview

This opinion argues that systems research and system development are two sides of the same process. Developers should study existing literature, compare approaches experimentally, invent solutions when needed, and write about their work, while researchers should ground new techniques in real systems and practical problems.

## Source excerpt

The Conference on Innovative Data Systems Research (CIDR) 2023 is over, and as usual both the official program and the informal discussions have been great. CIDR encourages innovative, risky, and controversial ideas as well as honest exchanges. One intensely-discussed talk was the keynote by Hannes Mühleisen, who together with Mark Raasveldt is the brain behind DuckDB. In the keynote, Hannes lamented the incentives of systems researchers in academia (e.g., papers over running code). He also criticized the often obscure topics database systems researchers work on while neglecting many practical and pressing problems (e.g., top-k algorithms rather than practically-important issues like strings). Michael Stonebraker has similar thoughts on the database systems community. I share many of these criticisms, but I'm more optimistic regarding what systems research in academia can do, and would therefore like to share my perspective. Software is different: copying it is free, which has two implications: (1) Most systems are somewhat unique -- otherwise one could have used an existing one. (2) The cost of software is dominated by development effort. I argue that, together, these two observations mean that systems research and system development are two sides of the same coin. Because developing complex systems is difficult, reinventing the wheel is not a good idea -- it's much better to stand on the proverbial shoulders of giants. Thus, developers should look at the existing literature to find out what others have done, and should experimentally compare existing approaches. Often there are no good solutions for some problems, requiring new inventions, which need to be written up to communicate them to others. Writing will not just allow communication, it will also improve conceptual clarity and understanding, leading to better software. Of course, all these activities (literature review, experiments, invention, writing) are indistinguishable from systems research. On the othe