What is extreme programming and how it makes your code better?
Extreme programming has a huge influence on how software industries work today. TDD, pair programming, Code reviews have become the de facto standards as a part of XP.
Even after 30 years of its inception, extreme programming is still relevant and Martin Fowler calls extreme programming as a basis for agile practices.
Let us explore how and why…
In early programming days, software projects ran only on the best of the abilities of the people who wrote it. One small mistake and the code wreaks havoc.
Even without any mistakes, once the codebase gets large enough, it is difficult to maintain the existing code, let alone add any new features.
Programmers put their best efforts in making sure the code keeps working, meeting deadlines etc, while the customers/stake-holders probably wondered the programmers are being lazy and not delivering.
Enter Kent Beck…
A lot of these problems got easier to solve and the efforts to do so went down significantly.
He came with something called extreme programming.
Let’s see how it works and why Kent Beck thought of it and how even after 30 years of its inception it is still relevant.
What is extreme programming and how did it solve everything?
Extreme programming is a practice based on Agile which basically ensures best quality software in short time keeping in mind the welfare of the programmers and engagement with the customers/shareholders.
It all started at C3 (Chrysler Comprehensive Compensation project), a payroll project at Chrysler which is regarded as the birthplace for Extreme Programming.
C3 was aiming to replace legacy COBOL based system and the early development started in SmallTalk which was supposed to end by 2 years. 1.5 years down the line… there are some performance problems and Kene Beck is supposed to help them solve it.
Kent Beck: “Where are the tests that will prove when I make things any faster nothing is broken?”
C3: “Actually the code doesn't really work yet”
Kent Beck suggests 3 options:
- Keep going as it is
- Outsource the project (which is a shame with such exceptional people around, Martin Fowler also worked as a consultant on this project)
- Give everybody a week off, throw away all that has been done so far and start fresh and I think you will be successful
Kent Beck is put in charge. He structures the project in 3 weeks increments where work is divided into stories and at the end of each increment a demo for the users and plan for the next 3 weeks.
Next, someone suggests each story should have some acceptance test. Then someone suggests pair programming etc.
And so on by the end of the day, he had formulated extreme programming.
Later in his book Kent Beck standardizes this way of doing things and calls it Extreme programming.
Impact of extreme programming
Martin Fowler’s describes it as the basis for Agile practices.
Understanding why extreme programming works
Extreme programming is nothing but a set of values, principles and practices.
Why? To improve code and product quality keeping in mind the welfare of the developers.
To elaborate more extreme programming adheres to certain non-negotiable values (which we know will produce good quality).
To adhere to these values we use certain practices.
While using these practices we have certain principles/guidelines we should follow to achieve the best possible results.
To explain it better, for an athlete value is having a great body, practice: exercise daily and principle is not to use steroids.
Values and practices are bound by principles.
5 values of XP — feedback, communication, simplicity, courage and respect
How would these values ensure better code quality and developer welfare you might wonder.
Let’s explore one by one.
Communication: Like everything else to be able to achieve the best results everyone should be on the same page. The teams should talk, explain and understand amongst themselves.
Feedback: Once we have the same direction every now and then we need to re-evaluate ourselves from the feedback given by customers or members from your team. This ensures we are heading towards the best possible outcome with self and customer satisfaction.
Simplicity: The most elegant solutions are not the ones which are complex but are those which are simple to understand.
‘It is better to do a simple thing today and pay a little more tomorrow to change it’ than ‘to do a more complicated thing today that may never be used anyway’.
This means less explaining when onboarding new members and easy maintainability of our existing work.
Follow KISS principle ‘Keep It Simple, Stupid!’.
Courage: Voicing your opinions, to discuss and take decisions for the best of the team/product/customer. It often leads to the best ideas which originally were not a part of the plan or even considered.
Respect: Being open to others and considering everyone’s opinion and thoughts not only encourages people to share great ideas but makes sure you are heard too by others.
Now that we have our values in place let’s explore the principles.
Principles — Rapid feedback, simplicity, incremental change, embracing change and quality
Rapid feedback: Get feedback often to make sure you are satisfying the customer needs and reflecting what you have learned through the feedback in the product and your work.
Simplicity: Solve every problem in the most simple way. Do only as much as is required to actually implement the feature. Anything extra might only add complexity and might be completely obsolete and difficult to change later.
Follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself)
Incremental Change: Trying to do a lot at once might end up introducing a lot of bugs, unwanted code and end up not working in time. Big changes at once are bound to backfire. So every change should be broken down in a series of small steps. This helps in tracking progress and small units can be tested efficiently as well.
This philosophy can be applied to the project, design, architecture or the changes in the workforce as well.
Embracing change: Changes in design, project, plan should be embraced. This might give a competitive edge to the customer to confidently make any changes based on the market/environment and overall peace of mind to the team to be competent enough to embrace it.
Quality work: A team that works well, makes a valuable product and feels proud of it. The customer in general has a great satisfaction score at the end.
Now let us look at some practices which help us adhere to our values keeping in mind our principles.
Practices — faster feedback(TDD), continuous feedback(refactoring, CI, small releases), shared understanding(pair programming, code reviews), developers welfare(40 hr work week), customer engagement(On-site customer, The planning game)
TDD- Test-driven development is a practice where you write the tests first and then write the code. This ensures immediate feedback. It also keeps the code crisp and simple as every time you write you only write as much code as it is necessary to pass the test. By the time you are done you also have a safety net to continue refactoring without breaking anything.
Code Refactoring-Refactoring allows us to continuously improve code. It helps in removing redundancy, unnecessary code, increasing readability. Keeping code crisp and simple allows us to easily make changes even after along time.
CI/CD- It allows the team to collaborate on different parts of the code without being dependent on anybody. Code is pushed multiple times a day by different members. Automated and end to end tests ensure everything is working correctly.
Small releases-CI and small release go hand in hand. CI allows us to release incremental versions of the product to receive feedback from the customer. This allows us to catch bugs and test code in production. An early change can be suggested by the customer after each release.
Pair programming: It is a technique where two developers sit together and write code. While one writes the other ones reviews the code, suggests improvements and looks out for any mistakes. Then roles are then switched. This means faster knowledge sharing and better communication. Developers tend to learn practices from each other which helps in setting the code standard at team/organisation level.
Code reviews: These are based on PR model where developers raise a PR for every story/feature they work on. This allows in adhering to organisation level code standard. Developers can be advised to make changes if any. This also ensures there is a second set of eyes that scan through the code making sure there is enough code coverage, no mistakes and in general code quality is good.
Automated tools such as SONAR cloud help in code reviews.
40 hours week: This ensures developer welfare. They are well-rested and at their best when they work. A team is only as good as it’s members. This ensures there are no burnouts and developers are able to maintain a good work-life balance.
On-site customer: The customer should be a part of the development process to answer any questions, set priorities and resolve disputes if any.
The Planning Game: This is a meeting that occurs at the beginning of an iteration cycle. The development team and the customer get together to discuss and approve a product’s features. At the end of the planning game, developers plan for the upcoming iteration and release, assigning tasks for each of them.
Coding Standards: Having a common sets of coding practices, using the same formats and styles for code writing allows all team members to read, share, and refactor code with ease, as well as make the learning faster for other programmers.
Collective Code Ownership: This practice delegates the responsibility of the code to the entire team where each member is equally responsible. This ensures all team knows all code and know exactly where to put a certain piece of feature and avoid duplication.
System Metaphor: System metaphor stands for a simple design such that new people are able to start working on it without spending too much time examining specifications. And overall the code is readable.
XP gave the world many popular practices which changed the software industry for good. Practices like Test-Driven Development and Pair programming found their ways in almost every company across the world. Code reviews, coding standards and the practice of every programmer writing tests for the code they write are a must to make sure the best quality software is shipped.
These practices together yield a highly stable platform for future development.
When to use XP?
- Fast-changing requirements.
- Strict deadlines
- Small teams. For teams that don’t exceed 12 people.
- Creating automated tests is possible.
Lastly, I would like to add, even if you think XP is not for you, you must at least adopt the proven working practices such as TDD, code reviews, pair programming, code refactoring, etc. These ensure the best quality software, and crisp easy to maintain codebase with the least bugs.
As a wise man once said
A bug caught any time before shipping no matter how late in the development process will always cost a million times less than when caught in production.
Hope you enjoyed it :)