XFAIR Software – How XFAIR manages to stay flexible in its solutions

Mr Terry, you and your team are essential for XFAIR’s ability to adapt to the versatile demands our customers have. What’s the range in changes that you make for the different types of events?

We have many types of changes we do for different customers for the same event or different events. It can be something as simple as styling the website in the customer’s CI (Corporate Identity) e.g. from blue to red or it can be as big as writing a new software. For instance, last year for one customer we had to write a completely new voting software that was only used for one event. Sometimes it can be in between, where we just write a new module, whether that’s in the admin tool, the registration or indeed one of the mobile applications. We might even enhance one of the modules to have new functionality, you know. This depends on what the customers require for that one event.

For sure, there’s a balance between what the customer wants and what we can do for them. As I said, certain things, like small little things, maybe take 15 minutes to do – i.e. styling – and we generally will do them without any additional management of the system. Bigger requirements resulting in bigger changes within the software demand more detailed specification and documentation as well as approval processes. Not just from the customer’s side regarding payment as these changes naturally have an impact on the cost of our services, but also from our side whether the new development will be useful for other customers or only this individual customer. This whole balance is something I have to maintain and discuss with the different parties about how big the work is and if we can fit it in with our current resources. Of course, XFAIR has a roadmap of where we want to take our development each year and we have to fit all our customer requirements into that.

What do you focus on the most: maintaining and evolving the existing programs or developing new solutions and branching out the portfolio? How do you keep up with the newest IT-security requirements?

Well, to answer the first part of the question: as I mentioned previously, it’s all about keeping the balance. We have a roadmap of what we want to achieve this year, of course within that we also have some time assigned for customer requirements and enhancing the software as per individual customer’s needs, but generally we want to expand our portfolio.

Whether that’s a new solution as in a new application or whether that’s updating a certain application either to make it more user-friendly or look and feel better; whether it’s to provide more functionality for individual modules or whether it’s a brand new module within the application. That balance of creating new and better solutions for our customer is obviously offset with any customer requirements and individual issues that they have during the course of their work with us. Of course, we have many customers with many different events so it can be quite challenging at times. However, it is part of my job to find that balance between how much we are going to do for customer specific enhancements and looking at the aforementioned roadmap concerning new developments.
Obviously keeping up with the newest IT-Security requirements is a massive topic with regards to IT-security especially for our ISO certification that we currently have. IT-security is a big part of the ISO certification within the development team. Yes, it’s certainly a challenge keeping up with the newest standards but we’re nothing if not determined to rise to that challenge.

How many people are currently working on the mobile applications and the web based solutions? What are the biggest challenges working in such an international team and do you consider code as your common language?

Well this is a really interesting question, because I had to think about this. A mobile application is not just requiring a mobile app developer. Mobile applications, certainly the ones we have, interact with a database. Which requires web services to be developed to interact between the app and the database. This web service is written by a web developer. So if we have to write a new module for one of our apps it doesn’t just require a mobile app developer, it requires an EMS-developer, because that’s the name of our software, or a C-Sharp developer, because that’s the language the code is written in for the web base. Therefore, it’s very difficult to put it as ‘what is your mobile development team and what is your web application development team’.

Within our team, we have our iOS developer who comes from an only iOS background so does only iOS developing. Our android developer comes from a web background and therefor has the ability to develop the android app as well as the web services. So they can do both whereas our iOS development cannot. But me, and two other web developers within our team can write web services. So when you say ‘Oh, we have a new requirement for the mobile app’ it will not only require one or two people, the iOS and Android developers, it could also require a web developer as part of the project. We are all one team providing one core functionality, which is to make event software for our customers. This team consists of seven people. There’s myself, four senior developers, one junior developer and one software tester. Of those four senior developers, we have one android, one iOS and two for the C-sharp development, which I myself work with as well.

The biggest challenge for me has not anything to do with the team members. It’s balancing the requirements of the customers with those of the business for our roadmap, as I mentioned earlier. The international team concept – again interesting, but the common language is not code. This is something slightly different, because there are many code languages. I, for example, would not be able to fully understand the iOS Code, because I’m not an iOS developer. I would certainly be able to read some of it, but of course not all of it. All code regardless of whether it is iOS or the android (JAVA or Kotlin), our web services (C-Sharp), or the database (SQL) are different languages. All these languages are written in English.

The challenging part for me is to ensure that the code is written to a certain standard and for it to be readable and understandable to another developer, which means that code needs to be commented correctly. That is why one of our internal processes and development standards that we have, is that all comments within the code are written in English because all developers speak it regardless of where they are from. Developers in general have to be able to speak English because of that fact. It’s not because the code is one language, as there are many different code types and many different languages within the code and a person who knows one language doesn’t know another language. It’s the same with spoken language. The common denominator is the fact that when writing the code, you write English.

The management of the international team isn’t really an issue. Of course there will be conflicts between different people, but these conflicts can also exist between people of the same nationality. It’s very much the case of English is the common language, this is how we develop.

Are you interested in becoming a part of the XFAIR development team and help create innovative and flexible solutions for our customers? Then please don’t hesitate to contact us via our application form – we’re looking forward to hearing from you!