Sustainable software enables you to deliver changes to the customer more quickly with a lower likelihood of bugs, a decrease of the total cost of ownership of applications, and increased business agility. Practices from Kanban, Scrum and eXtreme Programming can be used to develop sustainable software. It’s possible to verify the software's sustainability using a combination of automated analysis of source code, expert review of technical artifacts, and a comparison with benchmark data.
Joost Visser, CTO at Software Improvement Group and author of the book "Building Maintainable Software", spoke about agile development of sustainable software at the Agile Consortium Belgium 2018 conference where he presented the Ventouris case.
InfoQ interviewed Joost Visser, Johan Lybaert, director agile software factory at Cegeka, and Tom Dufour, leader of the Ventouris development team at Cegeka, about developing and verifying sustainable software with agile.
InfoQ: What is "sustainable software"?
Joost Visser: Software has the interesting property that when you make changes to it, either fixing bugs or adding features, the structural quality of the code will typically decline with every change. Especially when there is time-pressure, and there always is, then developers are pushed to compromise on structural quality.
But changing software too hastily is self-defeating. Because lower quality code is more difficult to change. This leads to a vicious cycle of hasty changes that decrease quality which increases time pressure even further. Clearly, this way of evolving software is not sustainable.
So for software, "sustainable" actually means "evolvable". The ISO standard 25010 for software product quality uses the term "maintainable" exactly for this quality characteristic of being easy to change.
Johan Lybaert: Sustainable software to me means that developers are still willing to work in the application code without having the frustrations of old frameworks, technical debt, lack of automated tests, duplicate code, dead code, misleading comments, ToDo’s, …
Tom Dufour: To me, it is software that can be understood quickly and can be edited easily.
InfoQ: What are the benefits that sustainability brings?
Lybaert: One benefit is a continuous decrease of the total cost of ownership of the application. If the normal average lifetime is 7 to 10 years, extending it due to the sustainability with another 10 years is really beneficial for the owners of the application.
Visser: Lower total cost of ownership (TCO) is a definitely a major benefit. But let’s not look at cost only. Sustainability also pays back as increased business agility. Software that is easy to adapt to business requirements can be an important differentiator in a competitive market.
Dufour: A benefit of sustainability is to be able to more quickly deliver changes to the customer with a lower likelihood of bugs.
InfoQ: How do you apply agile to develop sustainable software?
Dufour: With Ventouris, we provide a web-based software solution for 9 different Belgian Social Security Funds, to automate the administration of independent professionals and companies. While already running smoothly for 10 years, there are new requirements coming in all the time, often short-notice legal changes, that we quickly have to adapt to.
To support this, we borrow the best practices from Kanban, Scrum and eXtreme Programming to suit our needs; for instance, we focus heavily on Continuous Delivery, Test Driven Development and Pair Programming. We aim to always be very critical of our code and discuss proper design with our pair & colleagues: aim for what the code really needs and why.
Lybaert: In order to obtain sustainable software, we agreed a continuous improvement budget of 1000 man days in order to guarantee a longer lifetime of the application with a minimum of 8 years. This budget was the driver for keeping up with the latest java versions, Spring, Hibernate, Wildfly upgrades …
The ownership of testing is with everybody in the team (developers and analysts) and not with an independent test team. The result is writing the code the first time right.
InfoQ: How did you verify that the software code for Ventouris is sustainable?
Visser: Since Ventouris is such an important system, and committing to its future development is such an important decision, we were asked to take a very thorough look at its sustainability. In fact, we were asked to answer 23 detailed questions about the maintainability and security, as well as how future-proof it is. To answer these questions, we followed a proven verification process where we combine automated analysis of source code with expert review of technical artifacts and comparison with benchmark data.
For example, for Ventouris, we found that the quality level was about 3 stars on our 5-star rating scale, which is significantly better than average for systems of comparable age and size. Also, we established that the ratio of test code versus production code was more than double the average that we see in the industry.
So, through a combination of source code analysis, security inspection, architecture review, and cost estimation, we quantified and judged the system on all relevant aspects, ranging from security vulnerabilities to horizontal scalability, dependency on third-parties and external services, and very importantly flexibility to adapt to future requirements. All in all, taking answers to all detailed questions into account, we were able to conclude that Ventrouris is future-proof on a 10-year horizon.
Dufour: We aim to ensure that the effort to make changes in a certain area doesn’t increase or becomes more error-prone. This is continuously evaluated by all our developers.
Whenever new functionality is added, we perform a Pair Model on the story, where one or more developers will dig into the code to identify complexities, dependencies etc., prior to implementation, and to design the proper solution. Here we also evaluate if it’s more efficient to refactor certain areas first prior to implementation of additional functionality.
Larger topics for refactoring are evaluated and prioritized, to be taken up as epics and stories alongside the functional stories.
Lybaert: In the Agile Software Factory of Cegeka, all teams have a bi-weekly reporting to monitor whether we’re still doing the right things right within the agreed budget and timeframe. They are filling in a Progress report – PMI style reporting on customer, timing, budget, scope, dependencies & quality. This report is made available towards the software factory management & the customers. We value the transparency, openness of the status of all project activities. It includes reporting on the sprint, the agreed SLA’s, the defects…
The monitoring of the application is happening from different perspectives on a permanent basis. The Ventouris team has implemented a continuous build & deploy environment in which the automated tests are running by each check-in of new code. If the code is broken the information radiator is indicating that it must be claimed to be fixed with the highest priority. With a test coverage of more than 100%, the team can avoid regression. The Ventouris team is using "New Relic" as application monitoring tool for the performance follow-up on each of the SLA per transaction type.
At Ventouris, we work with 2-week sprints, where at the end of the sprint, we deploy to the "Acceptance" (ACC) environment. Our customers validate the new functionality on this environment, and a week after the ACC release we release to Production.
We’ve been in this steady pace for many years now. The fact that we’re able to release such a large application successfully every 2 weeks without regression and acceptance of the 9 customers within the week, is a clear indicator that our software is still sustainable.
InfoQ: What can agile teams do to write code that is sustainable?
Lybaert: Be very disciplined in applying all the XP practices, avoiding technical debt, keeping a high test coverage (> 90%). Making sure that you have good and open transparent relationships with your customers to allow the team to do the right things right on continuous improvement actions. Pair programming is key to keep the team disciplined in doing the right things right (TDD, refactoring, DDD ...).
Dufour: Discuss on proper design and build common knowledge: for larger Epics, we have a proper kick-off to map out the high-level design, we have regular code reviews to review parts of the code and share best practices, we have regular teaching sessions to educate the team on the complex functional context of Ventouris, upcoming legal changes ... It’s an iterative process where you look for good practices, try them out, evaluate them, modify them if needed and keep repeating that cycle. The quest for sustainable code is never finished.
Visser: Writing code that is sustainable actually does not require magic or rocket science. Very important pre-conditions are discipline, common sense, and a clear set of guidelines for the team to share and rally around. Such guidelines can include simple things like not writing methods larger than 15 lines, not duplicating code larger than 6 lines, and keeping automated test coverage at 90%. And also stakeholders outside the team should embrace the fact that not compromising on structural quality today is essential to sustain agile and fast-paced development for many years to come.