Tools of the Trade Icon

Welcome to Tools of the Trade

This podcast of an ongoing IEEE Software column explores the interplay between you, the software practitioner, and the tools you apply to the development problems you face. Skilled craftsmen set themselves apart from amateurs by the tools they use and the way they employ them. As a professional, I feel I'm getting a tremendous boost in my productivity by appropriately applying tools to the software construction problems I face every day. I also often find myself developing new tools, both for my personal use and for wider distribution. Column installments will discuss specific software construction activities from the standpoint of the tools we can employ — the tools of our trade. Future topics include editing, compiling, documentation, debugging, testing, configuration management, issue tracking, the development environment, tool building, and domain-specific tools. Of course, your suggestions are always welcome; email me at Diomidis Spinellis

This podcast is brought to you by IEEE Software.

Subscribe iTunes | Google | RSS

Bespoke Infrastructures

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 Frictionless Development Environment Scorecard

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.


Differential Debugging

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.


Portability: Goodies vs. the Hair Shirt

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.


Showing 5 - 8 of 25 results.
Items per Page 4
of 7

About the Speaker

Diomidis SpinellisDiomidis Spinellis is a professor in the Department of Management Science and Technology at the Athens University of Economics and Business and the author of Code Quality: The Open Source Perspective (Addison-Wesley, 2006). Contact him at