Tech moves fast! Stay ahead of the curve with Techopedia!
Join nearly 200,000 subscribers who receive actionable tech insights from Techopedia.
Extreme Programming (XP)
Definition - What does Extreme Programming (XP) mean?
Extreme Programming (XP) is an intense, disciplined and agile software development methodology focusing on coding within each software development life cycle (SDLC) stage. These stages are:
Continuous integration to discover and repair problems early in the development process
Customer involvement and rapid feedback
These XP methodology disciplines are derived from the following four key values of Kent Beck, XP’s originator:
Communication: Communication between team members and customers must occur on a frequent basis and result in open project discussion without fear of reprisal.
Simplicity: This involves using the simplest design, technology, algorithms and techniques to satisfy the customer’s needs for the current project iteration.
Feedback: Feedback must be obtained at multiple, distinct levels, e.g., unit tests, code review and integration.
Courage: Implement difficult but required decisions.
Techopedia explains Extreme Programming (XP)
In addition to the key values, XP methodology implementation also requires the support of the three principles of incremental change, embracing change and quality work.
Twelve key practices also must be followed:
Some traditional methodology practitioners criticize XP as an “unreal” process causing reckless coding. Several traditional software developers find XP inflexible with low functionality and little creative potential. Additional criticisms are that XP:
Has no structure.
Lacks essential documentation.
Has no clear deliverables, i.e., realistic estimates are difficult because the entire project requirement scope is not fully defined. (This lack of detailed requirements makes XP highly prone to scope creep.)
Needs cultural change for adoption. (May work for senior developers only)
Is costly, i.e., requires frequent communication/meeting at the customer’s expense, which may lead to difficult negotiations.
Has possible inefficiency from frequent code changes within various iterations.
Of course, as with any development methodology, all this is very subjective and dependant on personal preferences.
