How we work at Axelerant #

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.

Are these perfect? #

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.

  1. The current technology landscape.
  2. The tools and platforms we use.
  3. 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.

Our Reference Baseline

Adopting the baseline on a project is crucial for enhancing the overall efficiency and effectiveness of our operations.

Working with Git

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

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

Security is an everlasting concern in software engineering. Understanding security in the context of our work and recognizing various vectors that might compromise our system’s security is crucial. Security is a broad and deep topic, and it’s a team’s responsibility to implement safeguards at various levels.

Automated testing

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.

Coding Principles and Standards

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

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.

Knowledge sharing

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.

Bridging Skill Gaps

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.

Local tools

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.

Drupal

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.

Accessibility

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.

Frontend

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.

Open Source Contribution

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.

Content Structure Before Content Display

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.

Task Estimation

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.

Incident Management

Managing incidents in production systems is a critical aspect of maintaining system reliability and ensuring continuous service availability. Effective incident management not only focuses on resolving issues as they arise but also on taking steps to prevent future occurrences.