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.