Mark Esser

This decision to standardize on a collective default tech stack was made through a collaborative proposal-thinking process, where the entire company participated in discussions and ultimately reached a consensus. This proposal, which focused on our future direction rather than re-engineering existing projects and products, has been thoroughly debated and ratified company-wide.

1. Synergy and Efficiency Gains | A unified tech stack allows for the pooling of knowledge and best practices, resulting in significant efficiency gains. Developers can share insights and solutions more easily, reducing implementation time and error rates. This shared knowledge base accelerates development cycles and enhances code quality.

2. Easier Maintenance and Scalability | Maintaining and scaling software is considerably more straightforward when using a common tech stack. Developers can seamlessly transition between projects, leveraging their existing knowledge. This continuity enhances scalability, as new projects can be initiated more swiftly without extensive onboarding for unfamiliar technologies.

3. Cost Savings | Reducing the diversity of technologies leads to lower training and onboarding costs. Investing in a single tech stack minimizes the financial and time burden associated with learning new tools and systems. This also applies to tool procurement and infrastructure management, where uniformity provides additional cost efficiencies.

4. Improved Communication and Collaboration | A standardized tech stack fosters better internal communication and collaboration. Developers conversant in the same technologies can easily discuss and resolve issues, leading to stronger team dynamics and a more cooperative work environment.

5. Better Project Planning and Management | Project managers benefit from a homogeneous tech stack through improved predictability and control. With a consistent technological foundation, project timelines and resource allocations become more reliable, supporting both short-term and long-term strategic goals.

6. Seamless Integration and Interoperability | Standardizing technologies simplifies the integration of various applications and systems. Projects and solutions can interact more fluidly, creating a more cohesive and adaptable system architecture.

7. Enhanced Talent Acquisition and Retention | A well-defined tech stack streamlines talent acquisition by narrowing the focus to specific skill sets, thereby improving candidate matches. Developers are more likely to stay with an organization where they work within a familiar and consistent technological environment, enhancing retention.

8. Reduced Technological Risks | Focusing on proven, widely adopted technologies minimizes risks associated with stability, security, and maintainability. While new technologies offer innovation, they can also introduce uncertainties. A standardized stack provides a stable framework upon which innovation can safely proceed.

9. Easier Standardization and Compliance | A unified tech stack makes it easier to enforce development standards, security protocols, and compliance requirements. Consistency across projects strengthens overall governance and risk management.

10. Flexibility and Innovation | Despite standardization, our approach remains open to new technologies and trends. The default tech stack provides a solid foundation that supports innovation projects without endangering system stability. It ensures the company can adapt to technological advancements while maintaining operational integrity.

By aligning with a collective default tech stack, we position ourselves for sustainable growth, enhanced efficiency, and increased competitiveness in the market. This strategic move maximizes our existing expertise and sets the stage for continuous improvement and and long-term success, ensuring we remain agile and adaptable in a rapidly evolving technological landscape.

A senior developer from our team Shoplifters says the following about what the Elixir Squad is currently working on:

“The Elixirsquad is currently working on the implementation of new features for our e-commerce platform such as a compatibility search for SmartHome devices from different manufacturers. Not all of the products listed here can actually be ordered via the connected store systems, but rather serve as a general planning aid for the end customer when selecting products. However, finding and identifying planning errors and bugs and working out a solution for them is also a constant item within the team.”

I asked the same Shoplifters member what is the greatest potential of Elixir and Phoenix:

“Elixir and Phoenix provide us with powerful tools to investigate the topics mentioned. Despite the rather dynamic nature of the language at first glance, the ecosystem provides us with powerful tools for static analysis to identify even the not quite obvious module dependencies, even in a complex system like our platform backends, and to develop strategies for solving problems based on this. At least that's where the potential lies from a developer's point of view. The economist will like the fact that Elixir allows a relatively compact programming method, which can do without unrecoverable error handling to a large extent and can nevertheless work fail-safe and error-tolerant, if one keeps to basic rules in relation to the "process supervision".

Finally, I asked him what advice he had in store for Elixir newbies:

„Elixir is not an object-oriented language, even if it has adopted many syntactic elements from Ruby, the semantics behind it are quite different. Please take this to heart, and don't try to find a substitute for objects and classes in processes and "actors".”

A developer and project manager from our team X says the following about our use of Rails at i22:

"We use Rails to build stable and flexible backend systems. Rails is extremely good for managing data structures and quickly setting up new systems. It is the perfect base for most use cases."

I asked the same Team X member why the team prefers to work with Ruby on Rails, rather than Python and Django:

"Because Python is a scripting language and from my point of view not suitable for building stable web services. Python is for me rather good for scripts and fast small tools. Not for stable business applications. And if I want it fast I prefer Go."

A developer from our team BitFlip says the following about our use of Kotlin at i22:

"We use Kotlin to develop an MQTT broker with microservice architecture, including a JavaScript client module for type-safe communication from the front-end, and shared code between the front-end and back-end. What do we particularly like about Kotlin? Kotlin is a state-of-the-art language with a focus on conciseness, security, and efficiency. It can be compiled to Java bytecode, JavaScript, and natively, and is completely compatible with the ecosystem of whichever platform you choose."

A senior developer from our OneTeam says the following about our use of React at i22:

"We use React to build modern, component-based user interfaces. What do we like about React? React is a flexible JavaScript framework that allows us to easily and performantly create dynamic websites."

A senior developer from our OneTeam says the following about our use of TypeScript at i22:

"We use TypeScript in more complex projects to benefit from type safety to compile time. The TypeScript code we write is compiled into plain JavaScript for the browser. Type safety allows errors to be detected when the code is written, rather than when the page is opened in the browser. So there are fewer runtime errors and you work more efficiently. It also contributes to code readability."