The Engineering behind XTRF

If you’ve ever wondered how XTRF builds its flagship system, you are in just the right place to learn about it. Whether the questions you had were about the technology, the process, or the staff, they all will be addressed here.

The Technology

At its beginning, the platform was solely programmed in Java. PostgreSQL has always been the optimal solution for data storage. Some other technologies from the initial period of XTRF development included Maven, Spring, Hibernate, JSP, Struts and other frameworks popular in the first decade of the 21st century. After 2010, a move was taken towards an AJAX-like programming style with JBoss, Seam stack, JSF and RichFaces. Recently, the stack has evolved to enable REST API in the back end and Angularjs on the front end of the application. To make the picture complete, the coding language of choice for many XTRF backend developers is Scala.

Although some traces of the above mentioned early technologies can still be found in XTRF today, slowly but steadily they were replaced by new ones. JBoss may now be called WildFly, Java or PostgreSQL may now be in their versions 8 or 9, but XTRF always updates these critical components to stay abreast of the changes.

The Process

XTRF has a few processes in store that enable a smooth transition of any idea to a working feature. The basic ones include the following three:

  1. Design process
  2. Development process
  3. Delivery process

We want all new features to be inspired by our UserEcho forum – Product Development Ideas. Of course, we leave some space for strategic planning that constitutes a separate track for our development.

So, when an idea gets a lot or just enough traction among our clients, i.e. many upvotes and/or comments have been expressed around a topic, we notice it and decide something should be done about it. That moment of realization then becomes a development ticket in JIRA where more feedback and some preliminary thoughts are gathered. It is correlated to similar tickets to provide context. Such a ticket does not promise any development yet but opens the possibility to deliver something like that in the future. JIRA is a great piece of software to manage an application’s development. Our main project is simply called “DEV” and the most common ticket types are epics, stories, improvements and, sadly, sometimes bugs.

When a ticket makes it to the roadmap, its chances to be addressed are very high – it receives a sticker with a planned version. The design process starts shortly thereafter by consulting internal and external sources to study the topic. We are interested in understanding the needs of XTRF users, we learn what they’d like to experience as users. Information structure and interface actions follow the research phase. Feature specification, as well as UI mockups, are discussed with the developers before they commit to getting it done.

It can take the programmers one or more sprints to deliver a valuable piece of code. A sprint is usually 2 weeks and allows us to focus on more specific smaller tasks. Work progress is also more visible when done in smaller chunks. Every commit to the master codebase is first peer-reviewed and then tested by our Quality Assurance team.

When the time comes to release a new XTRF version, the code needs to be frozen for thorough automated and manual testing. This phase is called stabilization, because we want to make sure no undesired behavior occurs after an update of the system is out, up and running in our clients’ production environments. That is when our admins take the process over to install it on countless machines in the cloud and on your servers.

The Staff

Even the most sophisticated and modern technologies would not be worth much if it was not for the individuals who have the relevant skills and talent to use them. People who get the stuff done for you fall into the following 5 categories:

  • The Product Owner, yours truly, the one who keeps an eye on the processes.
  • User Experience Designers who do research, design interactions and draw mockups.
  • Backend Developers who program the invisible logic.
  • Frontend Developers who program the visible beauty.
  • Quality Assurance Folks who make sure that whatever got broken is scheduled for fixing.

The company’s headquarters are in Krakow, Poland. Most of us live in this historic city and have proudly graduated from one of its universities as engineers, psychology or language majors. Speaking Polish may be considered a superpower by many, but we have made it our goal to always start designing interface messages in English. Only then is XTRF localized by the collaborative work of our own clients, who know the tool inside out. Thanks to their efforts, the Home Portal is available in 10 languages, and the Client Portal and email templates add another 7 to that number.

Perhaps we all wish there was some magic powder that could be sprinkled on a keyboard and out of this magic a feature would emerge. Comments like “it is a small addition” or “it should be trivial for you” can oftentimes not be further from the truth. I tried to avoid being “too techy” when speaking about this process that delivers the software we know as XTRF to your computer. And if you got this far, I might have just succeeded.

Image
Łukasz Kaleta
PRODUCT OWNER
XTRF superhero who has the power to choose which features go in or get out of the system development pipeline. Began in 2009 as a support specialist and is now the product owner. Works with all departments on the system roadmap and sets priorities for current developments.
XTRF