This week we talk through principles in Extreme Programming, humanity, mutual benefit, improvement, diversity, failure and more.
A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter
Hi, I'm John and I'm joined by JP.
Today we will be going through chapter 5 and continuing our discussion about the guiding principles of Extreme Programming.
Values are too abstract to directly guide behavior. (This is why we discuss things in the context of principles)
Other principles may guide your team, but these are the principles that guide XP:
Now obviously we aren't going to bore you with discussion on all 14 of these principles, so today we'll only talk about a handful of them.
Copy and paste alert
What do people need to be good developers? What are some basic human needs?
Interestingly, satisfying these requisites meets both business and human needs.
"Fractal Nature of geology" When nature finds a shape that works, she uses it wherever she can.
A crystal is a material whose constituents, such as atoms, molecules or ions, are arranged in a highly ordered microscopic structure — the same arrangment all the way to an atomic level. The same shape, makes up arrangments that make the same shape, that makes up arrangements that make the same shape.
All's to say - I've found that many things that prove useful at a small scale, work at larger scales
Software development teams where everyone is alike, while comfotable, are not effective. Teams need to bring together a variety of skills, attitudes, and perspectives to see problems and pitfalls, to think of multiple ways to solve problems, and to implement the solutions. Teams need diversity
The principle of diversity suggets that the programmers should work together on the problem and both opinions should be valued.
"Learn to see problems as opportunities for change."
To reach exellence, problems need to turn into opportunities for learning and improvment, not just survival.
Conciously choose to transform each problem into an opportunity. Good book on this the obsticle is the way
.env files for all of our projects got posted to a public repo. We migrated toward a better more secure system, credentials that would be harder to leak and are easier to rotate. We used the problem as an oppourtunity to improve our architecture.
Sacrificing quality is not effective as a means of control... Quality should not be a control variable.
This is really extreme.
Author makes the aurgument that when you skimp on quality you end up spending even more time or money. This rings true, I have often taken the wrong approach in projects of skipming on design, testing or refacting and it doesn't really help in the long run.
We'd all like to get more features out the door for less money, it's just not doable. Less is less.
If you're having trouble succeeding, fail. Don't know which of the three ways to implement a story? Try it all three ways.
When you don't know what to do, risking failure can be the shortest, surest road to success