IEEE Software's "Tools of the Trade" with Diomidis Spinellis

Author Diomidis Spinellis provides an audio recording of his On Computing column, in which he discusses how we must be very careful to avoid breaking or degrading the system while working to maintain existing code.

Author Diomidis Spinellis provides an audio recording of his On Computing column, in which he discusses how managing and controlling a service’s provision is tricky, but tools for service orchestration, like Rundeck, can make our lives easier.

This audio recording of the Tools of the Trade column discusses how continuous integration is more than a set of practices, it’s a mindset that has one thing in mind: increasing customer value.

Many affordable cloud-based offerings that cover software development needs, like version control, issue tracking, remote application monitoring, localization, deployment, payment processing, and continuous integration, do away with the setup, maintenance, and user support costs and complexity associated with running such systems in-house. The most important risks of cloud-based tools concern control of the data stored and the services an organization uses. On the other hand, cloud-based tools dramatically lower the capital requirements and setup costs of a software development organization. They also help organizations adopt best practices in each domain simply by registering with the corresponding service. Using a cloud-based service also means fewer worries regarding scalability, while from the customers’ perspective delivering a service through the cloud allows an organization to have a much closer relationship with them. Through cloud-based services the development infrastructure is becoming increasingly homogeneous allowing developers to use the same tools across diverse projects and employers, transferring knowledge and skills from one job to the next, and offering a deeper talent pool of experienced developers.

Infrastructure developed within an organization for its own internal use can take many forms. The obvious reason for creating a bespoke solution is that it can be tailored to fit an organization’s unique needs, which offers many advantages: better performance, increased flexibility, and tactical or strategic advantages over the competition. However, such solutions are associated with a steep learning curve for newcomers, maintenance and support costs, and the risk of hijacking by groups with vested interests. Given that investment in bespoke infrastructures is a sunk cost and that these polarize the types of employees that stay in the organization, rational approaches for building an organization’s infrastructure include customizing a general-purpose solution or adopting an open source tool and improving it to address the organization’s requirements.

The environment in which we work as developers can make a tremendous difference on our productivity and well-being. Yet it's easy to get trapped in an unproductive setup by inertia, and thus suffer death by a thousand cuts. A scorecard we can use to evaluate and fix the environment we work in covers the setup of our workstation and working environment, our ability to access remote hosts, general-purpose tools, editing, debugging, application development, and the specific problem at hand. Some fixes involve tweaks in our setup, and others might require us to install new tools, learn new skills, and negotiate with our managers. They're all worthwhile investments.

Finding yourself in a situation with a working and a buggy system is quite common. Differential debugging methodically can help by comparing a known good system with a buggy one, working toward the problem source. Some simple steps include applying differential debugging by looking at log files and increasing a system’s log verbosity when needed. If the system doesn’t offer a sufficiently detailed logging mechanism, you can tease out its runtime behavior with tools that trace calls to the operating system or that trace network packets. You can also compare carefully the two environments where the systems operate.

Deciding whether to write portable code or not should be the outcome of a cost-benefit analysis. The key reason to favor portable code is that it opens up the selection of resources available to our project. Diverse technology choices free us from vendor lock-in, allowing us to select the best technology in each area based on quality and price, and minimize technology risks. However, portable code can degrade functionality, expressiveness, and efficiency. A middle course involves drawing boundaries around the non-portable code to isolate it from the rest of the application. Another approach is to admit defeat and write code that gives the best native experience. In the long term, separately maintained code bases can be less complex than a unified one.

Systems software is the low-level infrastructure that applications run on. As an applications programmer, first try to find existing systems software rather than writing it from scratch. Once you start writing systems software, use the most efficient algorithms and data structures that gracefully accommodate the workload. Have your code check for all error returns, block when it has nothing to do, and avoid repeatedly processing data in memory. You can accelerate stress testing your software by configuring your testing environment to exercise its edge cases. To debug your software, instrument it with copious amounts of configurable logging.

On 25 October 2012, at ACM's SPLASH conference, six practitioners and academics came together for a panel discussion about "Software Tools Research A Matter of Scale and Scope--or Commoditization?" This episode is a postconference report on the discussions based a transcript of the session.