Extreme programming (XP) is an agile software development framework that aims to produce higher quality software and higher quality of life for the development team.
In 2003, one of the first controlled studies highlighted the benefits of extreme programming (XP) (Abrahamsson, 2003). This study showed how the extreme programming technique improved accuracy by 26% and productivity by 12 locs/hour.
And that was in 2003.
Today’s development methods are considerably more efficient. Yet, they don’t fully consider the role and importance of security. So, what’s the point of an ultra-agile development process if its just going to turn up bugs later, and then require the team to cycle back, patch, re-launch, etc.
A better alternative? Securing code as early as possible.
Below are some techniques adopted from the extreme programming approach that benefit application security.
Techniques Adopted From Extreme Programming (XP)
While there’s endless ways to integrate security into your SDLC, we’ll be focusing on three techniques:
- Pair Programming
- Continuous Integration (CI)
- Test-First Programming
Pair programming is having two developers work at the same workstation. They’ll write, debug or explore code together, taking turns doing tasks. As one developer works, the other watches to observe, learn and support.
- Removes knowledge silos to increase team resiliency
- Collective code ownership can increase developer engagement with the project
- Reduces the incidence of bugs through continuous code review
- Efficiency gains through a short feedback loop, more representative of a live code review
- Increased learning and opportunities for communication
- Risk of disengagement or ‘watch the master’ behavior. This happens when one developer takes primary control over the project and the other watches, without practicing or learning.
- Communication breakdowns can happen when the developers aren’t talking through their processes, or they disagree on an approach for building or debugging
Continuous Integration (CI)
While not part of programming, continuous Integration is a growing favorite for teams that are scaling their code deployment and provides some great benefits to ensure security. In continuous integration, smaller code changes are immediately tested and added to a larger code base. It’s an automated process where code changes from multiple contributors are merged into a single software project. Usually, continuous integration is also adopted alongside continuous delivery (CD), so that code is tested and shipped out in small, quality batches.
- Automated integration to immediately test code
- Opportunity to catch and fix issues earlier
- Requires fewer changes to be incorporated after the build
- Takes discipline to commit to fixes as they’re found
- The possibility for flawed tests. This potential increases when tests are poorly written, outdated or not suitable for a particular app
- Issues with version control. Most CI/CD processes are developed for a specific version of an application, and would need to be reconfigured for new versions
Test-first programming (also called test-first development) works in a cyclical process of automated unit tests to identify issues with code before writing it for production. The steps of this process are:
- Write a failing automated test
- Run failing test
- Develop code that allows it to pass the test
- Run test
- Reduces feedback cycle for developers to identify and resolve issues
- Decreases number of bugs that are introduced into production
- Steep learning curve to understand and use the process
- Requires more up-front coding than other development methods
- May be difficult to get buy-in from senior management if they are resistant to change or do not understand the benefits of the ‘backward’ approach
Extreme programming is one of the most specific frameworks, and can be great for any company that is considering adopting an agile methodology. However, security cannot be forgotten in the process. Security should be proactively considered in the methods that your organization adopts. Regardless if you are choosing to use experimental programming or an alternative method, you can reflect on the options above to imagine how security can be best integrated into your SDLC.
Abrahamsson, P., 2003. Extreme programming: first results from a controlled case study. Proceedings of the 20th IEEE Instrumentation Technology Conference (Cat No 03CH37412) EURMIC-03,.
Erdogmus, H., Morisio, M., & Torchiano, M. (2005). On the effectiveness of the test-first approach to programming. IEEE Transactions on Software Engineering, 31, 226-237.
Ge, X., Paige, R., Polack, F. and Brooke, P., 2007. Extreme Programming Security Practices. International Conference on Extreme Programming and Agile Processes in Software Engineering, [online] 4536, pp.226-230. Available at: <https://link.springer.com/chapter/10.1007/978-3-540-73101-6_42> [Accessed 16 September 2021].
We help DevOps teams at SaaS companies to build confidence in their application security.Discover PTaaS
Was this article helpful?
Share This Post