Understand Principles behind Practices

From WikiContent

Revision as of 20:02, 2 January 2009 by Sberczuk (Talk | contribs)
Jump to: navigation, search

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

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.

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