While many development principles are universal, each individual develops their own style of programming and that might be somewhat different from another persons. We work in a team and sometimes these styles conflict with one another. To avoid losing precious energy and time in discussing this for each team we build, we are documenting some of the ways of working here.
Similarly, everyone has a different experience and they may not be aware of all the pitfalls of a specific practice; things that might be obvious to more seasoned developers. Since we forget to talk about things that are obvious to us, this guide is meant to document out method so that it is clear to all.
This guide aims to illustrate how to engineer the Axelerant Way: to provide strong guidance, not an authoritative direction.
No. These methods are not perfect but these are ours. We understand the tradeoffs involved and have decided this to be the most appropriate method based on these factors.
The current technology landscape.
The tools and platforms we use.
Our knowledge about these technologies and platforms.
We welcome improvements to these processes and methods provided there is enough support. We also recognize that not all teams are the same and the most appropriate method may be different for such teams. Wherever possible, we try to document that within our context.
Again, if you find anything lacking in any of these pages, feel free to raise a pull request.
Version control is a staple part of the development cycle and it is important we (the entire team) understand it properly. It is not an exaggeration to say that this is one of most fundamental skills of any programmer.
Continuous Integration (and its cousin, Continuous Deployment) are essential parts of a developer's cycle today. We use it everyday without realizing it and we ignore it at our own peril.
Security is an everlasting concern in the world of software engineering. Understanding what security means in the context of our work and the various vectors that might be responsible for compromising our system's security is extremely important.
Nobody likes repetitive tasks. Human beings are usually bad at reliably performing repetitive tasks. If you want to build, deploy, and generally jump to more exciting tasks soon, write automated tests.
When working on our projects, we prefer to use libraries. We adhere to our principle, proudly invented elsewhere, implying that we value and utilize community libraries. However, the thrill of our work often lies in the unique requirements that call for custom solutions beyond these libraries.
Documentation is highly underrated. It is probably the most underutilized, yet the most important factor of success. Think about any product or technology. The only thing that dictated its success long-term was its ease-of-use, and documentation is highly critical to achieve that.
As an engineer, we solve problems daily. It can be technical or non-technical. The solution can be from a reference or something you figured out. By sharing how you have solved the problem, you will be helping others who have the same problem. It can be in the form of a session or a blog.
No one knows everything. We all have things to learn and we see that when working on a project or implementing a solution. Some of us have gaps in our coding fundamentals, some in their implementation of standard practices, and so-on.
Your choice of tools you use to write code or work with issues will determine how happy and productive, or frustrated and inefficient you are. This is why we build configuration for local tools within the project repository so that the entire team is working with the same tools and in the same environment.
We are Drupal experts, but we can belong from different backgrounds. At Axelerant, we follow some set of tools and approaches. They might not be perfect. Your opinions are valued here.
In an increasingly digital world, our commitment to accessibility is not just a necessity—it's a strategic choice. As we navigate the landscape of technology, we stand as architects of change, sculpting solutions that comply with legal standards and are ethical statements of our dedication to diversity and inclusion.
When building Frontend interfaces for Drupal or JavaScript applications, we like to use the right tools and practices. These help reduce cycles in development and assist us in delivering the consistent solutions.
At Axelerant, our approach to open source contributions is guided by our values. We understand that growth is ongoing, and our work on various projects often reveals opportunities to expand our knowledge. We prioritize continuous learning and improvement. Open source contribution is one of the key elements in our mission of learning and improvement. Whether we're actively engaged in projects or participating in community initiatives, we contribute with dedication and a sense of responsibility. This not only enhances our expertise but also allows us to give back to the open source community, aligning with our mission to make a positive impact. In this way, we uphold the Axelerant way of contributing and our commitment to excellence.
When we’re building a website or an app, we first need to decide whether to configure the content structure first or to do the content structure and content display at the same time. Most of the time, we lean towards settling the content structure before the content display.
In our Agile projects, estimates define the work size needed to meet acceptance criteria or project milestones. We use story points, not hours, to estimate effort, considering complexity, work volume, and risk. This emphasizes that story points are a measure of relative effort, not actual time. Using story points helps us improve estimation accuracy and project delivery.
