Enough with “agile” already! It’s been 10 years since the Agile Manifesto, and the conclusion is inescapable: Agile methodologies are a key part of the foundational software development universe. As the Artful Dodger sings in “Oliver!”

Consider yourself at home, consider yourself one of the family. We’ve taken to you so strong, it’s clear we’re going to get along.

After a decade, we at SD Times are going to try hard to stop distinguishing between agile software development and non-agile software development. While we might talk about specific methodologies from time to time; Scrum, let’s say, or XP, or Test-Driven Development, or the oft-derided Waterfall—it’s all software development now.

That’s how things work in our industry. New concepts come in, are explored and adopted, and then become part of the furniture. Remember back when most developers worked with structured programming in languages like C, Fortran, Pascal, COBOL and PL/I? In our conversations and writing, many of us differentiated that new-fangled object-oriented programming and design stuff for years… And then, after a while, OOP languages and methodologies became standard. That’s not to say that all development is OOP—there’s still plenty of C going on—but for all intents and purposes, we don’t need to call it out for special mention.

We believe that the broad acceptance of agile software development, and its validation broadly throughout our industry, says that agile is mainstream. That’s not to say that we’re not going to use the “A-word” ever again, but rather we’re going to change how we talk about it. Our intent is to stop treating agile development as something new, unusual, niche or experimental. Will a decade’s worth of habits be hard to break? Certainly. But that’s where we’re going—along with the rest of the industry.

With Hudson and Jenkins, forks are good
One of the strengths of the open-source software model is that (licenses permitting) if one party doesn’t like how a project is going, it can fork the project and take it in another direction. If the fork results in new vibrancy or opens up the project to new users, the fork is good. If the fork, however, merely results in confusion and incompatibility, and divides scarce resources, then the fork is bad.

In the case of the Hudson/Jenkins kerfuffle, our perspective is that Oracle’s fork is good.

SD Times serves enterprise software development. To build business software, you need strong tools that combine features with quality, robustness with predictability, and support with innovation. If you’re going to adopt a tool as a standard within your organization, and invest in training and integration, you need to believe that the tool’s going to be there for you, and that its developers are taking your needs into consideration as the tool continues to evolve.

That’s a contrast, of course, from the enthusiast community, where innovation often begins. There is a creative tension between the innovators on the bleeding edge and the corporate organizations standing farther back, on safe ground. Or, in this case, from Hudson’s creator, Kohsuke Kawaguchi, who has one vision of the project, and from Oracle, which serves a business audience that demands stable software released on a regular schedule with specific guarantees and documentation.

The Hudson continuous integration server is incredibly popular, and many Oracle customers use the software for their business-critical projects. Those customers can’t deal with weekly, undocumented updates and unpredictable shifts in code hosting. Thus the fork, where Oracle takes over Hudson and Kawaguchi moves into Jenkins. This can only mean good things for Java shops: The cutting edge will continue to slice with Jenkins, while Hudson will chug along at a respectable, predictable enterprise pace.