Following practices without deep understanding allows you to quickly try something new. By forcing yourself to work differently you can change your practices more quickly; being disciplined about changing how you work is essential to overcoming the inertia of your old ways. Practices often come first.

Following practices without deep understanding allows you to quickly try something new. By forcing yourself to work differently you can change your practices more quickly; being disciplined about changing how you work is essential to overcoming the inertia of your old ways. Practices often come first.

-

Over time you will discover situations where the a practice seems to be getting in your way. Understanding the underlying principles allows you to make decisions about how to apply a practice: for example, you may approach Pair Programming differently if you thought that the reason for Pair Programming was to save money on computers, as opposed to having the benefit of real time code reviews. You need to be careful to distinguish between cases where the practice is truly not working in your situation, and case where it feels awkward because it is just different. Don't optimize before you understand why the current way is not working for you.

+

Over time you will discover situations where the a practice seems to be getting in your way. That is the time to consider varying the practices from the canon. You need to be careful to distinguish between cases where the practice is truly not working in your situation, and case where it feels awkward because it is just different. Don't optimize before you understand why the current way is not working for you. Understanding the underlying principles allows you to make decisions about how to apply a practice: for example, you may approach Pair Programming differently if you thought that the reason for Pair Programming was to save money on computers, as opposed to having the benefit of real time code reviews.

-

Following a practice without understanding can can lead to trouble too: Test Driven Development can simplify code and make development less expensive. But writing overly complicated, or inappropriate tests can increase the complexity of the code, and increase the cost of application development.

+

Following a practice without understanding can can lead to trouble too: Test Driven Development can simplify code, enable change, and make development less expensive. But writing overly complicated, or inappropriate tests can increase the complexity of the code, and increase the cost of change.

-

Being excessively dogmatic about how things are done can also erode innovation. In addition to understanding the principles behind a practice, question whether the principles and practices make sense in your context, but be careful: trying to customize a process without understanding the principles and practices relate can set you up for failure. The cliche example is "doing XP" by skipping documentation and doing none of the other practices.

+

Being excessively dogmatic about how things are done can also erode innovation. In addition to understanding the principles behind a practice, question whether the principles and practices make sense in your context, but be careful: trying to customize a process without understanding the principles _and_ practices relate can set you up for failure. The cliche example is "doing XP" by skipping documentation and doing none of the other practices.

When trying something new:

When trying something new:

-

* Start by following best practices as close to the "book" as possible. Resist the temptation to customize early; you risk losing the benefits of a new way of working, and of reverting to your old ways under a new name.

+

* Start by following best practices as close to "the book" as possible. Resist the temptation to customize early; you risk losing the benefits of a new way of working, and of reverting to your old ways under a new name.

-

* Once you have had some experience evaluate whether your execution of a practice is in line with its principles, and then adapt the practices to work better in your environment.

+

* Once you have had some experience evaluate whether your execution the the practices are in line with their principles, and if they are, adapt the practices to work better in your environment.

Revision as of 19:17, 3 January 2009

Development methods and techniques have principles and practices. Principles describe the underlying ideas and values of the method. Practices are what you do to realize them.

Following practices without deep understanding allows you to quickly try something new. By forcing yourself to work differently you can change your practices more quickly; being disciplined about changing how you work is essential to overcoming the inertia of your old ways. Practices often come first.

Over time you will discover situations where the a practice seems to be getting in your way. That is the time to consider varying the practices from the canon. You need to be careful to distinguish between cases where the practice is truly not working in your situation, and case where it feels awkward because it is just different. Don't optimize before you understand why the current way is not working for you. Understanding the underlying principles allows you to make decisions about how to apply a practice: for example, you may approach Pair Programming differently if you thought that the reason for Pair Programming was to save money on computers, as opposed to having the benefit of real time code reviews.

Following a practice without understanding can can lead to trouble too: Test Driven Development can simplify code, enable change, and make development less expensive. But writing overly complicated, or inappropriate tests can increase the complexity of the code, and increase the cost of change.

Being excessively dogmatic about how things are done can also erode innovation. In addition to understanding the principles behind a practice, question whether the principles and practices make sense in your context, but be careful: trying to customize a process without understanding the principles _and_ practices relate can set you up for failure. The cliche example is "doing XP" by skipping documentation and doing none of the other practices.

When trying something new:

Start by following best practices as close to "the book" as possible. Resist the temptation to customize early; you risk losing the benefits of a new way of working, and of reverting to your old ways under a new name.

Once you have had some experience evaluate whether your execution the the practices are in line with their principles, and if they are, adapt the practices to work better in your environment.