[1/2] Extreme programming: setting the process (Extreme Programming Applied: Playing to Win) (Category Engineering)

This post ends with a review of a book from the early 2000s that I started with in the previous one. post. Here I planned to talk about the six remaining practices of the second stage, as well as provide materials for further study. Let's go.

1. Simple design. (Simple Design) The point here is not to make a large architecture before the start of the project, but to design as new information and requirements become available. It sounds good, but for inexperienced guys it turns into a big ball of mud. As a result, there are still questions about how to properly design complex systems.
2. Collective code ownership (Collective code ownership) Collective code ownership within teams is a de facto standard, but contributing to the code of neighboring teams is still not so trivial - there is such a direction as innersourcing, which is mentioned if you want to reduce expectations and dependence on other teams. The main thing is not to wait for the neighboring team, but to send them code and pour through the procedure of merge request. There are a number of organizational and technical problems along the way, but bigtech companies somehow cope with them:)
3. Acceptance tests (Acceptance tessting) - the essence is to fix the expectations of the customer and write acceptance tests, which act as a fixation of the criteria for accepting tasks from the customer. Now this approach has slightly expanded to the criteria of readiness for tasks. (definition of done)which must be performed before the backlog element (user history) will be considered complete.
4. Coding standards (Coding standards) The authors talked about coding standards, which are now being automated at the linters level. But if we go a little further, standards also help with the use of shared libraries or standardization of API design approaches.
5. System metaphor (metaphor) An interesting concept about the use of metaphors within the system and a common language for communication between tech and business customers. Years later 5 After the release of this book, the book "Domain-Driven Design: Tackling Complexity in the Heart of Software" was published, in which Eric Evans introduced the concept of DDD and introduced the term "DDD". ubiquitous language
6. Forty-hour working week (40-hour week) Here the authors talk about the lack of overwork and normal work/life balance. Interestingly, even then, this topic was important and included in the set of principles.

Separately, the book talks a lot about how to sell XP to managers and developers, as well as how to implement these practices gradually and fight resistance. As a result, the book is no longer particularly relevant technically, but the concepts themselves have been adopted by the industry.

P.S. If you like this review, I recommend reading the books.

• Modern software engineering This is a recent book by Dave Farley that I'm talking about. already written. In this book, Dave talks about similar practices, but in an appendix to the current level of the industry.
• Accelerate - It's a book. 2017 Nicole Forsgreen, Jez Humble and Gene Kim already written. In this book, the authors describe the results of DevOps Reports. 5 It shows how engineering practices help businesses move faster.
• Tidy First?: A Personal Exercise in Empirical Software Design (Clean design. Practice of empirical software design) A recent book by Kent Beck, creator of eXtreme Programming. I already told you.. In this book, Kent elaborates on Simple Design:)
• A philosophy of software design John Osterhuth, creator of the Raft consensus algorithm I already told you.. In this book, John reveals his approach to software design and the importance of engineering practices.

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE