Is it a stretch to say that modern day DevOps folks can learn something from a bygone movement? Absolutely not. Although XP has a bad reputation for some specific reasons, it contains some principles that are of value to us today in 2019.
YAGNI
This acronym stands for "You aren't gonna need it". This is one of the pillars of XP. It makes the assertion that you shouldn't spend time on components or features that you might need down the line. In modern development languages like GoLang, we see the application of this principle is inherit in Go's design. A practical example of this, is Get/Set methods not being idiomatic. For purest Java DEVs, this can be troubling at best. Yet, modern platforms such as Kubernetes and Docker we're written in GoLang. A cursory review of the source-code on Github reveals that the engineers hardly follow a dogmatic OOP standard.
I can't say how many times I've tried to implement code for my systems that "I might need later" only to realize that new technology has lapped us yet again. This can be frustrating, as you never seem to get to the gold-plating stage. If we are able to apply YAGNI, we can save valuable time and effort. But what happens when the time comes to make the changes? Simple, we refactor.
Continuous Refactoring
Refactoring is often neglected in the DevOps realm. This is because that "Ops" portion of your title is always going to be concerned about stability. And lets face, we're feature oriented. At the same time, many engineers fail to understand what "refactoring" truly means:
Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. - Wikipedia
One of the misunderstandings is that "refactoring" gets confused with "gold plating" or new features. Instead, our efforts should be on the following:
- Optimization
- Increased Readability
- Increased Maintainability
- Documentation
Test Drive Development (TDD)
So let me be clear: You cannot continuously refactor without continuous testing. If you change your code often without tests, it will lead to unmanageable code and defects. This can be challenging for engineers who "haven't gotten around to writing tests yet."
TDD ensures that you write your tests, because it requires that you write them first! TDD works like so:
- Write a test for a unit of work
- This test will automatically fail because this code does not yet exist
- Write the code to pass the test
I have found TDD to work well with IaC projects such as Chef, Puppet, Ansible and friends.
TDD is not synonymous with XP, but it was largely embraced by it.
Peer Coding
Ok, this one is very controversial. I've heard many arguments about the practicality of a group of developers attacking a problem all at once. Like all things, you don't have to follow XP to perfection to get some benefit out of peer coding.
Working with distributed teams can be a challenge, but you shouldn't have to wait until you open a PR to have someone else take a look at your code. I have found that 1-2 hours a week can be well spent in an interactive screenshare session. Remember that diversity is great for problem solving. Having more than one mind solving an issue will unlock potential in all involved. In my opinion, the best possible scenario for team building, is team coding!
Final Thoughts
I'm sure there's still folks out there that love XP and use it daily. As a DevOps engineer, I'm fascinated with Dev practices and better understanding the platforms that others have built in the past. I strongly believe that each methodology is built on principles that have their place in the modern world. There is a lot more to XP than I've covered, and I don't claim to be an expert. I just wanted to share what has worked for myself and my team.
Top comments (1)
Nice article Johnny, always happy to see people writing about XP practices!