Agile Technical Practices
The most difficult step ever is the first step. It comes with doubts, uncertainties, and all sort of fears. If you defy all odds and take it, your confidence will replicate very fast and you'll become a master!
– Israelmore Ayivor
Is This Book for Me?
This book is about technical practices in the context of agile software development. It is aimed at software developers looking to improve their technical practices. Software coaches may also find it helpful as a teaching reference manual.
This is not a beginner's book on how to program. We expect readers to be comfortable with at least one programming language and to be able to write unit tests using any unit testing framework.
Why We Wrote This Book?
The principal driving forces that pushed us to craft this book are the passion for what we do and the wish to provide a straightforward path to other fellow developers. We have been working for the last 20 years in the software world as developers, coaches, and mentors. The content of this book has been distilled over those years of daily practicing, experimenting, and sharing.
We have been teaching and coaching others on this material for years with such amazing results that we felt that writing this book was something we owed to the community. We independently came to the conclusion that the very important matters about software development are the principles driving every line of code, not the technical knowledge of one specific vendor's product or another. Astonishingly, when discussing this, we discovered that we all share the very same principles (with some personal flavors).
We have identified a journey that could take the most diligent readers to mastery in a matter of weeks. If you are prepared to spend some time and effort going through the material, you will improve as a software developer.
We are what we repeatedly do. Hence, excellence is not an act, but a habit.
– Will Durant, paraphrasing Aristotle's Nicomachean Ethics
Why Distilled?
Distillation is the purification or concentration of a substance, obtaining the essence or volatile properties contained in it. It is also the separation of one substance from another. In this book, we will try to do the same, extracting and sharing the essence of all the best practices we have come across in our careers. We are concentrating here on the best of the best of what has worked, enriched by our own principles and values.
We want this book to be a single reference for what we think are the essential practices a developer should master. We have learned our lessons the hard way, but you don't have to. If you learn even one thing from it, you are already a better professional than yesterday. If you are better, the world of software development is better: transcendental Kaizen.
The idea for the book's title arose when the plan was born on a rare snowy night in London. After discussing the idea together over pizza (and a few Peronis), we ordered a couple of rounds of digestive grappa. It was then that we started joking about the title and soon we had fallen in love with it, so here it is!
Caution
In Vicenza (Veneto, Italy), there are several instances per year of addiction to grappa.
What are Agile Technical Practices?
During the last decade, the number of popular technical practices has grown exponentially. So, coming up with a list of core ones can be a daunting task. Every single programmer will have core beliefs, and a consensus can be challenging to achieve. However, the authors feel that among all those techniques there are a number of essential principles to grasp from many of them.
We use the agile term as a wide umbrella covering agile principles and practices as well as most methodologies associated with it. As for technical practices within agile, we will need to explore a bit.
The Agile Manifesto does not mention any technical practices. Scrum And Kanban do not specify any either. Can we use the software craftsmanship manifesto? There are no specific technical practices are discussed there either. What about Extreme Programming (XP)?
XP does have a set of technical practices, namely:
- Feedback:
– Pair programming
– Planning games
– Test-driven development (TDD)
– Whole teams
- Continuous process:
– Continuous integration
– Design improvements/refactoring
– Small releases
- Shared understanding:
– Coding standards
– Collective code ownership
– Simple designs
– System metaphors
- Programmer welfare:
– A sustainable pace
Which of the previously mentioned fundamental technical practices can be trained and studied individually?
In this book, we decided to focus our attention mainly on these four:
- TDD
- Pair programming
- Refactoring
- Simple designs
Now, another question arises: do we really need a core of technical practices in agile? Let's try to answer this with two more questions:
- How often do projects stagnate under their own weight?
- Why does this happen over and over again?
One of the main causes is probably technical debt. This is one of the reasons why technical practices are so crucial to the success of an agile project. They allow us to continue delivering value by addressing the accidental complexity or tech debt as it emerges.
So, is the subset of XP practices (TDD, pair programming, refactoring, and simple design) our core practices? Could these practices help prevent tech debt from accumulating? Simple design and refactoring look promising. Let's label them as technical design practices. What about pair programming and TDD? They belong in a slightly different category. Let's label them as technical feedback practices.
Working with practices related to design and feedback empowers experimentation. Consider a design change: first you get feedback from the pair, then change the design, and get feedback from the tests. Quick, continuous experimentation using feedback loops is how all kinds of systems can evolve and our programs make no exceptions. That's why you should aim to build a structure that gives quick feedback you can trust, so you can try new things without the worry of breaking the existing ones. Remember: "Inertia is your enemy!"
Optimism is an occupational hazard of programming: feedback is the treatment.
– Kent Beck, Extreme Programming Explained
TDD, pair programming, refactoring, and simple design are still reasonably big boxes we must open. So, let's see what we might find inside of each one.
Pair Programming
When we are more granular on pair programming, we find the following concepts and practices:
- Driver-navigator
- Ping-Pong/Popcorn
- Chess clock
- Pomodoro
- Pair rotation
Test-Driven Development TDD
There are two big TDD schools: the Classic/Classicist/Chicago school and the Outside-In/Mockist/London school. Let's add both to the TDD box. Outside-In TDD relies heavily on Mocks and Stubs, referred more generically as test doubles, so let's add test doubles as well. The transformation priority premise is a great way to evolve code without adding complexity too soon, so it can be seen as part of TDD or simple design. We choose to add it to TDD.
We end up with the following technical practices:
- Classic TDD
- Outside-In TDD
- Test doubles
- Transformation Priority Premise
Design Improvements/Refactoring
Doing the same exercise for refactoring, we end up with this:
- IDE productivity
- Refactoring smells
- Refactoring legacy code
- Design patterns
Simple Design
Design is a much more controversial subject, but XP advocates simple design. So, let's stay with high-level, generally accepted design principles and practices, such as:
- Object calisthenics
- Code smells
- The four elements of simple design
- Coupling and cohesion
- Connascence
- SOLID
These are the main technical subjects you will encounter during the journey we have organized for you. If you follow the planned schedule, you should find the learning path quite smooth, always building upon the previous steps. Feel free to wander away from the path and use the book as a quick reference manual for a particular subject.
Beyond Design
All our technical knowledge is not enough if we are not working with the business helping to achieve its goals. The great professional must be able to understand the business and have the principles to make the right choices in terms of understanding and clarifying requirements and being a positive team member. That's why the last section of the book changes the focus from building the thing right to building the right thing. We touch on outside-in development, behavior-driven design principles, domain-driven design, principles derived from lean and system thinking, and our take on working as a member of a team.
We have used some big words in the previous paragraphs. Don't worry if you are unfamiliar with them. That is what this book is for. We hope you find it inspiring – or at least interesting. Explore and enjoy!
