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?
