Understand Principles behind Practices

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
-
Programmers often like rules. Having rules make things simple: You just do what your supposed to do. The problem occurs when people start following practices without understanding the principles that the rules enforce. Following and enforcing rules without explaining their the rational understanding eliminates the ability of a team or a person to do the right thing when there is an edge case that the rules didn't cover.
+
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.
-
A common question is whether principles or practices are more important in a a development methodology. Following practices allows you to quickly try something new, and in many cases you can be quite effective by following the rules. Inevitably you will come to a situation where the practice does not quite work. Without an understanding of the reason behind the practices you can't decide whether or how to adapt the practice, or if your feeling that the practice is not working is because the situation does not match, or because you are stuck in an old way of thinking. An understanding of "why" also 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.
+
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.
-
As another example, 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 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.
-
Being excessively dogmatic about how things are done can 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.
 +
 
 +
 
 +
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.
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.
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.
- 
-
The practices provide a tool to allow you to explore a new technique without the baggage of your prior experiences. Once you've has a chance to "practice" a set of practices, you can then reflect on whether your circumstances merit a change. But evaluate after trying the new practice.
 
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.
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.

Revision as of 19:30, 2 January 2009

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 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 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.

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.


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.


By Steve Berczuk

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools