A Retrospective on Tangible Software: 2013-2023

The idea to write a research agenda as a retrospective in the past is stolen from here. This is an awesome technique to engage creative thinking.

The intangible nature of software has seen long been recognized as an impediment to software development, making development an overly abstract and difficult task. This lack of tangibility poses problem for developers to assess, change and communicate about software.

In the past decade, progress on several fronts have made software more tangible, and in turn simpler and changeable.

We review here some of the most successful research directions we explored.
Objects

A software truly exists in a fully tangible manner only at run time. In the case of object-oriented languages, the tangible software consists of objects. By putting objects at the center of the development process, development becomes more intuitive. We have achieved an object-centric programming language and tool chain. The languages features coherent constructs to promote objects, like object literal and object fragments. Modularity is entirely achieved via object nesting. The tool chain contains object-centric debuggers, object-centric profilers, and object-centric version control. For documentation, we have developed dynamic object diagram, an extension of UML that shows how object interacts and how they are organized in the heap at the same time.

Linearity

Software systems are non-linear and developers lack intuition about the system dynamics. A tiny change in input can lead to major changes of the behavior of the system. Understanding how a change in one aspect of the software system affects the overall system is hard. By putting system dynamics at the center of the development process, developers can more easily predict the impact of changes. In our sytem, behavior emerges from asynchronous communication of events between actors, stateful or statelss. An actor is linear if the frequency of events in the input stream is linear with the frequency in the output stream. Grouping events in bulks of fixed size is for instance linear; filtering events on non-unifrom predicates is not. Generating one output event per input event in fixed time is linear, in random time is not. To promote linearity, we promote the decomposition of the system into linear actors. This mere emphasis forces developers to think about and document system dynamics.

Virtuality

A unique feature of digital artifacts, including software, is that they can be copied at no cost. Collaboration happens thus on individual copies that are periodically integrated into a master copy. By putting the concept of a shared, unique, and tangible copy that everybody works on at the center of the development process, the sense of collaboration and awareness is increased. We have created a development environment that recreates the illusion of this shared, unique, and tangible copy without the drawback of the physical world. In this development environment, all changes are instantly broadcasted to all collaborators. The changes are however not necessary activated, making it clear which parts have ongoing modifications or conflicts. The platform successfully blurs the line between code review and version control, and the integration of individual contributions happens as a smooth and organic consensus.

Making software more tangible, more similar to real world mechanical systems, has made reasoning about software easier and thus less buggy.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s