We can write code in an agile fashion by applying technical practices that provide a quick and short feedback loop on the quality of our code. Technical practices help us to make sure we are building the thing right.
There are many XP (Extreme Programming) practices out there that provide us with many ways of shortening the feedback loop, so we can be sure to build the thing right and of our software's quality, in this article, we will only have a look at a few.
Practices are what we do continuously on a daily basis, not sometimes or often.
Some values added by technical practices:
A smaller feedback loop
A better understanding of requirements and cost
Knowledge sharing (increasing the bus factor)
Reduction of bugs
Quick and totally automated releases to production
Practices
Let's have a look at values a few practices add, if you want to learn all of them and the values they add, I recommend reading the book Extreme Programming Explained: Embrace Change (The XP Series).
Automated Testing
With automated tests, with a click of the button, within minutes we can have our whole system tested. They give us the confidence to deploy our application into production minutes after the last change was made.
This short feedback loop also prevents us from writing more code on top of code that contains errors, hence reducing outstandingly the overall bug-fixing cost.
Test-Driven Development
When test-driving our code, it becomes tough to write complicated code, because we write enough code to satisfy the requirements (represented as tests), and then refactor the code (improve the code without changing its behavior), hence we discourage overengineering and big design upfront (BDUF).
With Test-Driven Development we can quickly get feedback on the design, simplicity, and maintainability of our code.
It provides living and executable documentation for our applications and a suite of regression tests.
Continuous Integration
When multiple developers work on a project, it is important to keep track of where and when something broke, so we can fix it right away before deployment.
Continuous integration shortens this feedback.
Every time a developer's branch gets merged into master, the entire suite of tests is executed and an email is sent to the entire team whenever a test fails in a broken build.
This practice needs to be combined with a “stop and fix” attitude, meaning, members of the team must stop whatever they are doing to fix a broken build, which means the problem introduced by the latest change.
The advantage of following this practice is that the software can always be deployed, it's important that perhaps not all members, but at least multiple are fixing the broken build together, that way it doesn't take longer than necessary for the software to be in a deployable condition.
Pair Programming
With pair programming, right away, you get real-time feedback on the quality of the code.
You get things done more efficiently and with quality, being able to deliver software faster and with quality.
It's also a phenomenal way of knowledge-sharing, hence increasing the bus factor, which is important for the team and company if they want to continuously be able to deliver software fast and with quality.
Refactoring
The Boy Scout rule says:
Always leave the campground cleaner than you found it.
This rule is one software professionals must have when it comes to code.
It shouldn't be applied everywhere though, just when we need to make a change or understand one area of the code.
When software gets messy, it makes developers go slowly, which causes the business to slow down. By continuously refactoring our code, we can go faster for longer, increasing the lifespan of our software.
The book The Software Craftsman:
If this practice is accepted and established from the beginning of the project, developers will never spend too much time refactoring because the code will always be in a good state.
Refactoring is extremely important, we don't want the business to slow down because of us developers, we want to deliver software fast and with quality, satisfying the customers, forever.
Selling the practices
Sometimes it can be hard convincing other developers or managers that we should adopt these practices, hence I took the following excerpt from the book The Software Craftsman:
So, instead of saying to the team that they should do TDD, continuous integration, refactoring, pair programming, and other practices, we should say:
What if we could press a button and be confident, after a few minutes (if not seconds), that our entire application is working? We could reduce QA time from one week to a few minutes. We could even do it multiple times a day. What if we could immediately verify that changes made by different developers are not conflicting with each other or causing a problem in a different part of the application? That could save us a lot of time. How long does it take us to test and deploy our application to production? What if we could reduce that to minutes and do it multiple times a day, whenever a change is made? If a bug is found in production, how quickly can we fix the bug and have a new version of the application deployed? We also have a big gap in skillset within the team. How can we address that? How can we gain understanding of the different parts of the application, including its configuration, deployment, and frameworks? It would be great to reduce the dependency on certain members of the team.
Before talking about adopting practices, we should discuss what we want to achieve.
Conclusion
I love technical practices, but specifically the values they add, that which you achieve by adopting them.
Customer satisfaction and quality software 🚀