Jari Vanhanen

A taxonomy and an initial empirical study of bad smells in code

This paper presents research in progress, as well as tentative findings related to the empirical study of so called bad code smells. We present a taxonomy that categorizes similar bad smells. We believe that taxonomy makes the smells more understandable and recognizes the relationships between smells. Additionally, we present our initial findings from an empirical study of the use of the smells for evaluating code quality in a small Finnish software product company. Our findings indicate that the taxonomy for the smells could help explain the identified correlations between the subjective evaluations of the existence of the smells.

Bad smells - humans as code critics

This work presents the results of an initial empirical study on the subjective evaluation of bad code smells, which identify poor structures in software. Based on a case study in a Finnish software product company, we make two contributions. First, we studied the evaluator effect when subjectively evaluating the existence of smells in code modules. We found that the use of smells for code evaluation purposes is hard due to conflicting perceptions of different evaluators. Second, we applied source code metrics for identifying three smells and compared these results to the subjective evaluations. Surprisingly, the metrics and smell evaluations did not correlate.

Effects of pair programming at the development team level: an experiment

We studied the effects of pair programming in a team context on productivity, defects, design quality, knowledge transfer and enjoyment of work. Randomly formed three pair programming and two solo programming teams performed the same 400-hour fixed-effort project. Pair programming increased the development effort of the first tasks considerably compared to solo programming, but later the differences were small. Due to this learning time the pair programming teams had worse overall project productivity. Task complexity did not affect the effort differences between solo and pair programming. The pair programming teams wrote code with fewer defects, but were less careful in system testing, and therefore delivered systems with more defects. They may have relied too much on the peer review taking place during programming. Knowledge transfer seemed to be higher within the pair programming teams. Finally, we also found weak support for higher enjoyment of work in the pair programming teams.

Experiences of Using Pair Programming in an Agile Project

The interest in pair programming (PP) has increased recently, e.g. by the popularization of agile software development. However, many practicalities of PP are poorly understood. We present experiences of using PP extensively in an industrial project. The fact that the team had a limited number of high-end workstations forced it in a positive way to quick deployment and rigorous use of PP. The developers liked PP and learned it easily. Initially, the pairs were not rotated frequently but adopting daily, random rotation improved the situation. Frequent rotation seemed to improve knowledge transfer. The driver/navigator roles were switched seldom, but still the partners communicated actively. The navigator rarely spotted defects during coding, but the released code contained almost no defects. Test-driven development and design in pairs possibly decreased defects. The developers considered that PP improved quality and knowledge transfer, and was better suited for complex tasks than for easy tasks

Perceived Effects of Pair Programming in an Industrial Context

We studied the perceived effects of pair programming (PP) compared to solo programming in a large scale, industrial software development context. We surveyed developers (N=28) regarding effects of PP on learning, quality, effort, schedule, and human factors. Our findings support earlier results from studies done with students, or professionals doing small tasks. The positive effects of PP were largest for learning, schedule adherence of tasks, getting to know other developers, and team spirit. A small but clearly positive effect was perceived for various quality aspects, discipline in following work practices, and enjoyment of work. The improvement of estimation accuracy was almost negligible. The amount of refactoring did not change. On the negative side, the development effort for individual features was higher. In the beginning of the adoption, the exhaustiveness of work was perceived higher, but over time it decreased to the level of solo programming.

A tentative framework for managing software product development in small companies

Deploying an appropriate software process can improve the effectiveness of software engineering. Still, small companies find it hard to allocate resources to software process improvement and tailor existing process models for their needs. We present a tentative framework for managing software product development in small companies. The framework combines business and process management through four cycles of control: (1) strategic release management provides the interface between business management and product development; (2) release project management handles the development of individual product versions; (3) iteration management deals with the incremental development of product functionality within release projects; and (4) mini-milestones are used to get an indication of system status during development.

Development and evaluation of a lightweight root cause analysis method (ARCA method) – Field studies at four software companies

Abstract in Undetermined Context The key for effective problem prevention is detecting the causes of a problem that has occurred. Root cause analysis (RCA) is a structured investigation of the problem to identify which underlying causes need to be fixed. The RCA method consists of three steps: target problem detection, root cause detection, and corrective action innovation. Its results can help with process improvement. Objective This paper presents a lightweight RCA method, named the ARCA method, and its empirical evaluation. In the ARCA method, the target problem detection is based on a focus group meeting. This is in contrast to prior RCA methods, where the target problem detection is based on problem sampling, requiring heavy startup investments. Method The ARCA method was created with the framework of design science. We evaluated it through field studies at four medium-sized software companies using interviews and query forms to collect feedback from the case attendees. A total of five key representatives of the companies were interviewed, and 30 case participants answered the query forms. The output of the ARCA method was also evaluated by the case attendees, i.e., a total 757 target problem causes and 124 related corrective actions. Results The case attendees considered the ARCA method useful and easy to use, which indicates that it is beneficial for process improvement and problem prevention. In each case, 24–77 target problem root causes were processed and 13–40 corrective actions were developed. The effort of applying the method was 89 man-hours, on average. Conclusion The ARCA method required an acceptable level of effort and resulted in numerous high-quality corrective actions. In contrast to the current company practices, the method is an efficient method to detect new process improvement opportunities and develop new process improvement ideas. Additionally, it is easy to use.

Practical experiences of agility in the telecom industry

This paper discusses the adoption level of and experiences from using agile practices in three software development projects in a large Telecom company. The use of agile practices was more emergent than planned. Project managers and developers simply used practices they considered efficient and natural. The most widely adopted agile practices were to measure progress by working code, to have developers estimate task efforts, to use coding standards, having no continuous overtime, to have the team develop its own processes, to use limited documentation, and to have the team in one physical location. The projects used conventional testing approaches. Adoption of agile testing practices, i.e., test first and automated unit tests, was low. Some agile practices can just emerge without conscious adoption, because developers find them useful. However, it seems that an emergent process aiming for agility may also neglect important agile practices.

Software Deployment Activities and Challenges - A Case Study of Four Software Product Companies

Software deployment, including both clean installs and updates, is a crucial activity for all software vendors. It starts with a customer’s order of a new release and incorporates all steps taken until the customer is satisfied with the deployed product. Using interviews as the main data collection method, we conducted a case study of four companies to discover their software deployment activities and challenges. The studied products were more complicated than pure COTS products. We noticed three product characteristics that make deployment more challenging: 1) the product is tightly integrated to other customer systems, 2) the product offers various configuration options to support different ways of working, and 3) the product requires a pre-created, complex, real-world data model to be usable. We also noticed that software deployment is multifaceted, involving activities related to customer interaction, making integrations, and configuring, installing and testing the products.

ViCA-a WWW based tool for visualizing project status

Easy-to-access and up-to-date project status feedback is an important aspect of effective project management. When project data is collected, a common problem is how to present the data in an understandable form to the right people at the right time. The Visualization Client Applet (ViCA) is a Java-based client program. It is designed for Internet-based visualizations and is currently piloted in several high-tech companies. ViCA can be used even in a geographically distributed multi-project environment. The user is presented with a personalized up-to-date view of the project in which he is involved. The view is a fully configurable panel, which provides fast feedback of the project status. It can contain any number of metrics; each visualized by one or more charts. The user can navigate to a new panel by clicking a part of the chart. This paper discusses the benefits of YiCA, as applied in several product development organizations.