Duetto employs an “agile” development methodology and uses JIRA extensively to track its release progress. The adoption of agile principles necessitates teamwork and collaboration, and it has enabled Duetto’s engineers to create new features for the GameChanger application more quickly, while being more responsive to the needs of the company’s customers.
I’ve detailed previously how our architecture choices like Amazon Web Services and MongoDB have made the GameChanger app more versatile and scalable, and how coding in Java makes the solution more efficient. For this post I’d like to describe how agile development and deployment processes make Duetto as nimble as any hotel technology provider or other leading software company.
The R&D organization is broken down into “scrum” teams that manage their backlogs in the context of our overall release goals. We tend to organize our work into quarterly release cycles. However, we release code to production every week, and large new features are released incrementally and often hidden from most users until they have been beta-tested by some.
This incremental approach not only reduces risk, but also allows Duetto to gather feedback and iterate on features rapidly while delivering value to customers as soon as possible.
[bctt tweet="With #Agile dev ops, @DuettoUnicorn is more responsive to customer needs" username="OptimizeDemand"]
Agile development in action
For example, we wanted to deliver a new feature to let hoteliers manage their overbooking levels from the GameChanger app. By approaching the feature release in a nimbler manner, our team was able to add value to the users’ experience sooner.
There are two parts to the overbooking feature. First, there’s what I like to call the mechanical part, which involves actually maintaining and sending overbooking values to a different system via an API. Second, there’s the algorithm part, which recommends overbooking levels based on various data sources, including past booking patterns.
For the sake of this example, let’s just say the project could take 12 weeks total to accomplish. It would take about six weeks to deliver the mechanical part and another six weeks to deliver the algorithm. A software company could wait the full 12 weeks before enabling the whole feature at once for a customer.
But in our incremental approach, we developed the mechanical part of the overbooking feature in that six-week time frame and delivered it to a subset of our customers so they could start using it and pilot-test it for us. Six weeks later, we released the algorithm, which was ready to start generating overbooking recommendations.
Over the course of the production cycle, Duetto’s product team had already gathered valuable feedback and the development team ironed out any bugs that came up with the feature.
Deployment the Duetto way
Our deployment process starts with a Jenkins build server for continuous integration. A key part of our development methodology relies on software engineers writing automated tests for both our back-end logic as well as the user interface (the latter uses Selenium and other front-end testing frameworks). We only release when 100% of our tests are passing, and we strive for 90% or greater code coverage for both Java and Javascript.
As mentioned before in my most recent blog posts, we rely on highly efficient multi-tenant application code. Over the years we have developed various philosophies of interacting with Big Data. For example, Duetto engineers:
- Always update data in batches rather than one row at a time, to avoid many round trips to the database, and
- Use streaming- and/or fixed-memory algorithms, as opposed to “hold everything in memory” whenever possible. This limits our exposure to unbounded resource consumption.
We also use JProfiler frequently on our most important and expensive operations to optimize our code analytic pipeline. By regularly monitoring at the outer level (e.g. determining which parts of the system are taking the most aggregate time) and the low level (which of the innermost parts of the application are the most expensive), we continually and incrementally improve the performance and throughput for everyone.
For instance, we recently discovered that when our largest customer was fully online, some paths through our code were running slowly and could be optimized better. We made those performance improvements within a few weeks.
Finally, just as we strive to avoid Single Points of Failure in our hardware layer, we also avoid SPOFs in our development team. Although we are a relatively small group, we try to ensure that each area has at least two code owners and we ensure that all code changes are peer-reviewed. We’re currently using Phabricator, which is a code review tool initially developed at Facebook, and Github.
Bringing a New Approach to Integrations in the Hotel Industry