Jānis Blaus
Jānis Blaus
17 November, 2018

A Short Guide to Extreme Programming

Computer programming is the art of converting logic to actual work. Traditional programmers may disagree with us, but have you ever thought what the underlying purpose of programming is? From a programmer's point of view, you may be thinking solving problems is the real purpose of programming. However, the hard truth is, industries do not care much about solving problems.

In the business world, programming is usually seen as a means of aiding competitive advantage for a particular product. What this means is, a CEO or an MD of a leading multinational company needs programmers to help them with their products or other internal management systems. They don't care about which language or technologies are being incorporated as long as they attain their goal. Since its inception as an industrial weapon, programming has seen different approaches taken by programmers. Programmers at NASA used a much more fundamental approach than what we're doing these days. Structural programming became famous with the introduction of procedural languages like C during the 70s. From the 90s, object-oriented programming (OOP) became the new choice of industries due to the convenience it offered for software development. Other styles or paradigms such as agile development and test-driven development has seen a rise in use. Extreme programming is one of such programming paradigms that was invented as a solution for delivering modern and effective software solutions for industries. In this short guide, we'll look closely at what Extreme Programming is, how does it work, why should we use it and other important aspects for the potential audience.

Extreme Programming: Definition

Extreme Programming(XP) is an approach to deliver software solutions. It is a software development methodology where the primary emphasis is on the use of Best Practises. This paradigm is based on the fact that customer requirements are going to change over time. So it's better to build the most essential parts of a software and get the customer's approval than building the whole solution and facing changes in requirements. Extreme programming derives its name from the fact that it incorporates best-known practices to the extreme level. According to this method, best-known practices are widespread because they're effective. So incorporating best practices and incrementing features day by day will allow a software solution to be more robust and meet customer's expectation.

Origin of Extreme Programming

The origin of this paradigm goes as far back as the 90s. Industries were heavily employing an OOP method to achieve their software goals. Chrysler, a subsidiary of the Fiat automobiles were looking to establish a payment system which would pay all of their 80000 plus employees in the same way. Their choice of stack included the Smalltalk programming language and GemStone as the data access layer. The project was known as Chrysler Comprehensive Compensation System or simply the C3. Kent Beck, a pioneer of the Smalltalk language was brought in to help with the project. Facing the common problems present in the development process, Kent proposed and later implemented the first extreme programming approach. C3 thus became an important milestone in the XP methodologies.

Why Go the Extreme Way?

So the next big question is why do we need Extreme Programming and what's the feasibility of this approach when building commercial solutions. Traditionally, a slow development process is the most common problem faced by both enterprises and developers. In this era of rapid business growth, new demands are emerging every day. The old development methods are somewhat incompatible when it comes to meet the target of delivering timely solutions. Once, it was normal for software to be in the development phase for years. Even after production, updating needed much time. It was quite common for a software to be in the making for 5-10 years. However, the fast growth of enterprises requires much rapid access to the latest software. We've come to a time when it's normal for the business people to ask developers to deliver a software in less than a year. Even after developers deliver the software, clients always demand changes as their requirements took a turn during the development process. This is mainly because of the lack of understanding of business logic and programming feasibility between organizations and developers. XP aims at reducing this problem by allowing developers to incorporate the most basic features of a software first. Developers then show this prototype to customers for rapid evaluation. If the customer approves, then the development of the next most necessary function begins. This cycle continues and eventually when all the crucial features are developed, the team goes into production. If changes in customer's requirements appear, they're dealt accordingly right away.

Components of Extreme Programming(XP)

Extreme programming defines 4 core activities as the main components of the paradigm. These are coding, testing, listening, and designing.


Coding is the key state of the XP approach where the developers start coding to implement the features of the software. As the paradigm suggests, the most critical element of the software solution needs to be coded first. According to the principal of XP, coding all the features of the software before submitting them for feedback consumes a much higher time and productivity of the developer. Coding the essential feature first allows the developer to be ready to meet the changing requirements of the customers. If the client does not approve a feature, the developer can throw that part out and start coding the new feature immediately. The coding process of the XP paradigm adapts an incremental model. In this case, each feature is coded at a time, then evaluated before adding the next feature incrementally. By following this approach, the developer is sure of the prototype at any given time. 


Testing is an integral part of the extreme programming methodology. The advocates of the XP paradigm believed that if a little testing can eliminate a few flaws, then a lot of testing could eliminate most of the flaws present in a software. The initial idea was to test each piece of code written during the implementation of a feature at the end of the day. This would allow any potential bugs or flaws to be thwarted regularly and developers could code the next feature without having to worry about previous codes.

Unit Test

These are tests written for checking if a feature works as intended by the developers. Unit tests are automated tests written by keeping in mind what possible actions could break the feature. The more the number of tests, the higher the chances of the function being implemented correctly.

Acceptance Test

These tests are performed to check if the new feature rightly fulfills the client's requirements. 


Although it might not sound as cool, listening is another very important component of the XP paradigm. Developers are often faced with tasks or requirements that just can't be implemented. It frequently happens because most of the time customers don't have enough technical knowledge to be aware of what can be implemented and what not. The result is redundant customer requirements of which the development team have no idea. Listening eliminates these redundancies and aims at closing the gap between the customers need and the developers' capacities. By listening carefully to the customer, developers can determine what the customer is looking for in the software and what business logic is needed to implement. Only by listening to the customers, developers can give them feedback about different technical aspects of the problem and how it can be solved, or if can't be solved at all.


Many would argue that system development doesn't require anything more than coding, testing, and listening. By utilizing only these 3 components, a great system can be architected. But in practice, this would not hold for commercial systems. The software required by enterprises is complicated and needs a lot of dependencies. The code bases are very large. This opens up the scope of extra complexities and redundancies. Yes, it's possible to go for a certain amount of time without any definite design of a software. But, eventually, there will be deadlocks and overheads that can't be avoided anymore. A good design allows the developers to implement the software in a more structured way. In the future, this will enable developers to debug the system quickly and find potential flaws. The design should be free from too many dependencies, as lots of dependencies can cripple the system in the long term. Updating versions or moving the development stack also becomes a tedious task if the software requires too many dependencies. A modular, structural, and concise design approach should be taken for commercial software solutions.

Practices of Extreme Programming

Extreme programming methodology has defined selective practices for developers to follow. By following these practices, developers can aid to their contribution to a software much profoundly.

Test-Driven Development

TDD or test-driven development is a development approach which makes sure any given feature is implemented as the developers intended. This method promotes writing tests before even developing a feature. When the feature passes all the defined tests, developers can be sure of that features functionality. It differs from the conventional approach to software development where tests are done after implementing a feature. In this method, bugs or runtime flaws can be present in a function if the developer team fails to focus on every imaginable problem. TDD has become a popular method of software development on its own. It provides developers with the certainty of a given feature.

Pair Programming

Pair programming is heavily advocated by Kent Beck, the creator of the XP approach. What it means is that every piece of code is written by two dedicated programmers, instead of one. This allows the developers to ensure proper coding standards. Coding any specific feature with a partner means a developer is less likely to deviate from the project requirement. It also allows cross-checking of each feature right from the time of coding. Pair programming eliminates many of the common redundancies faced when programming individually.

Collective Ownership of Code

This means every piece of code is available to all the team members. According to this practice, codes are part of the team. Any team member is allowed to view already existing codes and may propose a change. In traditional development practices, each developer is typically assigned their roles and do all their coding alone. This may become a burden if somehow the developer doesn't remain in the team for the whole project. New developers need to contribute on their code even without having the same mindset of the previous developer.

Continuous Integration

This means any functionality of a given feature needs to be integrated incrementally. Usually, developers write codes for all the functionality of a feature then integrate those all at the same time. This can cause potential problems during deployment. Continuous integration allows developers to be aware of any unwanted issues right when they integrate it.

Controversy and Criticism of Extreme Programming

Since its inception as a software development paradigm, extreme programming has been part of a huge debate concerning its feasibility in commercial solutions. Lots of criticism from prominent figures have targeted this paradigm. Critics primarily drew upon the fact that by having on-site client request changes, XP promotes project scope creep. It can be thought of as a mean of bleeding much more money from the customer than agreed or funded. XP's primary viewpoint depends mostly on the interpretation of the client's requirements by programmers. By not having fixed requirements it confuses customers as they usually have little or no technical knowledge. Customers also object that the necessity of having a customer representative in the development team leads to the potential danger of micro-management. Having no major design up-front is also seen negatively. Prominent figures like McBreen and Boehm has criticized XP for being “often used as a means to bleed money from customers through lack of defining a deliverable product.” Extreme programming is hailed as a significantly important software development paradigm. If incorporated rightly, it can deliver top-notch commercial solutions at a much shorter development period. It has led the way to newer development paradigms such as the agile software development, and test-driven development. However, concerns regarding the proper usage of this method remain. It's believed to be much more resource consuming than other traditional approaches to commercial software.

Latest from the Netcore hub

Guides, research, opinions and sometimes just some crazy tech rumbling.
Explore, comment and join the dicussions.