Agile, Scalable, Continuous

A co-worker recently asked me about three similar, but distinct, concepts:

• Agile Development
• Continuous Integration
• Scalable Processes

These are all things that development managers must consider when they are trying to create effective teams, but they are separate and distinct concerns.

I find it easiest to distinguish these by thinking about what problems they solve.

Agile development techniques are concerned with the following problem:

The requirements change while the software is still being developed.

When you start a project, you do the best you can to determine what it is that you want to build, but the world of software is so fast-moving that things are always changing underneath you.

Agile development processes are concerned with ensuring that the tools and techniques and processes that the team uses are able to adapt to frequent, almost constant, change.

A great place to start learning about agile development processes is to read the Principles behind the Agile Manifesto.

Continuous integration techniques are concerned with the following problem:

Misunderstandings aren't discovered until the first time somebody tries to run the entire program as a whole.

A popular technique for working on large projects, with large groups of people, is to subdivide the project into many sub-projects, and each sub-project can then proceed independently, isolated from all the other work.

At the end, all of the sub-projects are combined together, and voila, you have a complete project. This step is called "integration".

This can work, if the sub-division is done by a skilled analyst or architect, and if each independent team builds exactly what the overall designer intended for them to build.

But very commonly, when all the pieces are put together, it doesn't work.

And it is only at this point, only at the end of their project, that the teams find out that they'd had a misunderstanding, and didn't build exactly what the original designer had intended. Unfortunately, at that point, substantial rework is required, the schedule collapses, and there is Much Unhappiness.

Continuous integration is a set of techniques for finding out about these misunderstandings early, as soon as possible, rather than at the end.

Here's the best description of these techniques: Continuous Integration

Scalable development techniques are concerned with the following problem:

Tools and processes that work well for small teams, building small products, for limited sets of deployment environments, don't scale up to large teams, building large products, that have to run on many platforms.

A classic, if 15 years old, description of the sorts of problems that arise when large teams build large projects for many platforms is Mark Lukovsky's presentation at the 2000 Usenix conference: Windows A Software Engineering Odyssey, in which he talks about the issues of scalability faced by the Microsoft development teams during the development of Windows 2000.

All three of these problems are important, and must be kept in mind by team leads, managers, and executives in any situation in which substantial software development occurs (which, nowadays, means almost any modern organization).

There are many specific ways to approach these problems, but one thing I'm pleased about is that the software we build at my day job is valuable in all these scenarios:

• It adapts naturally to change, and can be used in any agile development approach
• It is efficient and reliable, and can handily support the demands of modern build automation and continuous integration toolsets
• It scales well, from a simple near-zero-administration install for very small teams up to extremely high-end data center configurations where tens of thousands of developers must cooperate on a single project.

If you're struggling with software development issues, and your tools aren't helping, drop by our website and download a trial to see how we can help!