Software engineering has changed a lot over the last 20 years. What we practice today was once considered controversial in the 90s. Back then, the typical approach to software engineering was usually a waterfall-like process; this means distinct phases that were being worked on linearly: finding the requirements, designing & architecting a solution, implementing it, testing, and finally deployment.
The idea was that software could be built like buildings: well-defined steps, usually taken by different people in each phase. The waterfall model failed many times as software turned out to be quite different to build.
In 1993, a few people working together (one of them was Kent Beck) got together and proposed "radical" ideas.
They said two things: Focus on the goals and cut all the BS (pardon my french) surrounding software processes. There are supposed to be a) values that are supported by b) practices and should serve c) the customer/user/stakeholder.
Thanks to them and others, we have many agreed-upon methodologies and practices we use today. There were a bunch of academic studies that tried to prove their effectiveness but failed. Some of the methods we're talking about are personal preferences that some people prefer and others don't.
The year is 1996, and a methodology that encourages swift progress in the face of ever-changing customer requirements beckons. Such a programming approach was then coined by a software engineer, Kent Beck, and became known as Extreme Programming (XP).
XP is a variant of the later established Agile software development philosophy that values communication, prompt integrations of group-coded changes to a software product in small increments.
XP Explained, Simply
At the risk of oversimplification, think of XP as a set of best practices (and tools) that strive for a better product through involved bite-sized input from both the developers and end-users of a system.
A defining trait of the XP method is how a "metaphor" (think prototype) is reverse-engineered from customer requirements through an incremental series of automated tests, with the most straightforward answer to user requirements as the daily end goal. This scenario calls for quick test-design-get feedback-test loops, which require almost constant contact with the customer.
Typically, teams following the XP principle take pride in shared ownership of the entire codebase in solution to customer needs. This is only possible when pair programming, refactoring code, frequent internal appraisals, and customer feedback come together to build a product that grows daily.
Extreme Programming Pros & Cons
The word extreme should not deter you from stepping foot into the ins and outs of XP. In fact, here's a scan at the upside and shortfalls of going the extreme route to programming.
It is true that extreme programming is not every developer, but it’s got a cult following.
Advantages:
- Involves the customer enough to guarantee product acceptance
- Pair programming improves the product while sharpening your team's skills
- The test-first approach reduces wasteful code writing
Disadvantages:
- Some developers prefer coding without hovering supervision. Expect inertia thereat
- Evolving customer requirements can get frustrating
- The XP approach is brittle. Deviate far enough from its principles and you may as well call the resulting approach plain Agile
Extreme Programming Practices
To uphold the concept of XP, certain practices, tools, and modes of thinking have to be in use. While modern software development teams tweak these to their will, you'll find the following activities at play across all who claim to follow the XP method.
- Planning
- Testing
- Designing
- Pair Programming
- Continuous Integration
- Customer (expectations) Management
Let's explore each of these activities, applicable solutions (tools), as well as best practices in a better light.
1. Planning With Jira
Being able to look at your project workflow from a bird's eye view is one of Jira's strengths. While The project templates therein will not be labeled as XP by default, you certainly need the quick sprints to function in workflows in your plans.
Setting up a Jira XP project as the center that your team reverts to comes in handy, and sets the ball in motion for other tool integrations and activities down the line. In tune with the XP mantra of daily planning and designing, sprints and Kanban boards in Jira help put ideas, actions, and associated progress in one viewport.
When getting started with extreme programming in Jira, it's advisable to map the methodology into action in stages. This way, you polish the implementation of a single activity and build on your success without overwhelming your team by stretching their attention to too many platform features.
Once everyone is at least comfortable participating in the planning stage in Jira, you can look at the testing phase and how (if) you can integrate test tools with it.
2. Testing with JUnit
Unlike conventional software development methodologies, XP starts the product focus from the testing stage. This requires manually writing tests against user requirements. You're probably thinking, "...but there's no system to test!" and you're right. The very first XP test for every new product is an automatic fail. Like any resolution process, failed tests prompt teams to create solutions such that iterative test runs give the green light.
When developing systems from the "test-first" stance, XP teams apply the simplest fixes for any error encountered. The least complicated code saves time and effort and allows full participation of even the least experienced developers of the crop.
Tool options for the testing activity in XP programming largely depend on the platform you're developing. Java developers will find JUnit easy as they can extend tests in the same language throughout the development cycle. On the other hand, web developers could benefit from Selenium or Testim automated cross-browser testing platforms for faster tests.
The logic is water-tight: when errors stop showing up, we'll have met all requirements. Every other provision that comes after that will mean incremental testing and patching. The loop goes on until the customer is satisfied.
3. Project Management With Maven
Every developer taking part in the XP experience should know the code as though they wrote the whole project by themselves. Maven is an excellent system to accomplish this. When you create a Maven project, a standard file structure is adhered to, making it easy for developers to navigate through the project.
More impressive is the ability to define clear project workflows from design, build, test, install, and other sub-nodes you see fit. As an example, your developers can use the latest test scripts by simply uploading changes made by QAs to their local maven files and dependencies.
Maven also makes onboarding extra developers when the project has already begun an easy process. The intuitive import process that reads configurations from maven files quickly catches new developers up with the latest changes.
4. Developers Working Together With CoScreen
The idea of pair programming cements code ownership while upholding high-quality software development standards. With plenty of software developers taking part in XP sessions from remote locations, it only makes sense that an application that mimics a coding-next-to-each-other situation.
CoScreen makes it possible for developers to partake in mob or pair programming exercises. In the context of XP projects, several members of the team can share a single central screen on which changes to the codebase are made from all angles.
There are so many benefits to such a setup beyond the XP viewpoint. Notably, when used by a team of varying skill depth, it's likely for the junior developers to improve quickly, having watched their seniors work on code live.
Whether you decide to combine efforts in one IDE once a week or more frequently, it's been found that over 90% of developers eventually favor pair programming to coding in isolation.
Pairing can be done as a one time ad-hoc or as a scheduled session.
5. Continuous Integration With Jenkins
Once developers start working together on fixing any failing XP tests, every effort should make its way to the main codebase. Continuous Integration (CI) is a practice that expedites this process.
Jenkins is an automation platform filled to the brim with plugins to help you build pipelines that execute on cue. The resulting automation comes in handy where several changes are being made to a single source of truth (your legacy code for instance.)
A perfect example of the XP development method would be integrating test tools with code versioning systems through Jenkins. The result is a robust process that recognizes new code, runs tests based on client requirement generated scripts, and integrates changes if (and only if) the tests succeed.
To effect, Jenkins acts as a software developer's Buttler.
6. Slack Communication With Customer
Keeping the customer in the loop is at the core of XP tendencies. You can imagine the difficulties that arise from keeping this up, with developers, in general, being somewhat less social than your average project manager. This makes Slack and other communication tools so necessary as appraisal systems.
In line with extreme programming, Slack's most useful feature would have to be the inclusion of the customer in chat channels for regular updates and feedback loops. The inclusion of the client is a way to manage their expectations while fine-tuning the scaling prototype to their expectations.
Is XP Worth Pursuing?
When placed next to its team programming counterparts (Waterfall, Agile, Lean, etc.), you may find extreme programming and variants more challenging for developers to acclimatize to... If you had just the cost of implementation to consider, then yes, XP makes a lot of sense mostly because there is less LOC effort than, say, an out-of-the-box Waterfall approach to the same product.
A defining factor in the success or failure of your XP attempt is the choice of tools made. It's not easy to dictate IDEs because you could suffer time losses with developers learning new environments.
As usual, there's always that one tool that, when included, irons out a lot of the kinks that pose potential deterrent risks as the project scales. In the context of this article, including CoScreen as the pair programming tool of choice bridges more than one activity or solution case.
Consequently, you can use CoScreen as a demo session tool with the customer, an internal meeting platform, and the standard technical effort collaboration window. This lowers costs, and friction (more like fatigue) caused by logging into too many tools in the name of conformation to a particular software development methodology.
We recently hosted on our podcast - XP enthusiast, Dragan Stepanovic.
If you are looking for a collaboration tool with a multi-user remote keyboard and mouse co-editing option check out CoScreen for free.
