This website uses cookies to better the user experience of its visitors. Where applicable, this website uses a cookie control system, allowing users to allow or disallow the use of cookies on their computer/device on their first visit to the website. This complies with recent legislative requirements for websites to obtain explicit consent from users before leaving behind or reading files such as cookies on a user’s computer/device. To learn more click Cookie Policy.

Privacy preference center

Cookies are small files saved to a user’s computer/device hard drive that track, save, and store information about the user’s interactions and website use. They allow a website, through its server, to provide users with a tailored experience within the site. Users are advised to take necessary steps within their web browser security settings to block all cookies from this website and its external serving vendors if they wish to deny the use and saving of cookies from this website to their computer’s/device’s hard drive. To learn more click Cookie Policy.

Manage consent preferences

These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
Cookies list
Name _rg_session
Provider rubygarage.org
Retention period 2 days
Type First party
Category Necessary
Description The website session cookie is set by the server to maintain the user's session state across different pages of the website. This cookie is essential for functionalities such as login persistence, ensuring a seamless and consistent user experience. The session cookie does not store personal data and is typically deleted when the browser is closed, enhancing privacy and security.
Name m
Provider m.stripe.com
Retention period 1 year 1 month
Type Third party
Category Necessary
Description The m cookie is set by Stripe and is used to help assess the risk associated with attempted transactions on the website. This cookie plays a critical role in fraud detection by identifying and analyzing patterns of behavior to distinguish between legitimate users and potentially fraudulent activity. It enhances the security of online transactions, ensuring that only authorized payments are processed while minimizing the risk of fraud.
Name __cf_bm
Provider .pipedrive.com
Retention period 1 hour
Type Third party
Category Necessary
Description The __cf_bm cookie is set by Cloudflare to support Cloudflare Bot Management. This cookie helps to identify and filter requests from bots, enhancing the security and performance of the website. By distinguishing between legitimate users and automated traffic, it ensures that the site remains protected from malicious bots and potential attacks. This functionality is crucial for maintaining the integrity and reliability of the site's operations.
Name _GRECAPTCHA
Provider .recaptcha.net
Retention period 6 months
Type Third party
Category Necessary
Description The _GRECAPTCHA cookie is set by Google reCAPTCHA to ensure that interactions with the website are from legitimate human users and not automated bots. This cookie helps protect forms, login pages, and other interactive elements from spam and abuse by analyzing user behavior. It is essential for the proper functioning of reCAPTCHA, providing a critical layer of security to maintain the integrity and reliability of the site's interactive features.
Name __cf_bm
Provider .calendly.com
Retention period 30 minutes
Type Third party
Category Necessary
Description The __cf_bm cookie is set by Cloudflare to distinguish between humans and bots. This cookie is beneficial for the website as it helps in making valid reports on the use of the website. By identifying and managing automated traffic, it ensures that analytics and performance metrics accurately reflect human user interactions, thereby enhancing site security and performance.
Name __cfruid
Provider .calendly.com
Retention period During session
Type Third party
Category Necessary
Description The __cfruid cookie is associated with websites using Cloudflare services. This cookie is used to identify trusted web traffic and enhance security. It helps Cloudflare manage and filter legitimate traffic from potentially harmful requests, thereby protecting the website from malicious activities such as DDoS attacks and ensuring reliable performance for genuine users.
Name OptanonConsent
Provider .calendly.com
Retention period 1 year
Type Third party
Category Necessary
Description The OptanonConsent cookie determines whether the visitor has accepted the cookie consent box, ensuring that the consent box will not be presented again upon re-entry to the site. This cookie helps maintain the user's consent preferences and compliance with privacy regulations by storing information about the categories of cookies the user has consented to and preventing unnecessary repetition of consent requests.
Name OptanonAlertBoxClosed
Provider .calendly.com
Retention period 1 year
Type Third party
Category Necessary
Description The OptanonAlertBoxClosed cookie is set after visitors have seen a cookie information notice and, in some cases, only when they actively close the notice. It ensures that the cookie consent message is not shown again to the user, enhancing the user experience by preventing repetitive notifications. This cookie helps manage user preferences and ensures compliance with privacy regulations by recording when the notice has been acknowledged.
Name referrer_user_id
Provider .calendly.com
Retention period 14 days
Type Third party
Category Necessary
Description The referrer_user_id cookie is set by Calendly to support the booking functionality on the website. This cookie helps track the source of referrals to the booking page, enabling Calendly to attribute bookings accurately and enhance the user experience by streamlining the scheduling process. It assists in managing user sessions and preferences during the booking workflow, ensuring efficient and reliable operation.
Name _calendly_session
Provider .calendly.com
Retention period 21 days
Type Third party
Category Necessary
Description The _calendly_session cookie is set by Calendly, a meeting scheduling tool, to enable the meeting scheduler to function within the website. This cookie facilitates the scheduling process by maintaining session information, allowing visitors to book meetings and add events to their calendars seamlessly. It ensures that the scheduling workflow operates smoothly, providing a consistent and reliable user experience.
Name _gat_UA-*
Provider rubygarage.org
Retention period 1 minute
Type First party
Category Analytics
Description The _gat_UA-* cookie is a pattern type cookie set by Google Analytics, where the pattern element in the name contains the unique identity number of the Google Analytics account or website it relates to. This cookie is a variation of the _gat cookie and is used to throttle the request rate, limiting the amount of data collected by Google Analytics on high traffic websites. It helps manage the volume of data recorded, ensuring efficient performance and accurate analytics reporting.
Name _ga
Provider rubygarage.org
Retention period 1 year 1 month 4 days
Type First party
Category Analytics
Description The _ga cookie is set by Google Analytics to calculate visitor, session, and campaign data for the site's analytics reports. It helps track how users interact with the website, providing insights into site usage and performance.
Name _ga_*
Provider rubygarage.org
Retention period 1 year 1 month 4 days
Type First party
Category Analytics
Description The _ga_* cookie is set by Google Analytics to store and count page views on the website. This cookie helps track the number of visits and interactions with the website, providing valuable data for performance and user behavior analysis. It belongs to the analytics category and plays a crucial role in generating detailed usage reports for site optimization.
Name _gid
Provider rubygarage.org
Retention period 1 day
Type First party
Category Analytics
Description The _gid cookie is set by Google Analytics to store information about how visitors use a website and to create an analytics report on the website's performance. This cookie collects data on visitor behavior, including pages visited, duration of the visit, and interactions with the website, helping site owners understand and improve user experience. It is part of the analytics category and typically expires after 24 hours.
Name _dc_gtm_UA-*
Provider rubygarage.org
Retention period 1 minute
Type First party
Category Analytics
Description The _dc_gtm_UA-* cookie is set by Google Analytics to help load the Google Analytics script tag via Google Tag Manager. This cookie facilitates the efficient loading of analytics tools, ensuring that data on user behavior and website performance is accurately collected and reported. It is categorized under analytics and assists in the seamless integration and functioning of Google Analytics on the website.

How Extreme Programming Helps Us Make Extremely Great Software

  • 17598 views
  • 9 minutes
Vlad K.

Vlad K.

PHP Developer

Dmytro H.

Dmytro H.

Backend Development Lead

Share

When Kent Beck joined the C3 project at the Chrysler corporation in 1996 to do performance tuning on their payroll system, he felt the need to refine the development methodology adopted in the team. To do that, he took the best practices used in the development industry for the last 35 years, and tried to unite them and take them to the ’extreme level’. That’s how the Extreme programming (or XP) software development methodology was born.

Twenty years later XP is adopted in a lot of development companies and keeps evolving and proving itself as a reliable methodology for creating successful products. Nowadays XP is one of the most solid-standing approaches in software communities, although some of its practices have been significantly reviewed, updated or redefined as corollary.

Extreme programming paradigm is aimed to help people make higher-quality software in a more productive way, and that’s why we at RubyGarage are following that paradigm as well. And to understand how do we do it, it’s important to start with explaining the four basic XP activities.

  1. Coding. Code is the main part of the product. Everything can be implemented through the code only, so writing effective code becomes a priority #1. One of the XP principles explains that the product changes should be incremental: you’d better make small releases once per three weeks rather than one big release in a year.
  2. Testing. The more tests you do, the more flaws you can eliminate. To adopt this approach, XP offers to write and run:

    • unit tests to confirm the validity of every piece of written code before proceeding to implementing the next feature
    • acceptance tests to check if the code satisfies the customer’s product requirements
    • integration tests to detect troubles related to the interaction of software modules
  3. Listening. Since products are done for customers, not for developers, the team should clearly understand the users’ needs. Brought to extreme importance, the customer feedback is critical for learning and making changes quickly. Thus, extreme programming methodology also dedicates a lot of attention to communication between developers and customers. That is done through making at least one product user always available for reaching and consulting.
  4. Designing. Design, if taken from the programming perspective, organizes the logic of a product and allows to avoid the excessive complexity. Not only it allows to get rid of system dependencies, but also helps to effectively deal with changes (which are inevitable in product development and thus are embraced in extreme programming methodology).

To turn all those activities into an effective workflow usable for product development, multiple practices were developed. In this post we’d like to share the practices we use in our everyday routine. Here they are:

Pair programming

Agile software development - Pair Programming

To write the code in the most effective way, we follow the pair programming practice, when one person writes the code and thinks about the smallest details, while the other one focuses on the overall picture and reviews the code.
The developers usually switch their roles within an hour, and such pairs are not predefined — people are pairing in different ways for each new task. That allows to guarantee that all developer team members are familiar with the code, know the current progress, can learn from others and be involved in planning meetings.

While it's primarily helpful for writing a better, defect-free code, pair programming has additional advantages: it helps to build a strong team, make developers more satisfied of their work and consider a bigger variety of solutions before solving a problem.

Around 20% of all code-related tasks at RubyGarage are done through pair programming; others are usually too quick, too typical or too simple to involve two developers. The pair programming practice is often used for more complicated goals, when a few decisions should be considered and discussed to find the best one.

Planning game

In general, the planning game practice is a practice of making meetings before each sprint to plan the near-term releases and current tasks for the developers. A few ways are offered to do that; we stick to the planning poker variation, explained in another Agile methodology called Scrum.

The basic idea behind planning poker is to simultaneously unveil everyone’s thoughts and expectations on how complex is a task and thus how much efforts it requires to be done. That allows ’players’ to avoid becoming biased after the more experienced developer has revealed his own thoughts, which would otherwise happen in case of turn-based poker.

The complexity of a task is measured by story points. One story point is an arbitrary measure defined and negotiated previously by the team; it represents estimated efforts required to make some typical or familiar task within the current project. The idea behind story points is that different developers may solve the same problem in the same way, but it may take different time for them to do that depending on their competency and experience. Thus, measuring required efforts is more effective than measuring time in planning poker.

So here’s what the whole process looks like:

A product manager explains the task to be estimated and answers the related questions. Then every developer makes an estimate and takes the corresponding card showing a total number of story points the task requires in order to be done; nobody can see what cards were taken. (A special deck was designed for that matter, however, usual notes can be used or a smartphone with an app for that). Then everyone shows the cards taken at the same time.

Software development Planning game

The ones who had the highest and lowest estimates then explain their decisions. Often, if the discussion starts taking too much time, the project manager (or a moderator, if there is any), can use the timer to cease the negotiation.
After that the developers make new estimates considering the new arguments and info, take new cards and everything starts again until the consensus is found.

A study in 2007 made by Haugen and his colleagues had shown that this approach is pretty effective: after making a few experiments with planning poker practice it was found that the final estimation perfectly corresponded to the real time the task required to be done.

Test driven development

As written before, to provide the best quality for a product and guarantee its reliability and durability, it should be tested a lot. The test driven development approach offers to follow an extreme strategy when writing a new piece of code: the developer should write as many tests as possible until he can no longer think of ways to break the written code.

To write effective tests a developer follows the next short instruction:

  1. Set up the environment, i.e.,provide code with necessary data before testing it.
  2. Execute the code (run the test).
  3. Verify the results. Note: the code should not simply work, but behave as expected.
  4. Clean up the environment to be sure next tests are not affected by previous ones.

The algorithm for the whole TDD approach is simple. To write a new piece of code, the developer makes the next cycle over and over again, often referred as to ‘Red -> Green -> Refactor’:

  • Red: Defines the behavior he wants to implement next and then writes a test (also with as few lines of code as possible), which should fail unless the required behavior is present.
  • Green: Writes enough code just to make the required functionality work and pass the previously written test. Fixes that code if needed until the test is passed.
  • Refactor: Improves the code to make it readable and having no duplication and code smells without changing its current behaviour. After each small change the previously written test should be run to avoid errors.

Refactoring here plays a role that can be hardly underestimated. Without this practice, your product may appear unstable, have code smells and technical debt resulting in potential problems with further development and improvement of the software. Refactoring, if done according to the XP methodology, allows to avoid any potential problems related to scalability, reliability and security of the product in future.

Continuous deployment

The product team should deploy the new version of the software frequently in order to be ready for sudden changes (and thus new requirements). In RubyGarage we have sprints (1, 2 or 3 week long), and the new version is released at the end of each sprint. All members are always working with the latest version of the product to avoid integration problems.

Since software is updated frequently, and the implemented changes usually correspond to the current requirements, sometimes there might be troubles with adding new features to the existing product architecture. To avoid that, code refactoring should be done every now and then to make that architecture simpler and thus more flexible, extensible and scalable for new changes. At RubyGarage, we go further and have refactoring as a part of the test driven approach to avoid the need for refactoring in the future. Thus, the code gets refactored even before it is merged with the code on the production server.

Shared understanding

To make the code clear and readable for everybody, extreme programming methodology offers to have a set of rules accepted within a team explaining the coding standards. We in RubyGarage stick to the community-driven code style guides written for most tools that we use, like Ruby, Ruby on Rails, PHP, Symfony 2 and CoffeeScript.

Another practice related to shared understanding of the product is collective code ownership, when all the team members can review and edit any part of the product code, which makes all the team responsible for the final result. In GitHub it is achieved by the requirement for all team members to review each opened pull request and approve it.

Not only this is a great team-building practice, but also an effective way to speed up the development process, since any error can be fixed by any developer in the team.

If the task seems to be somehow complex, it means you can simplify it and break into smaller tasks. The smaller the task, the easier it is to write the corresponding code and test it. As extreme programming methodology puts it, «Simple is best».

Sustainable pace

Finally, if we’re speaking about making the team work more productively, it’s important to provide developers with enough time to rest. Thus, they should not work more than 40 hours per week. If that happens, the next week such person should work less hours to balance such overtime.

All that practices, when implemented, help to keep the sustainable pace and move on in a very dynamic and productive manner. Frequent code-merge, refactoring and collaborative way of working require developers to be always alert and stick to the project’s schedule.

For the RubyGarage team the extreme programming practices have proved its effectiveness long ago. In fact, some of these practices were adopted in most of the companies, so don’t be surprised if you find out that others take advantage of, say, pair programming or test driven development — it’s indeed the finest ways to create working and reliable software!

CONTENTS

Authors:

Vlad K.

Vlad K.

PHP Developer

Dmytro H.

Dmytro H.

Backend Development Lead

Rate this article!

Nay
So-so
Not bad
Good
Wow
2 rating, average 5 out of 5

Share article with

Comments (0)

There are no comments yet

Leave a comment

Subscribe via email and know it all first!