Article

10 Keys to Successful SW Dev: #10 Tools & Infrastructure

Bernhard Kappe

Published on: May 18th, 2009

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

After last month’s post on the five deadly sins of software development, I thought it would be good to write about how you can overcome those sins (present in every project) to successfully develop software. The list we use internally roughly parallels that of the Standish Chaos reports, and I’ve illustrated it with the patterns we use, as well as some antipatterns we’ve seen and experienced.

#10 on the list is Tools and Infrastructure:

Pattern: We use standard tools for our software development process. For example, every project uses a source code repository, we do continuous integration (hudson) and enforce test coverage as part of every build. Every project uses our wiki for in process definition and documentation. The tools have the benefit of being easy to use, of making communication between team members and clients easy and transparent. They have the benefit of enforcing/reinforcing what we consider important in our method (like test driven development, continuous integration, just in time specification and continuous feedback) and getting out of the way where too much structure is a hindrance.

Similarly, we use standardized stacks for our development, testing and production environments wherever possible. These environments are virtualized, so cloning a new development environment (or adding more production instances) is extremely fast, whether that’s in a data center/dedicated hosting environment or on the cloud.

Antipattern: Tools that don’t get used. Why is the project plan not updated? Why is there no documentation? Often this is because the tools are too cumbersome to use and don’t provide enough value to the team or the stakeholders.

Antipattern: Glass menagerie. A different operating system, database, application stack for every application. We’ve seen it before: Applications written in php, python, erlang, ruby, java and perl, all sitting in the same data center, on ubuntu, red hat, free bsd, with oracle, sybase and mysql databases, and next to sql servers supporting MS Access database applications. I’m glad I don’t work there! Heterogeneity carries a cost – more software to support, patch and troubleshoot, more integrations, more costs. Introduce new things into your production environment when it’s necessary, not when you want to try out some new toys. Try those in a sandbox first.