Everything but the code

Blogger: Joe Niski

The importance of infrastructure is a major theme for Burton Group - the loose definition of "infrastructure" as "everything but business logic" structures our thinking and research.

In my years as a developer and development manager, I came to regard most of the tools I used on a day-to-day basis as infrastructure, just as important as my chair, desk, PC, and telephone. "Everything but the code" became infrastructure. My IDE, the version control system, the build scripts, the bug-tracking system, all the tools involved with the magical evolution of ideas into software. Fortunately, some of my employers understood development tools this way: tools were licensed, installed when I showed up on the job, worked well together - and there was someone responsible for the infrastructure, and somebody I could go to for help and support (whether inside the company or via a support contract). I didn't need to worry about those things; they were part of the environment, and I could largely forget about them and focus on the software project(s) and/or people I was responsible for.

Unfortunately, many of the companies I worked for didn't quite get it: multiple version control systems (or none at all), bug-tracking via post-it notes, requirements management by half-remembered customer conversations - or I couldn't get the budget for reasonable tools and support for my team. Anyone who's worked in more than a few development shops has probably seen all the bad. Sadly, many developers I talk to haven't experienced much of the good.

When I arrived at Burton Group just a year ago, I thought SDLC infrastructure was important enough to write about. (I spent the last quarter expanding on this theme with a collection of Reference Architecture templates due for publication later this year.) Of course, I'm not the first or only person to look at development tools this way - Joel Spolsky touched on these issues years ago in "12 Steps to Better Code" and more recently in "The Development Abstraction Layer." A client I met at Catalyst in July recently started capturing her thoughts on this, coining the term "envirostructure."

The development trade and development tools continue to evolve rapidly - five years ago, few people would have considered a unit testing framework as essential as version control, but that's changed. Everyone agrees on the importance of requirements documentation, but there are so many ways of defining requirements that tools are all over the map. Here's my current list of must- or should-have infrastructure, more or less in order of decreasing importance:

• Some organized and standardized way of documenting, managing, and tracing requirements
• IDEs
• A software configuration management/version control system
• A defect-tracking system
• Unit testing frameworks
• Build automation tools
• Packaging and deployment tools (i.e., release management)
• Whole-system test automation
• Reporting on key development metrics
• Automated code analysis

What's on your list? What did I miss?

Comments

Here are a few additional items from my list...
1)Document management / knowledge management. There is much more than requirements
2) Application mapping - what are all the runtime dependencies for this application - what services consumed?
3) tools to help collaborate with other developers - screen sharing, joint note taking, co-browsign
4) Project tooling - programmers need to use them too. Project planning, time tracking, status reporting.
5) Component/Service/class library to help improve reuse.
6) Code review tooling - tools to help prepare for and follow-up on a code review. code review specific commented, reporting, ranking and tracking. Code reviews doe on paper are often quite lame and useless for a large code base - other than allowing a PM to check off a list item.
7) Governance support - I am using proper licensed and approved components and frameworks?

[joeniski]

Thanks for the comments, these are interesting.

#1: You're right, there's more than requirements involved with most projects - but my view of development infrastructure is focused on the tools and information that are essential (or nearly so) to developers on a day-to-day basis.

#2: This essential information, is often a release engineering function - the external resources for a given application usually vary between development, testing, and production, and often scattered across an app's configuration files, perhaps stored in the SCM system.

3) IDEs are increasingly adding collaboration tools - NetBeans is good at this, and it's addressed in the recent Eclipse Europa release.

4) In my experience, programmers are most concerned with managing their own tasks - sometimes this is driven my the defect management system, sometimes by project management tools. We're seeing more developer- and team-centric portals for task management - Microsoft's Team Foundation server is one of several.

5) A perennial challenge! I've seen a few component repositories with IDE plug-ins, but don't know them intimately. Some tools brand themselves as facilitating "search-driven development", offering the promise of indexing code so developers can search the company repository for what they need before building. Again I'm not familiar with any of them (yet).

6) Many Eclipse-based IDEs, notably IBM's Rational Application Developer, do a reasonable job of this out-of-the-box.

7) License and intellectual-property compliance is one domain for static code analysis tools.