If you want to start from the beginning, go to the first part of the article, where we have reviewed the principle of developers interchangeability.
There will be the third part, where we will bring together the main pros, cons, and intermediate results of the interchangeability principle. Follow us on Facebook to get the updates. : )
Our stack
Bitrix24 forms basic software stack. It is a PHP coded by Bitrix24 developers that one needs to adapt oneself for and learn how to play mostly by others' rules. Though it's a great way to learn how to optimize — now and then the rules written by others will create artificial restrictions and conflicts.
Development of our applications for Bitrix24 implies a slightly different stack — we need to work with the AMI protocol and the FreePBX configurator for the virtual PBX Asterisk, various javascript subtypes, including both client frameworks and server Node.js — and that's not it!
Over the years of custom development based on Bitrix24, we have implemented data exchange with a variety of systems, including ERP systems, self-written accounting system, Microsoft Active Directory, industry aggregators, payment systems, site and landing engines, web-analytics systems, various virtual PBX and SMS services. Also, from time to time we migrate data from different systems to Bitrix24.
Previously, we worked with sites on CMS 1C-Bitrix, but now we're moving away from this technology. Business automation as the company's specialization turned out to be much more interesting.
Developers specialization
Each developer can choose from the general stack of technologies what he likes best. Of course, experienced developers can perform a lot of tasks, but everyone has preferences.
All developers have the right to specify what they don't want to do. It makes no sense to make anyone work on something he or she hates. On the other hand, a developer can point out some technologies of his interest — in this case, one can sometimes change the technology used for the task in a decent time.
Sometimes a developer knows how to perform a specific task better than colleagues, and thus he or she becomes a priority executor for the tasks of this kind.
Developers growth
Specialization allows slowly but consistently expanding and updating the technology stack — both for developers and for the company. It is facilitated by the constant rotation of projects, the ongoing presence of projects on support, and the emergence of new ones with the room for software design.
Discussing and evaluating the project with different developers allows finding alternative solutions for each task. Also, it always leaves some room for maneuver. The search for alternatives seriously increases the level of understanding and code organization in the team. It also gives a boost to less experienced developers.
Specialization restrictions
If the technology is quite specific, like a certain js framework, it creates significant restrictions for the interchangeability principle: the choice of the executor is narrowed down to one or two particular developers who are familiar with the tool.
Such a restriction does not create major problems, because most of the projects are related to the basic software stack, and they can be easily redistributed, which will free up the time of a specialist.
For example, now two of our developers are mastering Vue.js. It doesn't mean that we cannot delegate tasks on Vue.js to other developers. We can, and for sure will do so. But in some perspective, the selected pioneers will be involved in all projects based on Vue.js. It's one of the variables in the planning process.
The power of decomposition
There is a lifehack that lies on the surface. Any task can be decomposed to a manageable level by almost any developer. Decomposition into small tasks that can be distributed among the whole team — that's the power.
The main thing is to remember about the dependencies and the importance of merges, otherwise, it might get awkward.
Of course, there might be some problems with software design. In this case, indispensable are the thoughtful artifacts of product design, meetings with the person who set the task, as well as advice and assistance from the most experienced developers.
Learning and cooperation
The principle of developers interchangeability involves constant work in a team that, in its turn, forms a culture of communication, cooperation, and mutual learning.
Internship program in combat conditions
For several years now, our company provides an internship program for students of the local tech university. They are trained to work with our software stack. Several interns work with us regularly, two of them have already become full-fledged developers.
However, the local university trains specialists who fall short of fully conforming to our profile. Plus, the company has its norms of code organization and set of approaches to solving various typical tasks. Not all interns can find their way in our system of working environment organization, and especially in Bitrix24. To answer some basic questions, we hold a one-time meeting for newbies to get them acquainted with our environment, general rules, and Bitrix24.
Training new team members
All our developers take Bitrix24 courses and earn certificates. For an intern, it can be quite a hard task, but with time and experience, everyone copes with it.
Eventually, we have created a mentoring system, let's call it Sensei and his Padawans. Sensei is one of the leading developers. He has practically inexhaustible reserves of common sense, logic, patience, and simple software solutions for how to "just make it work". Four people have studied on his watch — it's quite a weighty result for our small team.
An intern can always turn to a more experienced developer for advice, solution, or attentive code review with the analysis of logic and software implementation. Such interactions happen every day. Among other things, it helps us to maintain a decent level of projects implementation.
For more, the interns often work on tasks in tandem with an experienced developer, complementing and re-using already implemented functionality. It allows the interns to stay in the stream of optimal software solutions and various subtleties, not to become isolated in separate tasks, and not to fall out of the workflow.
Advice and mutual assistance
Interns apart, the culture of advice and mutual aid lives within the entire development team. There's no space for personal competition. Although we must admit that there is a competitive spirit in terms of the quality of created solutions, and each developer perceives this spirit in his or her unique way. Some work their asses off to make sure their solutions are no worse than the ones of their colleagues. Some do not perceive rivalry at all — they work by themselves, and that's it.
It's ok to consult a colleague on the solution choice. Each developer has a bar at which he or she prefers to seek advice. Mutual assistance lives and works thanks to the human and professional approach of developers — and thanks to the principle of developers interchangeability, too.
P.S. Engineers
When I say "developers" I mean our Asterisk engineer as well. He writes code on his side, "pilgrims" often come to him for advice on the PBX behavior or what architecture to choose. Our Bitrix24 and Asterisk integration module based on the FreePBX configurator, its support, and development for the past two years are all largely the merit of our telephony engineer.
Our technical director is also a telephony engineer — with a bias to Cisco, but limited to that. Now and then he assumes the role of developer or system administrator (especially when our staff administrator is on vacation). Thanks to him we have resolved a lot of technical issues and a lot of our developers have gotten some proper advice.
Awesome is our system engineer. He reigns over all development environments, testings, productions, backups, and other vital things. He will always promptly help the developer on his part, give advice, and sometimes work as a second pilot.
And of course, not to forget our CEO. He is also an engineer with development experience, and occasionally he does not deny himself the pleasure of settling a couple of complicated technical issues.
So, keep in mind the engineers when you talk about developers, and even more so — the rule of mutual assistance and training.
***
In the third and final part of this series, read about the pros and cons of our approach. Our Facebook will let you know when the article is out. By the way, we also have profiles on LinkedIn and Instagram — though, the latter is in Spanish.
