Ian Dees, Tektronix
We join software projects with grand ideas of tools, techniques and processes we’d like to try. But we don’t write code in a vacuum. Except on the rare occasions when we’re starting from scratch, we’re confronted with legacy code whose history we may not know and team members who have been quite productive for years without the silver bullets we’re pushing. How do we get a toehold on a mountain of untested code? How can we get our software to succeed despite itself? Sometimes, we have to get our hands dirty. We may have to break code to fix it again. We may have to put ungainly scaffolding in place to hold the structure together long enough to finish construction. We may have to look to seemingly unrelated languages and communities for inspiration. This paper is a discussion of counterintuitive actions that can help improve software quality. We’ll begin with source code, zoom out to project organization and finally, consider our roles as individual software developers.
Ian Dees, 2011 Poster Paper, Abstract
