A WiFi lantern to increase developer team cooperation
BI-Beacon was initially known as CILAMP; short for Continuous Integration Lamp. The problem that CI status indicators (or “build lamps”) solve is one of developer coordination and cooperation.
When several code changes happen concurrently on each developer machine, and those changes are checked in to a shared code server, it is in the whole teams’ interest that the state of the joint code base is still OK:
The system should always compile without errors
All automatic tests (unit, integration, system) should still be passing
Generating artifacts (installers, packages, app bundles) should still work
How BI-Beacon is utilized in a CI/CD scenario
Using triggers or polling of the build servers current state together with BI-Beacon – a live indication of the current or previous build can be visualized in a physical arena where all devs can see, for instance in the center of the room.
A slow yellow pulse means the build server is currently building; the result is not yet available.
Green color indicates that the the system built without errors – all tests passed. Everyone can update their local sources (or fork master) without worry, and it’s also an excellent time to check in your changes.
Red means something failed; either with a compile error or some test didn’t pass. Now is not a good time to update your local source.
Having a build indicator available makes the team collaborate more efficiently, and avoids conflicts where developers are annoyed with each other’s bad commits; in fact, this is such a common need that throughout the years development teams have often spent their time and energy on coming up with their own homegrown solutions, as in the left image below.
Of course your ninja-devs could probably come up with their own solution to this problem, however travelling that road is rocky and may come at a high cost:
Developer time is expensive, and building even “homegrown hacks” is non-trivial
Homegrown solutions tend to fail after some time, causing either service outage or high maintenance cost
The developer that initially built the solution may switch workplace, again causing a service outage
A BI-Beacon client was launching a new service, which customers could sign-up for on their web site.
Whenever a sign-up occurred, a database was updated. Once a week, a report was generated on how many sign-ups the company had the previous week. However, this method suffered from two issues:
PDF presentations during Monday meetings are not super exciting 🙂
The relatively long period between registrations and the status reporting made it hard for the staff to see the correlation to their work
How BI-Beacon is used celebrate sign-ups
By positioning a BI-Beacon centrally at the office, at a vantage point visible for most people, everyone could see in real-time when a new sign-up happened.
Since sign-ups became visible in real-time, it caused daily celebration at the office, with increased awareness as a result. This in turn sparked ideas on how to get more sign-ups naturally and playfully. For instance, coworkers started sharing the sign-up page on social media to attract new people.
The integration was as simple as adding an SQL trigger to the relevant database table in the service.
A WiFi lantern to increase the speed of software delivery
One BI-Beacon customer was trying to get higher software quality by introducing code-reviews in the development team. However, they struggled in this process change, even though developers agreed it was a good practice to do code reviews. A couple of observations stood out when identifying the business issues at hand:
Code reviews were lagging behind schedule, causing delays in delivery for the rest of the organization and customers
Code reviewing was seen as something dull and boring, and less productive than “actual coding”
How BI-Beacon was used to embrace code reviews
By positioning a BI-Beacon by the coffee machine, just outside the developer room, everyone that went for a coffee got a clear indication of the state of code reviews.
This is what the colors indicated:
Yellow meant there is some code to review.
Purple pulsing slowly meant some code had been waiting for review for more than four days. Get on with it already!
Green color meant all code reviews are done – hurray!
By showing clearly the value of code reviews – no one missed the glowing light indicator by the coffee machine! – it was suddenly a lot easier to get code reviews happening. Developers also expressed that it was more fun to do code reviews, as it turned into a kind of game at the office, but also that it was clear that the whole organization valued code reviews and the increased quality it brings to software development.
The integration was done by regularly running a Python script that checked the state of issues being worked on by the development team.
A WiFi lantern to reduce disturbances and increase support ticket throughput
One BI-Beacon customer had an innovative idea on how to increase throughput in internal support and operations. The issues were two-fold.
Low awareness of new tickets coming into internal support ticket system
A lot of human related disturbances, stressful and inefficient for everyone involved and often reducing operations efficiency unnecessarily
How they use BI-Beacon
By integrating a BI-Beacon physically at the office, close to operations, both problems were reduced. This is how they did it:
Purple color means there are unassigned high priority (system is down, or other critical issues) tickets in the support system, who will be the first to respond?
Green color means all tickets in the support system is assigned to a co-worker, and none of them are high priority . Things are under control and no immediate action is required!
Red pulsing color means there is a priority one ticket being worked on (or unassigned), so please do not disturb us, we are working as hard as we can!
By showing the support system state in this accessible way, they reduced the human disturbances of support, and engaged support personnel in assigning tickets as soon as they are in. In this way they sort of gamified the daily experience of working in support and operations, making business more efficient for everyone.
From a technical standpoint, the integration/coding effort was minimal, and done using a database query and a script polling the support system database every minute.
BI-Beacon loves open source software. The API has been intentionally open all the time, and open sourcing the server that controls Beacons has been part of the plan for at least a year – it’s just not been made official.
Having the API V1 server open source means you will be able to host the state server on your own premises, which may be necessary to satisfy the IT policy at your company or your clients. This also means you will not be locked-in to BI-Beacons state server “api.cilamp.se”.
The date of availability is 1st of June 2019. The backend server will be made available in BI-Beacons github server repository.
Beacons with firmware version 0.84 and upwards are reconfigurable to alternate state servers; units with prior versions use api.cilamp.se implicitly. Version 0.84 release date is 1st of January 2019.