Ooochie: A Ruby Developer’s Journal

I've recently gotten back into reading, and have been trying to read at least a little bit every day. I always feel a sense of accomplishment after I finish a book, since I get so much more out of them than most other things these days. I really enjoy books based on true stories, inspirational books, and sometimes technical books. I mostly read books that have been recommended to me, so I thought I'd post my reading list here for you all to peruse. If you have any recommendations, please leave a comment!

Recently Read

• Mere Christianity by C.S. Lewis
• Into the Wild by Jon Krakauer
• Escape by Carolyn Jessop

Currently Reading

• The Art of Possibility by Rosamund Stone Zander and Ben Zander
• Implementation Patterns by Kent Beck

In the Queue

• The Art of Happiness by the Dalai Lama
• The Screwtape Letters by C.S. Lewis
• The Culture Code by Clotaire Rapaille
• The Exceptional Presenter by Timothy J. Koegel

What are you reading?

I've been working on reading Agile Estimating and Planning by Mike Cohn, so I figured I would post my notes here as a follow up to my notes on Extreme Programming Explained. The book starts by introducing the purpose of planning, and why traditional methods of planning fail. Right from the beginning (even the title), it stresses that the estimating and planning process itself must be agile. Planning should reveal what should be done and when, and estimating should reveal how big a project really is.

The reason I picked up this book was to read about release and iteration planning, so those are the parts I will highlight here. I have never personally be involved in a release planning meeting, and we talk a lot at Integrum about how we need to be better about release planning. We've also tested out a handful of iteration planning techniques, so I was really interested in what this book had to say.

Tips for Iteration Planning

• Don't allocate tasks to certain pairs/individuals during iteration planning. It takes away from the "all in it together" attitude.
• Organize stories and tasks so it is easy to tell what task goes with what story.
• Don't get too far into a discussion about design. All you need at the time of iteration planning is guesses about the work to be completed.

These are just the highlights I took from Agile Estimating and Planning by Mike Cohn. For more information, go read it yourself! Please comment with thoughts or experiences on release/iteration planning. Thanks!

OK my dear readers, I give you the final part of my series on Extreme Programming. Thanks for being patient (except - cough - Gist - coughcough) while I finished reading!

Parts 1 and 2 discussed the values and principles of XP. Now we are ready to talk about the practices: specific ways to apply XP to your software development. The author says the following about the practices:

"The practices in this chapter aren't the whole story of XP. They provide a foundation of respect, communication, and feedback that fosters simplicity and courage. The team members can use their increasing confidence and competence to build relationships inside and outside the team."

Without further ado, the primary practices of XP are:

Sit Together

• Develop in an open space.
• Communicate with all your senses.
• Physical proximity enhances communication.

Whole Team

• People need a sense of belonging to the team.
• Large teams lose trust, and trust is necessary for collaboration, so try to keep teams small.

Informative Workspace

• An outsider should be able to tell how the project is going within 15 seconds of being exposed to the workspace.
• Water and snacks provide comfort in the workspace and encourage positive interactions.
• Cleanliness and order of the workspace clears minds and helps people focus.
• Use big, visible charts.

Energized Work

• Work only as long as you are productive.
• "Software development is a game if insight, and insight comes to the prepared, rested, relaxed mind."
• If you're sick, rest!

Pair Programming

• Pair programming is two people working at one machine.
• "Pair programming is a dialog between two people simultaneously programming and trying to program better."
• Allows people to keep each other on task, clarify ideas, and hold each other accountable to other practices.
• Rotate pairs frequently. Switch pairs at natural breaks in development.
• Personal space must be respected!
• Pay attention to hygiene and health.
• Avoid relationships within the team.

Stories

• As soon as a story is written, try to estimate the necessary development effort.
• Early estimation gives business people and tech people the chance to interact and create value.
• Estimating early gets everyone thinking early.
• Put stories on index cards on the wall.
• "You can't make a good decision based on image alone." - Providing estimates allows customer to make an informed decision.

Weekly Cycle

• Plan work a week at a time.
• Have a weekly meeting to review progress, have the customer pick a weeks worth of stories to implement, and task out stories.
• Goal: deployable software at the end of the week.
• Work on gradually reducing planning time.

Quarterly Cycle

• Plan work a quarter at a time.
• Have a weekly meeting once per quarter to reflect on progress, plan themes, identify bottlenecks, and pick a quarter's worth of stories to implement.
• Focus on the big picture: Talking about "themes" as opposed to stories helps people see how the details of what they are doing fit into the bigger picture.

Slack

• Always include some minor tasks that can be dropped if you get behind.
• Meeting your commitments is important in building relationships.
• "Clear, honest communication relieves tension and improves credibility.

Ten-Minute Build

• Automatically build the whole system and run all tests in ten minutes.
• "A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback."
• An automated build can be a stress-reliever at crunch-time.

Continuous Integration

• Integrate changes every couple of hours.
• Pairs should integrate(build and run tests) after every pairing session.
• "Continuous integration should be complete enough that the eventual first deployment of the system is no big deal."

Test-First Programming

• Write a failing test before changing any code.
• Helps avoid writing unnecessary code.
• Tests should be easy to write. If they aren't, you may have a design problem.
• Passing tests let your teammates trust that you've written working code.
• Get into a coding rhythm: Test, code, refactor. Test, code, refactor. etc.

Incremental Design

• "Strive to make the design of the system an excellent fit for the needs of the system that day."
• Eliminates duplication.
• XP teams are confident in their ability to adapt the design, which allows them to satisfy the human need for immediate success and economic need to put off investment.
• "The most effective time to design is in the light of experience."

There you have it, a brief (and hopefully helpful) overview of the values, principles, and practices of Extreme Programming. As I mentioned in Part 1, I am glad to have found a work environment that follows XP. It creates a feeling of community and a productive working environment. For more info, go read the book yourself! Enjoy. :)

Now that we've gone over the values that drive XP (Part 1), we're ready to talk about the principles that guide XP. Beck defines principles as "a set of domain-specific guidelines for finding practices in harmony with XP's values." We need principles because they act as a bridge over the gap between values and practices. "Values don't provide concrete advice about what to do in software development." Principles help make it easier to derive practices from the values outlined in part 1. The principles that guide XP are the following:

Humanity

• People need basic safety, a sense of accomplishment and belonging to a group, the opportunity to grow, and the opportunity to understand and be understood.
• People need free time. Time away from work allows for more energy to bring back to the team.
• Private life details confuse team communication. Keep private matters private.

Economics

• Make sure what you are doing has business value and serves business needs.
• Earn money sooner and spend money later.
• Try to enhance "option value": options for future use of your product.

Mutual Benefit

• Every activity should benefit all people involved. If it costs one person, relationships will begin to break down.
• Automated tests help you write better code now and act as documentation for future programmers, therefore benefiting all parties.

Self Similarity

• Try copying a good solution into a different context.
• Write a test that fails, then make it work.

Improvement

• "Perfect" is a verb, not an adjective!
• XP is excellence in software development through improvement.
• Do the best that you can now with the intention of doing it better tomorrow.

Diversity

• Teams where everyone is alike are not effective: a variety of skills and perspectives is necessary for success.
• Diversity leads to 'conflict' (i.e. more than one solution). All ideas should be valued and respected.

Reflection

• Think about how and why you are working.
• Learn from your mistakes and the mistakes of your team members.
• Reflection comes after action.

Flow

• Deliver a steady flow of valuble software.
• Deploy small increments of value frequently.

Opportunity

• See problems as an opportunity for change!

Redundancy

• Difficult problems should be solved in several ways in order to prevent disaster. (i.e. Defects are addressed in XP by continuous integration, pair programming, customer involvement, etc. All these things are done to solve the same problem: bugs.)

Failure

• "Failure is not a waste if it imparts knowledge."
• When you don't know what to do, try something. Risk failure.

Quality

• Increases in quality lead to increases in productivity and effectiveness.
• People need to do work that they are proud of.

Baby Steps

• Momentous change all at once is dangerous.
• Take many small steps rapidly.(i.e. Test driven development, continuous integration.)

Accepted Responsibility

• Responsibility cannot be assigned, you have to accept it.
• If you are responsible for implementing story, you are also responsible for designing and testing that story.

As Beck puts it, "The principles give you a better idea of what the practice is intended to accomplish." Now that you understand the principles, you already know the goals of XP. The practices, which I will outline in part 3, are the things you can do to accomplish these goals.

Part 3 coming soon!

Even programmers can be whole people in the real world. XP is an opportunity to test yourself, to be yourself, to realize that maybe you've been fine all along and just hanging with the wrong crowd.

This quote comes from the Note to Programmers at the beginning of Extreme Programming Explained, by Kent Beck and Cynthia Andres. I consider myself very lucky to have found a workplace that follows XP. While I was in school I didn't know what I wanted to do with my degree because the stereotypical lonely programming life did not appeal to me. Had I known there was such a thing as XP, I would have been much more optimistic about pursuing a career as a programmer. I've recently been reading through Extreme Programming Explained and have taken notes in an attempt to absorb as much of it as possible. I thought I would post them here for those who haven't gotten the chance to read it. Here's a very brief overview of the overview. :)

What is XP?

• Giving up old habits for new ones that work.
• Appreciating yourself for total effort today.
• Striving to do better tomorrow.
• Evaluating yourself through contributions to team goals.
• Getting your needs met through software development.

Paradigm for XP

• "Stay aware. Adapt. Change."
• "Make frequent, small corrections."
• "You don't have to wait a long time to find out if you were going the wrong way."

After the basic overview of XP, the author gets into talking about values, principles, and practices. For now, I will only cover values, which are the first to be explained.

We all have personal values that shape our everyday lives; they are the roots of the things we like and dislike, and are "the large-scale criteria we use to judge what we see, think, and do." XP incorporates five core values that that focus on what is important to the team. They are outlined below.

Communication

• Helps solve problems.
• Motion without communication is not progress.
• Creates a sense of team and cooperation.

Simplicity

• Ask yourself, "What is the simplest thing that will work?"
• Eliminate wasted complexity.

Feedback

• Change is inevitable, and change creates the need for feedback.
• Be satisfied with improvement rather than expecting instant perfection.
• Shorten the feedback loop; it will allow you to adapt sooner.

Courage

• Definition: Effective action in the face of fear.
• If you know what the problem is, do something! If you don't know, ask!
• Doing something without regard for consequence is not effective teamwork.
• We must have the courage to adhere to the other values.

Respect

• XP won't work if the team members don't care about the project and each other.
• Everyone is important!

Next stop: principles that guide XP and practices to use in order to live XP. Stay tuned.