Kent BeckRecensioni

Despite the terrible name, a mind opening title for programmers and managers alike. It will take time to apply everything this book suggests, but I'm a convert already.

This is one of those books that I would have rated more highly a few years ago. TDD is not a particularly complicated concept and, these days, it's not particularly new either. Thus, the explanations I've come across online[1] and the one book I've read on the topic[2] have been quite sufficient exposure, making reading another book on the topic superfluous.

That said, Beck's book was, in my opinion, better than Test-Driven Development: A Practical Guide by David Astels. Astels' book is not bad, but it's over 500 pages long, and TDD just isn't really that complicated. Beck's book, at ~200 pages of fairly spacious typesetting, is much more proportional to the complexity of the topic (websites are even shorter, but I prefer to read books, especially when they are available from the library at work).

In short, if you are interested in learning about TDD -- and I think it's an approach all programmer should learn about and apply judiciously but not religiously -- I recommend reading about it on the internet and then, if you're a book person or want to see a more extended example, read Beck's book.

[1] http://en.wikipedia.org/wiki/Test-driven_development and http://www.agiledata.org/essays/tdd.html
[2] test-driven development: A Practical Guide by David Astels

XP is such a good set of patterns, Raising great development practices to a system that enhancing each other. This should be read by anyone taking part in a development team or tightly interacting with it.

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 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.

Repetitive and simplistic. Does not go into more complex issues of testing. There must be a better book out there on TDD.

I have read as much of this book as I needed and used some of the material when proposing a new process at work. I wish it focused on more than just unit tests.

Very timely in the early 2000s. Fights the bureaucracy of the methodologies of the "3 amigos" - Booch, Rumbaugh and Jacobsen - which became the Unified Process (RUP).

If you want to learn the principles of XP, this is THE book. If you want to learn the practice of XP, there are better alternatives.

The ideas and motivation of XP are explained clearly and concisely. It's a short read, but fairly convincing. However, if you learn better from examples, this book does not have enough real world stories to really see XP in action.

The book is full of great quotes:

XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.

Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn't change, because change is going to happen; the problem, rather, is our inability to cope with change.

No book of gardening, however complete, makes you a gardener. First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a garden

As Will Rogers said, “It ain't what you don't know that gets you in trouble. It's what you know that ain't so.”

If members of a team don't care about each other and what they are doing, XP won't work. If members of a team don't care about a project, nothing can save it.

In software development, “perfect” is a verb, not an adjective.

Quality isn't a purely economic factor. People need to do work they are proud of.

Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn't give you time to drink your coffee.

Put new software into production every night. Any gap between what is on a programmer's desk and what is in production is a risk. A programmer out of sync with the deployed software risks making decisions without getting accurate feedback about those decisions.

Silence is the sound of risk piling up.

He picked a powerful metaphor for his teaching, Scientific Management. When picking descriptive names, it helps to pick a name whose opposite is unappealing. Who could possibly be for “unscientific” management?

Having a separate quality department sends the message that quality is exactly as important to engineering as marketing or sales. No one in engineering is responsible for quality.

I don't write Smalltalk, but this is undoubtedly one of the best books on programming I've ever read, and I think will be applicable to anyone who works in an OO paradigm and wants to write better code, where better means clearer separation of concerns, enhanced readability, and better performance.

I found this book an approachable read for learning the how, what, when, why's of test-driven-development. Mr. Beck has both the knowledge to impart and the skills to communicate the concepts and practice of test drive development.

I must have read this back when it came out because I remember some of the jokes. This is a fascinating book about TDD, esp. if you read it now, given the maturation of the development model. On p. 199 there is a tantalizing section on "Application" TDD, where in a paragraph Beck anticipates BDD -- and how hard BDD can be if you don't properly rope in stakeholders as collaborators. I don't think we've figured that one out yet.

The book is a weird mix. First there's a section where Beck uses TDD to evolve an interface for handling money operations in different currencies. The section is a bit of a cheat, though, because first off Beck notes that he's done the "money" implementation 3 times in production, six times in print, and in live talks (p. 82): So the notion that he is somehow figuring out a problem or design with his TDD is pretty doubtful. He also notes in passing as he is working towards an implementation of a Sum class that it looks like a Composite pattern (p. 74) . . . that's right. He basically had the whole architecture in his head and is just kind of playing around. The section is also problematic because there's no complete source listing of the end product. Nowadays, it would be nice to have a full-blown commit list in github. On the other hand, it's all Java, and you have to wonder if it would take so long in, say, Ruby or Python.

Then there's a section on TDD'ing a Python xUnit. This section is quite forgettable. It's supposed to be "meta" and show you how you can TDD anything, but, really, it's pretty boring.

Then comes Part III: TDD Patterns. This bears close reading and has lots of little bits of advice, but you had better already be a "patterns" person. There are some interesting bits that show how far we've come from Java (for example: I can't imagine every doing a "self shunt" (p. 145) in Ruby.

We have really come a long way.

So: I recommend this for wisdom and for remembering the history. But if you're new to TDD I'm not sure this is the right place to start anymore.

referred from Uncle Bob's _Clean Code_

Imaginen escuchando al padre de XP mientras desarrolla paso a paso un sistema usando Test-Driven Development. Este libro ayuda a entender TDD mediante práctica.

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 "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.

I've been a programmer for over 10 years now, but somehow I haven't had to do too much collaboration on a project...

I suspect it has something to do with the fact that the only language I'm comfortable to collaborate in (Perl) isn't one that most folks collaborate in..

Anyway, I'd like to try Pair-programming with one of the '100 times more productive' programmers that the experts say are out there...½

This is an excellent introduction to the whole field of Agile methodologies in general and Extreme programming in particular.

Эта книга харизматических лидеров экстремального программирования - о том, как планировать проекты разработки программного обеспечения по технологии XP. В основном она предназначена руководителям - тем, кто должен составлять план работ, а потом следить, чтобы он соответствовал действительности.
Она будет полезна и программистам с заказчиками, поскольку это две основные роли в процессе планирования и разработки ПО.

Экстремальное программирование - это упрощенная методика организации производства для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований. Данная книга поможет определить, оправдано ли применение XP в вашей ситуации.

It's always good to go back to primary sources. This book started the "extreme programming" fad, which is one approach to writing software. As with many such fads, this one is built on a set of solid principles, but the success or failure of any given project depends on the intuition and discipline with which those principles are brought together. More loosely, it's one way out of many that software could be written.