Posts Tagged ‘eXtreme Programming
Coding process in FDD is not as exciting and challenging as it is in XP (eXtreme Programming). This happens because by the coding time the features have been extensively discussed during Process One, iteration kick-off meeting, design review meeting. Classes and methods are defined by now, their purpose is described in code documentation. Coding often becomes a mechanical process.
Unlike XP FDD strongly discourages re-factoring. The main argument against re-factoring here is that it takes time and does not bring any value to the customer. The quality of code is addressed during code review meetings.
FDD encourages strong code ownership. The main idea is that every developer knows the owned code and better realizes the consequence of changes. FDD fights the problem of leaving team members from the different angle:
- Sufficient code documentation simplifies understanding somebody else’s code.
- Developers know what other people’s code does, since they reviewed the design.
- Developers will look at each other’s code during code review.
What is XP? XP (eXtreme Programming) is a lightweight, efficient, low-risk, flexible, predictable,scientific, and fun way to develop software. It is distinguished from other methodologies by,
- Its early, concrete, and continuing feedback from short cycles.
- Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
- Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.
- Its reliance on automated tests written by programmers and customers to monitor the progress of development, to allow the system to evolve, and to catch defects early.
- Its reliance on oral communication, tests, and source code to communicate system structure and intent.
- Its reliance on an evolutionary design process that lasts as long as the system lasts.
- Its reliance on the close collaboration of programmers with ordinary skills.
- Its reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project.
XP is a discipline of software development. It is a discipline because there are certain things that you have to do to be doing XP. You don’t get to choose whether or not you will write tests—if you don’t, you aren’t extreme: end of discussion. XP is designed to work with projects that can be built by teams of two to ten programmers, that aren’t sharply constrained by the existing computing environment, and where a reasonable job of executing tests can be done in a fraction of a day.
XP frightens or angers some people who encounter it for the first time.However, none of the ideas in XP are new. Most are as old as programming. There is a sense in which XP is conservative—all its techniques have been proven over decades (for the implementation strategy) or centuries (for the management strategy).
The innovation of XP is
- Putting all these practices under one umbrella.
- Making sure they are practiced as thoroughly as possible.
- Making sure the practices support each other to the greatest possible degree.