Understand Principles behind Practices - Revision history

Kevlin at 08:20, 11 July 2009

Kevlin — Sat, 11 Jul 2009 08:20:28 GMT

←Older revision		Revision as of 08:20, 11 July 2009
Line 3:		Line 3:
	Following practices without deep understanding can allow you to try something new quickly. By forcing yourself to work differently you can change your practices with ease and speed. Being disciplined about changing how you work is essential in overcoming the inertia of your old ways. Practices often come first.		Following practices without deep understanding can allow you to try something new quickly. By forcing yourself to work differently you can change your practices with ease and speed. Being disciplined about changing how you work is essential in 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 cases where it feels awkward just because it is 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.	+	Over time you will discover situations where 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 cases where it feels awkward just because it is 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, if you thought that the reason for pair programming was to save money on computers, your approach would be quite different than if you looked at pairing for the benefit of real-time code reviews.

	Following a practice without understanding can can lead to trouble too. For example, 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, increasing the cost of change.		Following a practice without understanding can can lead to trouble too. For example, 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, increasing 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 to each other 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 how the principles and practices relate to each other can set you up for failure. The clichéd example is "doing XP" by skipping documentation and doing none of the other practices.

	When trying something new:		When trying something new:
-	* Understand what you're trying to accomplish. If you don't have a goal in mind when trying a new process, you won't be able to evaluate your progress.	+	* Understand what you're trying to accomplish. If you don't have a goal in mind when trying a new process, you won't be able to evaluate your progress meaningfully.
	* 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 ~~the~~ the practices are in line with their principles, and if they are, adapt the practices to work better in your environment.	+	* Once you have had some experience, evaluate whether your execution of the practices are in line with their principles and, if they are, adapt the practices to work better in your environment.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 22:36, 16 February 2009

Sberczuk — Mon, 16 Feb 2009 22:36:02 GMT

←Older revision		Revision as of 22:36, 16 February 2009
Line 7:		Line 7:
	Following a practice without understanding can can lead to trouble too. For example, 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, increasing the cost of change.		Following a practice without understanding can can lead to trouble too. For example, 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, increasing 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 to each other 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:
		+	* Understand what you're trying to accomplish. If you don't have a goal in mind when trying a new process, you won't be able to evaluate your progress.
	* 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 the the practices are in line with their principles, and if they are, 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.

Kevlin at 17:07, 3 February 2009

Kevlin — Tue, 03 Feb 2009 17:07:38 GMT

←Older revision		Revision as of 17:07, 3 February 2009
Line 1:		Line 1:
-	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.	+	Development methods and techniques embody 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.	+	Following practices without deep understanding can allow you to try something new quickly. By forcing yourself to work differently you can change your practices with ease and speed. Being disciplined about changing how you work is essential in 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.	+	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 cases where it feels awkward just because it is 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.	+	Following a practice without understanding can can lead to trouble too. For example, 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, increasing 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.
Line 12:		Line 12:
	* 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 the the practices are in line with their principles, and if they are, 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.
-
-
-

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 19:22, 3 January 2009

Sberczuk — Sat, 03 Jan 2009 19:22:00 GMT

←Older revision		Revision as of 19:22, 3 January 2009
Line 7:		Line 7:
	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.		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:

Sberczuk at 19:17, 3 January 2009

Sberczuk — Sat, 03 Jan 2009 19:17:54 GMT

←Older revision		Revision as of 19:17, 3 January 2009
Line 3:		Line 3:
	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.

Sberczuk at 19:13, 3 January 2009

Sberczuk — Sat, 03 Jan 2009 19:13:31 GMT

←Older revision		Revision as of 19:13, 3 January 2009
Line 1:		Line 1:
-	Development methods and techniques have principles and practices. ~~The principles~~ describe the underlying ideas and values of the method. ~~The practices~~ are what you do to realize them.	+	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~~, and by simply working~~ differently you can ~~improve what you are doing, and~~ being disciplined about changing how you work is essential to ~~overcome~~ the inertia of your old ways. Practices ~~can~~ 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. ~~(There is more~~ to ~~pair programming than~~ just ~~sitting down together~~.)	+	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.

-	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 ~~the or writing the wrong test because you want to code "test first." Writing detailed tests early about an aspect of the~~ application ~~that you know will change frequently can increase the costs to make a simple change~~.	+	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.

-	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~~. On the other-hand~~, trying to customize a process ~~with~~ without understanding the principles ~~it,~~ and ~~how its~~ 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; 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 ~~adopt~~ the practices to work better in your environment.	+	* 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.

Sberczuk at 20:02, 2 January 2009

Sberczuk — Fri, 02 Jan 2009 20:02:41 GMT

←Older revision		Revision as of 20:02, 2 January 2009
Line 1:		Line 1:
	Development methods and techniques have principles and practices. The principles describe the underlying ideas and values of the method. The practices are what you do to realize them.		Development methods and techniques have principles and practices. The principles describe the underlying ideas and values of the method. The practices are what you do to realize them.

-	Following practices (without deep understanding) allows you to quickly try something new, and by simply working differently you can improve what you are doing~~. Being~~ disciplined about changing how you work is essential to overcome the inertia of your old ways. Over time you will discover situations where the a practice seems to be getting in your way. ~~An understanding of~~ underlying principles allows you to make decisions about how to apply a practice: for example, you may ~~come to a different understanding of how to~~ Pair ~~Program~~ 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 practices (without deep understanding) allows you to quickly try something new, and by simply working differently you can improve what you are doing, and being disciplined about changing how you work is essential to overcome the inertia of your old ways. Practices can 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. (There is more to pair programming than just sitting down together.)

	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 the or writing the wrong test because you want to code "test first." Writing detailed tests early about an aspect of the application that you know will change frequently can increase the costs to make a simple change.		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 the or writing the wrong test because you want to code "test first." Writing detailed tests early about an aspect of the application that you know will change frequently can increase the costs to make a simple change.

Sberczuk at 19:41, 2 January 2009

Sberczuk — Fri, 02 Jan 2009 19:41:24 GMT

←Older revision		Revision as of 19:41, 2 January 2009
Line 1:		Line 1:
-	~~To work effectively as part~~ of ~~a team we need to agree to how~~ the ~~team members will interact~~. ~~Sometimes these guidelines~~ are ~~expressed in terms of a development method such as Scrum, or XP, for example~~.	+	Development methods and techniques have principles and practices. The principles describe the underlying ideas and values of the method. The practices are what you do to realize them.

-	~~Development methods have principles and~~ practices. ~~The principles describe~~ the ~~underlying ideas and values~~ of the ~~method~~. ~~The practices are what~~ you do to ~~realize them~~.	+	Following practices (without deep understanding) allows you to quickly try something new, and by simply working differently you can improve what you are doing. Being disciplined about changing how you work is essential to overcome the inertia of your old ways. Over time you will discover situations where the a practice seems to be getting in your way. An understanding of underlying principles allows you to make decisions about how to apply a practice: for example, you may come to a different understanding of how to Pair Program 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 ~~practices (~~without ~~deep~~ understanding~~) allows you to quickly try something new, and in many cases you~~ can be quite effective by following the rules. And when you are learning a new way of working there is a lot of merit in following practices "by the book." Over time you will discover situations where the a practice seems to ~~be getting in your way. An understanding of "why" allows you to make decisions about how to apply a practice~~: for example, you may come to a different understanding of how to Pair Program 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. Test Driven Development ~~is a great idea that~~ can simplify code and make development less expensive ~~over the lifecycle~~. But writing overly complicated tests can increase the complexity of the code, and increase the cost of the or writing the wrong test because you want to code "test first." Writing detailed tests early about an aspect of the application that you know will change frequently can increase the costs to make a simple change.	+	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 the or writing the wrong test because you want to code "test first." Writing detailed tests early about an aspect of the application that you know will change frequently can increase the costs to make a simple 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.	+	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. On the other-hand, trying to customize a process with without understanding the principles it, and how its 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; 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 adopt the practices to work better in your environment.

-	When adopting a new practice of development method:
-	* Resist the temptation to customize the practice early on; you risk losing the benefits of a new way of working.
-	* Once you have had some experience evaluate whether your execution of a practice is in line with its principles.

-	Following rules dogmatically can be helpful when you are trying something new to force you to change your mindset, and you can get into trouble customizing the rules before you have had a chance to change your mindset. And shared practices and guidelines should be in place to encourage communication and allow you to not worry about tasks that are secondary to your primary goals. But following rules blindly can cause problems too.
-
-	For example, having rules about coding styles are very useful when it comes to allowing others to quickly understand your code, and team members not following agreed upon coding guidelines can cause others to waste time. Yet indenting code is not the highest value activity a programmer can do, so code formatting guidelines that can be automated strike a good balance between team productivity and individual productivity.
-
-	When you are working, periodically take the time to reflect on whether "what has worked in the past" is still the right thing. Whenever you see someone on your team doing the "wrong" thing, take the time to understand the reason behind what they are doing. Sometimes they may be falling off the rails. Sometimes that may be seeing something from a different perspective.

Sberczuk: Understand Why moved to Understand Principles behind Practices

Sberczuk — Fri, 02 Jan 2009 19:31:11 GMT

Understand Why moved to Understand Principles behind Practices

←Older revision

Revision as of 19:31, 2 January 2009

Sberczuk at 19:30, 2 January 2009

Sberczuk — Fri, 02 Jan 2009 19:30:54 GMT

←Older revision		Revision as of 19:30, 2 January 2009
Line 9:		Line 9:

	When adopting a new practice of development method:		When adopting a new practice of development method:
-	* Resist the temptation to customize the practice early on; you risk losing the benefits of a new way of working.	+	* Resist the temptation to customize the practice early on; you risk losing the benefits of a new way of working.
-	* Once you have had some experience evaluate whether your execution of a practice is in line with its principles.	+	* Once you have had some experience evaluate whether your execution of a practice is in line with its principles.

	Following rules dogmatically can be helpful when you are trying something new to force you to change your mindset, and you can get into trouble customizing the rules before you have had a chance to change your mindset. And shared practices and guidelines should be in place to encourage communication and allow you to not worry about tasks that are secondary to your primary goals. But following rules blindly can cause problems too.		Following rules dogmatically can be helpful when you are trying something new to force you to change your mindset, and you can get into trouble customizing the rules before you have had a chance to change your mindset. And shared practices and guidelines should be in place to encourage communication and allow you to not worry about tasks that are secondary to your primary goals. But following rules blindly can cause problems too.