It Will Never Work in Theory

Software development research that is relevant in practice

Browsing Posts published by Leif Singer

Chris Parnin, Spencer Rugaber. Programmer Information Needs After Memory Failure“. ICPC 2012.

Despite its vast capacity and associative powers, the human brain does not deal well with interruptions. Particularly in situations where information density is high, such as during a programming task, recovering from an interruption requires extensive time and effort. Although modern program development environments have begun to recognize this problem, none of these tools take into account the brain’s structure and limitations. In this paper, we present a conceptual framework for understanding human memory organization and its strengths and weaknesses, particularly with respect to dealing with work interruptions. The framework explains empirical results obtained from experiments in which programmers were interrupted. The intent is to use the framework to design development tools capable of compensating for human memory limitations. We also delineate programmer information needs such tools must satisfy and suggest several memory aids such tools could provide.

Parnin and Rugaber discuss several cognitive challenges that probably every developer has faced at some point: tracking many code locations at once while doing a big refactoring, or trying to remind ourselves to continue work on a certain problem when an external event has occurred. For these challenges, they give examples for coping strategies that, again, probably every programmer has used one time or the other. We send reminder e-mails to ourselves, add // TODO comments that we forget about later, or deliberately create compiler errors as an anchor into our current task.

The authors analyze and classify these challenges and coping strategies using existing research from neuroscience. The result is a theoretical framework that is mostly interesting to researchers and a few practitioners who wish to create better developer tools. Wearing my researcher hat, I cannot help but to instantly try thinking of neat ways to leverage this framework as a designing aid for developer support mechanisms.

However, when I put on my developer hat, I realize that it’s even more than that. Parnin’s and Rugaber’s framework helps me reflect upon my own programming habits and provides some explanations for their existence. For example, why is it that so many TODOs remain in code for so long, never to be DONE? They are passive reminders that are never triggered!

Even without the tool support that Parnin and Rugaber are creating, their paper provides an interesting look at ourselves as developers, our habits, our weaknesses, and our coping strategies. In doing so, it raises our awareness for these issues and inspires us to slight modifications of our work practices that are better tailored to our human brains. The next time I write a TODO, I’ll make sure to create an automatic reminder as well.

Felienne Hermans, Martin Pinzger, and Arie van Deursen. “Supporting Professional Spreadsheet Users by Generating Leveled Dataflow Diagrams”, ICSE 2011.

Thanks to their flexibility and intuitive programming model, spreadsheets are widely used in industry, often for business- critical applications. Similar to software developers, pro- fessional spreadsheet users demand support for maintaining and transferring their spreadsheets.

In this paper, we first study the problems and information needs of professional spreadsheet users by means of a survey conducted at a large financial company. Based on these needs, we then present an approach that extracts this information from spreadsheets and presents it in a compact and easy to understand way, using leveled dataflow diagrams. Our approach comes with three different views on the dataflow and allows the user to analyze the dataflow diagrams in a top-down fashion also using slicing techniques.

To evaluate the usefulness of the proposed approach, we conducted a series of interviews as well as nine case studies in an industrial setting. The results of the evaluation clearly indicate the demand for and usefulness of our approach in ease the understanding of spreadsheets.

Many professional software developers might cringe when thinking about spreadsheets, or simply not take them seriously because they’re not “real programming”. They are, however, a fact of business and often get the job done. While they can be developed much faster, they also bear a great potential for errors. Felienne and her co-authors embraced this reality and decided to do something about it — using approaches from software engineering.

Ignoring any assumptions regarding the problems of spreadsheet users, they used Grounded Theory in an industry setting to find out which problems really existed in business. One thing they found was that existing spreadsheets often need to be understood by new users. Diving deeper, they found that the comprehensibility of such inherited spreadsheets was often seriously lacking — posing a great risk from a business perspective.

The authors then developed a tool to help with this issue. It creates dataflow diagrams that make dependencies in spreadsheet formulas visible. An evaluation with business users showed that these diagrams are indeed comprehensible and useful — that is, they help end-users in understanding unfamiliar spreadsheets. Another interesting finding was that the creators of — in their view — simple spreadsheets only realized the actual complexity of their own creations after having used the tool.

The best part is: Felienne, Martin, and Arie demonstrated the practical relevance again by launching a successful startup based on this research! The company is now part of the Dutch startup incubator “YesDelft”, has partnerships with several IT service companies, and has paying customers. How’s that for practical relevance of research?

Ohad Barzilay. “Example Embedding”Onward! 2011. 

Using code examples in professional software development is like teenage sex. Those who say they do it all the time are probably lying. Although it is natural, those who do it feel guilty. Finally, once they start doing it, they are often not too concerned with safety, they discover that it is going to take a while to get really good at it, and they realize they will have to come up with a bunch of new ways of doing it before they really figure it all out.

After we had an interesting discussion with input from industry a few weeks ago with the paper “Component reuse vs. snippet remixing”, I want to follow-up in that direction with another perspective. Apart from the hilarious abstract, it is a paper that reads well and entertains. In addition, it sheds some light onto a common, yet shunned practice.

From time to time, developers use example code from the Web in their own code. In his essay, Barzilay lays the foundation for talking about this phenomenon and identifies the elements of that ecosystem. For example, he mentions what kinds of sites are used by developers and what the process of reusing an example can look like. Addressing concerns from the Component reuse vs. snippet remixing paper, he discusses potential solutions for making the practice safer and more systematic. Finally, as an interesting analogy, Barzilay contrasts example embedding with academic practices.

While the use of examples from the Web may be looked down upon by several developers, it is a pervasive practice. Yet, neither industry nor research provide comprehensive support for making it safer. Barzilay’s essay helps us understand what the example ecosystem looks like and gives us ideas for possible solutions of its problems.

Finally: thanks to Jorge, Neil, and Greg for having me here at NWIT!