Communicating bugs: global bug knowledge distribution

https://doi.org/10.1016/j.infsof.2004.09.009Get rights and content

Abstract

Unfortunately, software-component libraries shared on a global scale contain bugs. Members of the library user community often report bugs, workarounds, and fixes. This bug knowledge, however, generally remain undiscovered on library web site or in open bug databases.

In this article I describe design criteria for bug handing from a global user community perspective. I also describe a distribution architecture for bug knowledge. The architecture focuses on bug awareness and bug visibility in the standard work environment.

Introduction

Global sharing of software-component libraries is currently the model of the distribution for software components in object-oriented programming. As an example, Java has become a language that excels in global sharing [3], [12], [26]. Java application programming interfaces (APIs) or Java libraries are easily shared: constituting one of the most relevant features of the language. Most programming languages more or less share this library feature.

Bugs are likely to appear in libraries like any software application. Perhaps bugs are an unavoidable property of the complexity of software; a complexity Brooks calls essential [2]. McLellan et al. discusses how usability testing can lead to the design of usable libraries [8]. However, there are other simpler reasons for bugs in libraries. For instance, libraries are sometimes released early. The library may be released as a form of communication of intent and direction of development. In these cases bugs are likely to exist to a higher degree than if libraries where fully developed and well tested.

Besides the fact that bugs exist, the lack of knowledge about bugs can be a major obstacle in development. This is a communications problem, the analysis of which Rosson argues is key to the understanding of how to better support software development [11]. Because bugs are unexpected, difficult to discover, time-consuming, and unpredictable it is vital to share the knowledge throughout the user community. In this respect, the user community as a whole can benefit from the knowledge of individual members. Fig. 1 illustrates the change from collecting reports, to publicly opening bug databases, to the proposed future of sharing actively bug knowledge as proposed in this article. Bugs also represent relevant technical information that evolves during the lifetime of the library. Distributing information about bugs is important in reducing overhead and to support knowledge awareness. Confidence in the development organization can be achieved by the efficient distribution of bug knowledge. Knowing that the library will reflect discovered bugs may increases the programmers' belief that they can fully utilize the library (even though this may include working around or disregarding missing functionality). Furthermore, members of the user community often generate bug knowledge. To respect the community's effort in development, the development organization should not only fix bugs but also efficiently distribute bug knowledge.

Today, bug reports and reports on workarounds end up in web sites, mailing lists, or special purpose bug tracking tools but not in the standard work environment. Programmers must on their own initiative search for information about known bugs by continuously spending time reading sources of information outside their normal work environment. However, professionals want to focus on the task at hand and search only for relevant information [4], [6]. The programmer is likely to work mainly with their development environment and library reference documentation (often still through a local copy). This standard work environment acts as the programmer's work interface. The environment also constitutes the programmer's knowledge in the world, [9]. Therefore, as bugs are detected, workarounds constructed, and fixes released, bug knowledge should surface in this standard work environment.

In this article I analyze bug handling in relation to library users and describe design criteria from an efficient knowledge communication and distribution perspective. Furthermore, I describe an architecture for the distribution of library bug knowledge on a global scale. The architecture focuses on precision in delivering the right bug knowledge at the right time and on sharing bug knowledge within a library community rather than collecting bug knowledge from library users to the core-development team. Generalizing, the article addresses efficiency in library-based programming and in technical communication within global communities.

The documentation provided with a library is the source of information programmers have about the library, either because the source code is not distributed or because it is too detailed to be of practical use. There are two types of library-related documentation: reference and tutorial. Reference documentation provides detailed listings of component specifications. Tutorial documentation, on the other hand, provides general descriptions. I distinguish between reference and tutorial documentation through their roles in work. Where as reference documentation is used continuously and covers the details of the library, tutorial information is used in the early stages of development and covers the basic and/or the general overview. Reference documentation is, in my view, part of the standard work environment. Java library reference documentation, for instance, is often distributed in Javadoc form [5], [7], [27].

I believe that it is limiting to differentiate between documentation and development environment. Reference-type information distribution can be performed in many ways. One common example is code-completion functionality in source-code editors, available for instance in Forte4J [23]. Code-completion provides alternative completions on text written in the editor which enable the programmer to choose rather than type. When used in relation to components, code-completion functionality also becomes a highly compact and highly relevant form of reference documentation.

In essence, reference documentation should be regarded as the information-processing tools through which users access library functionality, including textual listings and editor functionality such as code-completion. The main point of reference documentation is that it serves as a source of information and a memory for the programmer in relation to libraries. Reference documentation acts as the programmer's knowledge in the world [9]. The view of documentation a central programming tool is perhaps still somewhat controversial. Reiss, for instance, does not even mention documentation in his article Software Tools and Environments [10]. However, I believe that global sharing of libraries changes development fundamentally, making reading an important aspect of coding and documentation equally important to editors and compilers.

Application programming interfaces (APIs) are sets of protocols, routines, and programming tools for building software applications, though commonly non-graphical tools. In the Java domain, API is a common name for what in other languages are sometimes known as modules or libraries. In this article I use the term software component libraries or simply libraries for APIs. In Java, libraries are bundled Java classes and work as a distribution form for frameworks, platforms, or general utility classes. New applications or libraries are constructed with libraries as a base. Though other programming languages have had library constructs before Java, few languages have been so integrated with the library concept. Since its first public release in 1995 Java development has, in practice, been equivalent to development based on the Java standard development kit (SDK, originally called the Java development kit or JDK). The java.lang library, which is loaded by default by the compiler, contains the basic Object class that all Java classes inherit from. Other languages develop in the same direction and distribute libraries as a model for component sharing [31], [32].

Libraries, in a sense, change development from a writing activity to a reading-writing activity. Because libraries grow large and change rapidly compared to programming languages, developers cannot be expected to remember the all the technical details. The Java SDK is an example of this development. Table 1 shows the development of the Java SDK during its lifetime and the rapid growth of SDK. Having in depth knowledge about over 3,000 classes is virtually impossible.

For the development of electronic reference documentation, the standard web infrastructure can be a limiting factor. Web browsers, such as Microsoft Internet Explorer [25] and Netscape Navigator [30] and web servers such as Apache [13] define socio-technical standards that web applications must adhere to. What is most relevant are client side standards, currently languages like HTML and XML (and related style sheet languages such as CSS and XSL) [42]. On the server side, technology is easier to exchange or extend as long as the output adheres to client-side standards.

For the development of bug-knowledge distribution and integration of evolving content there is limited support within the standard web infrastructure. HTML and XML are strict document languages that do not reflect global structures or directly support evolving content. Web browsers also generally have very limited client-side memory at its disposal. Furthermore, there is often a domain-related security barrier in place that disables the mix of content from multiple sources. (However, it is possible to develop dynamic client-side content generation using some tricky programming but it is not well supported.) On the server side, dynamic generation of content is supported in relation to the integration of databases and mix of multiple files. However, these techniques are highly general and not designed specifically for the evolution of documentation or the programming domain.

Section snippets

Understanding bugs

Bugs must be understood from the users perspective to develop systems that efficiently distribute bug knowledge to users. Let us take a look at what bugs are in this context and how we should define it to server the purpose of overcoming the bugs that do appear in the library source code.

Understanding bug handling

Another way of understanding the needs for bug handling systems is to look at what knowledge is currently being collected during bug handling. Therefore, I have examined the knowledge collected in relation to bug reports today.

Efficient distribution architecture

Delivering the right bug knowledge at the right time is the solution to the problem discussed in this article. This timing is crucial to the successful dissemination of knowledge in a software library community, perhaps more so than other types of knowledge due to the unexpected nature of bugs. Let us summarize design criteria on bug-handling systems from the knowledge distribution perspective:

Bug knowledge should be self-distributing. As soon as bugs are detected, every member of the library

Discussion

In this Section 1 will discuss issues not directly addressed within the distribution architecture and also extend the scope beyond the bug domain.

Conclusions

In this article I examine current distribution of bug knowledge in relation to global sharing of software-component libraries. From my study of contemporary bug-handling systems, I find that library users must search for bug knowledge on their own initiative. The article proposes a different view on bugs, focused on library-user perspective (rather than a development-organization perspective) and argue that efficient distribution of bug knowledge requires the opposite communication direction

Acknowledgements

Henrik Eriksson and Magnus Bång deserve appreciation for discussing the article and Ivan Rankin for proofreading the article. The ECSEL graduate school supported this work.

References (43)

  • The Academic Press Dictionary of Science and Technology, (1992) Academic Press, San Diego...
  • F.P. Brooks

    No Silver Bullet: Essence and Accidents of Software Engineering

    IEEE Computer

    (1987)
  • M. Campione et al.

    The Java Tutorial: Object-oriented programming for the Internet

    (1998)
  • J.M. Carroll (Ed.) (1998) Minimalism Beyond the Nurnberg Funnel MIT Press 1998, Cambridge,...
  • L. Friendly (1995) The design of distributed hyperlinked programming documentation, in proceedings of the 1995...
  • J.A. Hackos (1998) Choosing a minimalist approach for expert users in Beyond the Nurnberg Funnel, John M. Carroll...
  • D. Kramer. (1999) API Documentation for Source Code Comments: A Case Study of Javadoc, In Proceedings of the...
  • S.G. McLellan et al.

    Building More Usable Libraries

    IEEE Software

    (1998)
  • D.A. Norman

    The Design of Everyday Things Basic Books

    (1988)
  • S.P. Reiss

    Software Tools and Environments

    ACM Computing Surveys

    (1996)
  • M.B. Rosson

    Human Factors in Programming and Software Development

    ACM Computing Surveys

    (1996)
  • P. Tyma

    Why are we using Java Again?

    Communications of the ACM

    (1998)
  • Apache website:...
  • BugBase website:...
  • BugCentral website:...
  • BugTalker website:...
  • Bugzilla website:...
  • Debian bug website...
  • DevTrack website:...
  • Devx website:...
  • Elementool website:...
  • Cited by (1)

    View full text