Metaphysics of Software Development
Some insights on the software development craft, from a philosophical viewpoint.Thursday, February 4, 2010
Principles and practices
Every software development method aims to achieve certain goals, even if such goals are only implicitly stated. In order to achieve the desired objectives, each development method relies on a set of abstract principles, which are taken for granted. Theoretically, these principles can be applied to every particular case, without leading to too much contradiction. However, these general principles may not lend themselves to direct application in all the concrete cases, given their own abstract nature. To circumvent this problem, development methods usually have also a body of practical rules, which are more concrete and can be directly implemented with little or no adjustment.
The practical rules, therefore, are a means to applying the general principles to specific problems, such that developers abiding by the method get closer to their intended targets. As a consequence, the practical rules are subordinated to the principles and are only useful as long as they promote the adherence to the principles. But sometimes the practices happen to work against the principles themselves, which leads the developers astray, instead of getting them closer to the aimed targets.
Let's take a particular practice of a particular method to illustrate this. Consider the well-known ritual of daily Scrum. It is based on the first value and on the sixth and twelfth principles of the Agile Manifesto. As a practice, it states that developers should stand up together for 15 minutes every day to publicly update the project status. During the meeting, each team member speaks at a time, answering the following three questions:
So, during the daily meeting, when a member reports the status of their work, only the other members of their own sub-team are able to completely understand what it is all about. Hence, the meeting proves to be almost useless, since none of the members will get any new piece of information: those belonging to the same sub-team had already known all the details, while the others couldn't grasp most of what was being said.
In such cases, abiding by the rule of the daily meeting leads to a poorer communication, instead of a better one. Obviously, the problem in the above example is the team size and that is the real problem that needs to be tackled. But, supposing this is not possible (because of "orders from above", for example), it is important to recognize that the practice is not delivering the benefits it should. So, other forms of conveying information should be chosen and implemented, in spite of what the method prescribes. In summary: principles are more important than practices. If there is a better way to apply the principles, go for it.
The practical rules, therefore, are a means to applying the general principles to specific problems, such that developers abiding by the method get closer to their intended targets. As a consequence, the practical rules are subordinated to the principles and are only useful as long as they promote the adherence to the principles. But sometimes the practices happen to work against the principles themselves, which leads the developers astray, instead of getting them closer to the aimed targets.
Let's take a particular practice of a particular method to illustrate this. Consider the well-known ritual of daily Scrum. It is based on the first value and on the sixth and twelfth principles of the Agile Manifesto. As a practice, it states that developers should stand up together for 15 minutes every day to publicly update the project status. During the meeting, each team member speaks at a time, answering the following three questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
So, during the daily meeting, when a member reports the status of their work, only the other members of their own sub-team are able to completely understand what it is all about. Hence, the meeting proves to be almost useless, since none of the members will get any new piece of information: those belonging to the same sub-team had already known all the details, while the others couldn't grasp most of what was being said.
In such cases, abiding by the rule of the daily meeting leads to a poorer communication, instead of a better one. Obviously, the problem in the above example is the team size and that is the real problem that needs to be tackled. But, supposing this is not possible (because of "orders from above", for example), it is important to recognize that the practice is not delivering the benefits it should. So, other forms of conveying information should be chosen and implemented, in spite of what the method prescribes. In summary: principles are more important than practices. If there is a better way to apply the principles, go for it.
Labels: agile, principles
posted by Otavio Macedo # 9:06 AM 
Archives
January 2010 February 2010 March 2010 August 2011 November 2011
Subscribe to Posts [Atom]
Post a Comment