Kent Beck

Na 1a edição fica mais evidente a quebra de paradigma proposta pelo XP e pelos métodos ágeis em geral. O livro é ao mesmo tempo provocativo e cativante. Beck explica claramente a motivação e as ideias básicas por trás do XP, o que ajuda o leitor entender e acreditar na solução proposta. Por outro lado, a 2a edição é um livro muito mais pragmático, sem tanta provocação. Nela, o método é explicado em maiores detalhes, discutindo melhor a sua aplicação prática. Essa show more mudança é natural ao considerar o contexto das duas edições: na 1a, de 1999, o livro é praticamente um manifesto - a proposta de um método diferente do que estava sendo usado na época -; na 2a, de 2004, o XP já era um método popular e que, portanto, precisava de um "manual" mais detalhado para ser aplicado.

Uma diferença importante entre as edições é o conjunto de práticas propostas. É comum encontrar referências às práticas do XP1 (1a edição) e do XP2 (2a edição). É curioso notar que outros autores/metodologistas propõem práticas diferentes. Isso mostra que o XP é, acima de tudo, uma ideia. Por isso eu prefiro a 1a edição - ela representa melhor a ideia!

Como conclusão, a escolha de qual edição ler depende do seu objetivo. Se você ainda não conhece o XP e quer entendê-lo, recomendo a 1a edição. Se você já sabe o que é o XP e quer saber mais detalhes e, principalmente, como aplicá-lo, recomendo a 2a edição. show less

This book helped change the way that software development is generally practiced, from the leadership to the programmers, from the business to the design. It is important to note that this book has been delivered in two very different editions. The first edition in 1999 set the direction while the second edition in 2005 brought insight out of several years of experience in an updated text.

What’s so “extreme” about Extreme Programming? First, it advocates a practice called “pair show more programming” – programming in teams of two and sharing the burden of writing and debugging the code. Second, it advocates a heavy use of automated testing and writing those tests at the beginning of a new feature, not at the end. It also advocates the practice of continual integration – making many small deployments instead of one big deployment. This practice, 15 years after publication, is adhered to in most development shops.

What I like most about this book is that it flattens the landscape. Instead of having hierarchies and bureaucracies, it brings responsibility to everyone on the team. This is especially true in my industry, medical research. It’s in touch with the evolving dynamics of the workplace. Careers should not be a race to the top but a continual development of skill. Lean production techniques, concepts of continual improvement, and shared responsibility are all consulted in suggesting how to handle the business of software. The purported results are substantially reduced software defects (i.e., improved quality) and slightly reduced development time (i.e., reduced cost).

While these ideas were cutting-edge in 1999 (and still not widely practiced in 2005), they are expected in most software shops in 2020. Thus, this book is to be consulted as a vestige of history rather than a set of new ideas to implement. It’s still interesting, relevant, and inspirational because of the revolution it sparked. I read this book as a way to think through the practice of test-driven development. It helped me with that practice and continues to catalogue what good software development consists of. Interestingly, these skills have developed into Agile practices and more recent DevOps trends. Writing about these topics should now be consulted for state-of-the-art. show less

When a software developer is writing code, she/he is often confronted with a problem: How much work should I put into writing “the best” code versus just doing a quick but serviceable job? Kent Beck, pioneer of the influential Extreme Programming: Embrace Change, addresses this question via an in-depth look at the process of “tidying” code. His answer is usually to “tidy first”… but not always. This book seeks to identify exactly when one is in those exceptional show more situations.

Interestingly, Beck even explores economic reasons in his analysis – a main driver of developer effort that’s not talked about much in development books. These reasons are explored at a theoretical level that incorporates a bit of economic theory.

At times, this book can seem to be overly organizational and thus a bit dreary. That is, it categorizes situations instead of constructing a narrative. This approach became an extremely obvious limitation while I listened on an audiobook format. Perhaps a written text might avoid this pitfall somewhat more, but I suspect that even then, this shortcoming will show up in the reader’s experience.

This book’s audience is limited to those engaged in the art and practice of software design and development. The size of that audience is not huge, but it is growing. Developers can continue to learn from Kent Beck, one of the most observant, self-aware software authors in the industry. Those who desire to better themselves daily will benefit from his passion and attention to detail in this book. show less

This is an odd book. It is propaganda for a now popular software development method, but its strongest arguments have nothing to do with productivity or cost savings. Instead, they appeal to the personal integrity of software professionals: they are about identifying the values one upholds and, if they match those of Beck's Extreme Programming, to use his practices as a means to satisfying them.

The second edition of this book is more mature than the first. Beck doesn't talk as much about show more "cranking the dials up to 10" and he is far less dogmatic, and far more reflexive, about the right way to develop software. At some points (in particular with some of the corollary practices he proposes) the arguments are thin and too reliant on anecdotal evidence. But still, this is a great book, and I welcome the emphasis on values, on the humanity of software development, on communication, on professional commitment to work well done. It is refreshing to read not only that developers are not cogs in a machine, but that this is the essential insight of responsible software practice and needs to be taken to its extreme consequences. show less