American software developer, born 1961. Created Extreme Programming, popularised test-driven development and wrote JUnit. "Make it work, make it right, make it fast" is his, and that is the order we follow.
Definition
Beck came out of the Smalltalk community of the late eighties and through the nineties. That is worth knowing, because the practices he is known for were not invented at a desk. They were lifted out of a way of working where the programmer sat inside the system while it ran, changed it and saw the effect immediately.
Extreme Programming took shape in 1996, during the Chrysler C3 project. XP named things that are obvious today and were not then: pair programmingDevelopment practice where two developers work together at one machine - one writes code, one reviews and thinks - continuously and synchronously., continuous integration, and the customer as part of the team rather than a party on the other side of a requirements document.
Test-driven development is the part that has travelled furthest, popularised through "Test-Driven Development: By Example" in 2002. The cycle is red, green, refactor: write the failing test, make it pass in the simplest way possible, then clean up the code while the test holds you accountable. The point is not test coverage. The point is that you have to describe what you want before you describe how.
He wrote JUnit with Erich Gamma in 1998. That framework became the template for the xUnit family, and thereby for what unit tests look like in practically every language today.
His mantra is an order, not three equal goals. Make it work. Then make it right. Then make it fast. Those who swap the first two end up with something elegant that does not solve the task, and those who skip the second end up with technical debtAccumulated costs of quick, short-term technological decisions - makes future development slower and more expensive. they did not choose.
The line here is real, not a decorative reference. The Smalltalk community Beck took pair programming and the fast feedback loop from is the same community Jon Petter comes from, in the same period.
Pair programming is a core principle for us, not an exercise we bring out when someone is watching. It is also the cheapest form of knowledge transfer we know: two people who wrote something together have both seen why it turned out the way it did.
The tests are why rewriting is practice rather than risk. When the specification and the tests carry the requirements, the code beneath them becomes something replaceable. That is why seven years in production and modern code is not a contradiction, and it is the same point as knowing the craft being what makes the speed defensible.
XP's idea of the customer in the team is the forerunner of the design partner model: the person who will use it sits in the room while it is shaped, instead of receiving it when it is too late to have an opinion.
In practice
The line here is real, not a decorative reference. The Smalltalk community Beck took pair programmingDevelopment practice where two developers work together at one machine - one writes code, one reviews and thinks - continuously and synchronously. and the fast feedback loop from is the same community Jon Petter comes from, in the same period.
Pair programming is a core principle for us, not an exercise we bring out when someone is watching. It is also the cheapest form of knowledge transferStructured process for transferring know-how from one person, team or organisation to another - important in system handovers and new partnerships. we know: two people who wrote something together have both seen why it turned out the way it did.
The tests are why rewriting is practice rather than risk. When the specification and the tests carry the requirements, the code beneath them becomes something replaceable. That is why seven years in production and modern code is not a contradiction, and it is the same point as knowing the craft being what makes the speed defensible.
XP's idea of the customer in the team is the forerunner of the design partner model: the person who will use it sits in the room while it is shaped, instead of receiving it when it is too late to have an opinion.
