Using the example of the WRISTBAND event app, I will tell you how to boost up the hard skills of developers and smoothly test new features right while developing a real project.
Developers, trying to make life the project process easy and improve their skills, bury themselves in useful tools: frameworks, libraries, manuals. In fact, the situation is as follows: unsolved tasks seem to never end, and the extension of the expertise becomes a daily routine. It’s unlikely that we can change it. And seeking to do it is hardly pragmatic
Let’s see what can be optimized!
How not to drown in the information chaos
Client feature request – can it be challenging? Of course! To deal with such, some employers prefer to take team training upon themselves: they buy up various courses and tickets to conferences and hackathons. Is it effective? Probably yes. Are there any other options? Our experience shows — yes.
To level up team skills (to handle tough feature request, you should be a pro), we chose a very rational approach: it’s up to a person what and where to learn, which means that the developers are responsible for their own skills. This saves a lot of time since developers learn skills that are required immediately and test them on real projects.
If the client feature request is about working with a technology we aren’t familiar with, we follow the pre-developed plot. I’ll explain it by using the example of a small passing application for the event industry that we’ve created.
The client feature request is to create something we’ve never done before
To get more details about this feature request, let us tell you a story. We received a trial task to develop a mobile application from startupers who lived in New Orlean and sold IT-solutions for event organizers. Ok. We’ve got a task. The task was to build a service for security guards which will reduce queues at the entrance and make it real for guests to pass through by using wristbands with RFID-tags.
Creating an interface for this mini-app — only three screens — dead easy for us. But its performance was to be provided by technologies we weren’t sure of. In particular, this applied to RFID tags. At the time, we didn’t work with them, and online research didn’t give a clear answer to our question if there are libraries that can read them.
Additional conditions set by the clients during the briefing made the overall situation even worse. Go ahead and find out what happened.
The first stage: complexity estimation
One of the main project challenges — deadlines (tough feature request isn’t the only thing we should worry about). We had less than a month. Besides it, another factor impeding the situation was that the service was to be used from a rare smartphone model that could not be obtained.
One more thing: the application needed steady offline mode. At events (especially held in the open air), there are often problems with the internet connection but a bad signal should not slow down the work of the guards. The app was to be designed so it could work without connection but sync with the server as soon as the internet shows up. What if someone bought a ticket at the last moment or after the event starts?
Handling this feature request didn’t seem challenging, but everything had to be done flawlessly. As it’s supposed that letting through would take no more than 2 seconds, lags and slowdowns were not allowed.
The second stage: implementation and testing
As we had less than a month, our strategy was like this: 2 days to test the most problematic features and if find a solution — keep working. The clients were pleased with it and we dug deep in the development stage.
First, we plumbed the depths of RFID tags. We chose several libraries that could help us manage this task. We then discovered that RFID tag — is a predecessor of NFC technology, hence theoretically any smartphone with an NFC module could ‘understand’ the information in the bracelet.
As a result, we created the technical prototype and tested the needed set of features (using our own smartphones and credit cards). The original hypothesis was confirmed, and the library didn’t fail. Since we didn’t have the opportunity to test this functionality on the right model, we sent a technical prototype to the clients. Everything worked as expected, and we promptly switched to other tasks that were not somehow difficult.
So what did we get? A very minimalistic design with traditional ‘traffic light’ colors: red — if the guest doesn’t have access to a zone, and yellow — if the check-in stage was passed earlier. Additionally, app work was accompanied by relevant audio signals which helped to reduce the time of passage of a person through the control point.
The third stage: consolidation of knowledge
What can help you in mastering a new feature (and handling client feature request — particularly, the toughest ones) is telling your teammates about it. Unlike attending conferences, this practice is a mandatory and regular ritual that happens several times a month in our team. No preludes or formalities — a short speech of 30 minutes is enough.
As part of an in-company meetup, we discuss not only features but also the process of solving problems. Sometimes we end with a detailed guide — this works in cases when the team regularly uses a particular technology (for example, FaceID).
Initially, it seemed that programmers would be skeptical about such performances and the prospect of broadcasting ‘about something’ in public would strain them. In fact, it turned out differently: the opportunity to share experience was taken with sympathy. People were glad to get the chance to be an expert. Plus, such events added value to the work and greatly improved the team spirit.
Conclusion
The app and the wristband have successfully worked at several events, and the project is now actively developing. What about us: we have been working on the contactless payment feature and we’re almost in the home stretch, which means that the bracelet will contain not only information about access to specific zones but also turn into an e-wallet that can be used for transactions at the event.
For example, you will be able to pay via it for a dish on the food court or in the shop zone. Thus, the app has become the basis for an infrastructure service that allows to collect detailed statistics about the event and purchases made during it. And we have got a promising client who likes to experiment with technology and is ready to entrust us with the most complex pieces.
