The development team at Alea Soluciones, nicknamed ‘Bifer’, invited me to join them for a DeskSurfing (soon a short article on this topic). So, last week I have spent two days at Alea, pair programming with their team and test-driving some new features, it was great!
We started with some organization news from Eduardo, immediately followed by the daily meeting. Alberto and Nestor Salceda (@nestorsalceda) were connected via Google Hang Out, tasks where discussed and we set them up on Trello, ready to go!
Then after a fast coffee, Guillermo and I dived into adding a feature to their telephony monitoring system. The new feature required some minor changes through various components so I got a good big picture of their architecture, message passing, templating system, etc.
We grabbed some salad for a fast lunch, and at the end of the day we toured their offices a little more. We stopped at their laboratory, where they have a small version of what a cable operator would have. This setup allows them to test against the real thing. Really interesting stuff I would say.
Again, daily meeting to start. This time Alberto was in the office, we discussed the outcome of Day 1 tasks , this time I had to participate! After the meeting, I grabbed some coffee and met with the team to discuss a performance improvement for a provisioning system. I paired with Alberto with that specific task, and we rewritten the tests to pull data from Redis instead of querying hardware via SNMP. Then after a quick lunch I paired with Eduardo continuing a similar task.
Funny fact: Sometimes I use the CLI as an example for an alternative DM (delivery mechanism) to enforce decoupling the DM from the Application; Alea does actually have a CLI as an alternative DM for some of their applications. DM Decoupling FTW!
Unit tests were really fast, so ridiculously fast that you can run ALL tests with watch in the command line (even glued with growl, gnome notify or similar) and forget about it while you work on the code. By the way, integration tests where super fast also. That’s the way!
Their deployment infrastructure allowed them to deploy in less than a minute to any environment, from the command line. Awesome.
Feature toggling allowed them to deploy deactivated features, and give the marketing/business people the control over the “feature switches” whenever they see fit, and for individual customers at a time. Double awesome.
Their development team is small, skilled and tightly packed. Information flows freely in their office, via Trello, and via their daily meetings with Google Hangout with the people that are working remotely.
RabitMQ as a message queue to connect different applications in an decoupled way looks very good. SaludOnNet has many application contexts that share data, and independent deployability is very important to us. The way the Alea team deals with this could be potentially applied to improve our own architecture.
Outside my comfort zone:
I have really struggled to keep up with this guys’ business domain. Lots of acronyms are part of their ubiquitous language, take a look at the content table of this wikipedia article and you will see what I am talking about. It took me more than a day to get fluent with their domain, or at least with the part they were working on. Pair programming proved fundamental for this knowledge transfer.
Some of our work required to interact with real hardware via SNMP. This made end-to-end testing more difficult because their initial state could not be always trusted. When something went wrong, we were sometimes doubting about the problem being in the new code, or in some hardware configuration out of our control.
The one hour+ commute to their offices proved painful compared to my 20 minute-ish daily commute, made me think about some colleagues at SaludOnNet that do that every day.
Thanks guys for opening your doors and for this excellent opportunity. Looking forward to have you DeskSurfing our offices soon!