Vladimir Filipchenko
(Photo : Vladimir Filipchenko)

Release Driven Development is gaining traction in software development with its approach focusing on regular code delivery to end users. Master developers like Vladimir Filipchenko provide detailed information about the methodologies, technology, and how to apply this approach at work. Vladimir is a highly accomplished backend engineer with a wealth of experience in application development and maintenance. With a notable career spanning over a decade, Vladimir has made significant contributions to renowned companies in the software industry, including Google and Fitbit to name a few. His expertise in programming languages, databases, and distributed systems has positioned him as a trusted resource for designing, developing, and troubleshooting complex backend systems. 

Could you please explain in brief about the Release Driven Development approach?

Release Driven Development aims to achieve frequent and stable releases by emphasizing iterative development. It combines various techniques and cultures already popular in the IT world. By releasing software regularly, teams can provide incremental value to users and maintain a steady cadence of improvements and features. Thus, Release Driven Development is gaining prominence in the IT sector.

The existing Scrum methodologies already utilize Release Driven Development. What is the difference?

Yes. Release Driven Development will not replace existing methodologies like Scrum. Instead, it complements them. The approach acts as an additional plugin to the existing software development practices. While methodologies like Scrum focus on iterative development, estimation, and planning, Release Driven Development emphasizes the release and maintenance aspects. It encourages teams to evaluate how they will successfully release and support their solutions involving complex and decoupled systems.

What is the background of Release Driven Development?

I have more than 13 years of experience as a software engineer. I've noticed that one of the main challenges for engineering teams is a lack of understanding of work impact on end users, businesses, and customers. Engineers must recognize their solutions primarily target business needs and are meant to solve customer problems. Programming languages, frameworks, and methodologies are tools for achieving business success. Frequent software releases help bridge the gap between businesses, clients, and engineers, minimizing discrepancies and fostering collaboration.

Can you list some of the advantages of Release Driven Development?


Release Driven Development offers several benefits like early visibility of results by delivering features incrementally with a well-estimated plan. It allows for quicker validation of assumptions and provides additional visibility to the business, product managers, and other stakeholders. Another advantage is that engineers can get faster client feedback as frequent software releases enable companies to respond quickly to market demands and changing user needs. The ability to gather client feedback based on the initial results of an upcoming feature can help adjust the overall direction, ensuring the solution meets user expectations and business goals.

Release Driven Development also helps to regularly release and introduce new features, functionalities, and enhancements to the software. Users can benefit from these additions, improving their overall experience, productivity, and satisfaction. Moreover, it also addresses bugs and issues and allows faster fixing, leading to a more reliable and stable software product.

How can one apply this approach at work?

Applying Release Driven Development involves two main directions- engineering and organizational. From an engineering perspective, it's crucial to build a stable release CI/CD pipeline that supports the end-to-end release process. By establishing a well-defined and automated release pipeline, teams can ensure that each release is reliable, consistent, and ready to be published. I have written an instructive article about building a Release Driven Development pipeline for a newly created project. 

Additionally, engineers need to shift their mindset towards embracing a culture of reliability, resilience, and continuous improvement in software systems. Taking inspiration from Site Reliability Engineering (SRE) principles, teams should focus on proactive monitoring, incident response, and effective incident management. 

From an organizational perspective, one must ensure that each engineering team can effectively divide big features into predictable outlined pieces. It involves breaking down complex tasks into smaller, manageable work units and estimating their effort accurately. By doing so, teams can plan and prioritize their work effectively, allocate resources efficiently, and deliver value incrementally.

Furthermore, if your organization hasn't already adopted a DevOps culture, now is a perfect time to do so. DevOps focuses on streamlining the software development and delivery process, enhancing collaboration between development and operations teams, and achieving faster and more frequent releases. The "You build it, you own it" principle of DevOps aligns well with Release Driven Development, as it encourages engineers to take ownership of the entire software lifecycle, from development to deployment and maintenance.

By addressing the engineering and organizational aspects, teams can successfully apply Release Driven Development at work. 

Who can use Release Driven Development?

Any team or organization, regardless of size, can adopt Release Driven Development. However, it is important to note that Release Driven Development may not be the best fit for streams like infrastructure management or legacy software maintenance. For example, when a team is responsible for maintaining old software nearing its end of life, the benefits of frequent releases may be minimal. 

ⓒ 2024 TECHTIMES.com All rights reserved. Do not reproduce without permission.
* This is a contributed article and this content does not necessarily represent the views of techtimes.com
Join the Discussion