Agile is technology agnostic
Have you wondered what type of languages or technologies you should use when doing Agile software development? This article will help clear that up. The answer is a lot simpler than you might think! It turns out that in fact, agile is technology agnostic.
What language / design approach is best for agile?
I’ve seen some people ask questions like “what language should we use if we’re doing Agile on this project?” Or “should we take an Object Oriented approach or Functional Programming approach if we want to do Agile?”. These might sound interesting but they are actually are not the right sort of questions to be asking.
Agile software development is technology agnostic about specific languages (e.g. Java or Python or Node or C++ or whatever), and it is also agnostic about technology approaches (Object oriented, functional programming, imperative programming, etc). It is not that the people who wrote the manifesto didn’t have opinions on those things, they certainly do (I have done training with Alistair Cockburn, one of the signatories of the Agile Manifesto, and I can tell you he is very passionate and opinionated about object oriented programming).
It’s just that those weren’t the problems they were trying to solve. They weren’t trying to solve object oriented versus functional programming, or component systems versus APIs. They were trying to answer the question: no matter what language or design we are using, what is the best way of breaking down and dividing up the work? And of inspecting and modifying that work? Now, you’re probably wondering about technical practices…
But what about technical practices?
That is a completely different issue. There are technical practices (not technologies) that are related to agile software development. It is difficult if not impossible to be Agile (not just “do agile”) without them. While there are many different opinions in this area, there is general agreement that you need to be doing at the very least:
- Continuous Integration i.e. developers merge changes into trunk / main at least once per day
- Solid unit test coverage
- Some level of automated integration / acceptance tests.
The more technical purist approaches to Agile, such as Extreme Programming, say you should go futher, and be doing:
- Pair Programming
- Test-driven development (TDD)
- Continuous Delivery.
These are software development practices though, not programming languages or styles. There’s an important difference.
But what about tools?
Some people also ask what specific tools you need to be using to do agile. This is wrong, wrong, wrong. Remember the Agile Manifesto? In one of the fundamental four principles, it says:
“We have come to value individuals and interactions over processes and tools“.
Now that doesn’t mean that you shouldn’t have a process and you shouldn’t use tools. But the point is, don’t get too hung up on it. Don’t let the process and tool define how you work! Find a good, agile way of working, that respects people and frees up communication channels, and then find a process and tool that works well that way of working. Instead of the other way around.
But what about architectural patterns?
Some of you might be wondering about architectural patterns: component architectures, service oriented architectures, APIs, microservices, and so on. Do you need to be doing those to be “agile”? This is a more complex and controversial point.
As a short answer, I believe no. You should be able to build any system in any way you want. Agile is a way of breaking up, assigning and inspecting work, not a system of how to glue technology components together.
Some might say though that a truly agile system will be changing often and will thus only work with an architecture that can accomodate a high rate of change. And that requires some level of abstraction and isolation, and that means at the very least SOA, if not Microservices. A traditional monolithic app structure will be brittle, take a long time to build, require heavy regression testing, and not fit in well with agile software development practices.
I think there are some merits to that argument.
However, keep in mind:
- people were doing agile software development before service oriented architectures came along, and definitely long before microservices came along
- agile isn’t as much about frequent changes as you think (although they should have frequent commits / merges because the work should be broken up into small batch size as per Lean Manufacturing principles).
Anyway this is getting off topic and is a story for another day! Please let me know if you disagree or have questions in the comments.
