One New Tech Per Project
From some months now, each time we start a new project, we tend to introduce a component or a service we've never worked with before.
This started with a particular project, where we sensed a backend storage component we weren't very familiar with (Symfony CMF) would ease the implementation a great deal. It worked. Then, for following projects, we forced ourselves to challenge the technology stack to see if our current stack was the best for the job, or if we could find a better match by thinking outside the box.
Since most our customers are Marketing or Innovation services, they usually leave us the choice of the technology stack. So they don't care if we use Go, Koa, React.js, Sails.js, Titan, or Reactive Functional Programming in addition to the already classical Symfony2, Angular.js, Node.js, ElasticSearch, RabbitMQ and PostgreSQL - as long as we match their business requirements.
Which benefits does this practice bring us?
Developer Motivation
Even though it's easier to develop in a language you've been mastering for long, this can't last longer than a few years. That's because developers usually get bored of a language after seeing what happens in other languages. New languages have the ability to innovate in a more disruptive way. We don't want to become the modern COBOL developers, so relying on what we already know (PHP5, JS) isn't enough.
All our developers are aware of that, and they have a high demand for experimenting with new technologies. Doing so on real-life customer projects makes the experimentation both more challenging, and more rewarding.
Team Building
In a project team, there is always someone better at a language than the others. This person usually takes a leading role ; in return, other developers naturally refer to the lead developer for important decisions. Marmelab's policy on tech lead is to empower everybody to let them become leads. Forcing all developers to start with a common level (the ground level) on a piece of technology is a great way to leave the door open for everyone. And since all developers discover the technology at the same time, they are forced to share their findings, difficulties, and questions. They listen to their respective opinions, they focus more on getting the project done than on doing it the way they think is best. In short, they work together as a team.
Effective R&D
About once a month, the entire marmelab team steps off for one day, and we all work on small Research & Development projects to test and assess new technologies. Most of us also have side projects, usually with new technologies. And we invest time to build and support open-source libraries like gremlins.js, gaudi.io, or phpcr-browser. In other terms, we do assess a piece of technology before using it on customer projects. This gives us a head start to choose which element in the stack we should swap for a more innovative one, once a customer project gets started.
But no lab work will ever beat a real-life experimentation. Learning a new component through a customer use case, with high availability and quality requirements, is a totally different process than following a "hello, world" tutorial. We have to apply the same good practices as we do in other languages (unit tests, separation of concerns, readability, D.R.Y., etc.). We have to watch out for performance, maintainability, security, and stability. The experience we get from these projects is solid, based on facts, and applicable to other projects.
Tech Stack Surprise
Companies invest in R&D to be able to cope with tomorrow's challenges. If a customer comes and asks us to use a whole new technology stack, we probably won't be able to answer. But since we've been testing new components all along, chances are that a customer's tech stack may only contain very few unknows components for us. This greatly reduces the learning time required for starting every new project, and this allows us to answer to more RFPs. With a broader tech range, marmelab becomes more competitive.
Failure Resiliency
We also take risks to learn to fail. Sometimes our choices of new components don't end up with good enough results. Some components aren't mature enough, or not adapted to the use cases imagined by our customers. Many times, it takes us longer to implement a feature using the new component than it would take with a well-known component. In these cases, we have to compensate by being even faster with the part of the stack we know. Sometimes we pay a high price for rolling back to a more stable technology. That's when we learn to fail. And it's better to fail often by a little, than to fail only once, but big time. Risk management is at the core of marmelab's business, and we must be able to cope with our customers' uncertainties just like our owns. Taking risks on the technology stack is our own training for risk management.
Customers Are Free To Adhere
If you're considering working with us, you should know that we do that "One New Tech" thing in the open, and only if you agree with the practice. Most our customers trust us with this choice, but you may very well impose us the whole tech stack. We believe that the product is more important than the technology, and we love to build new products. Just be aware that you'll get better motivation and better results by letting us choose the tech stack. Plus, you may get additional visibility by using cutting-edge technologies.
Conclusion
By adding an unknown component to our technology stack for new projects, we create a risk of failure. Our business is therefore conditioned by our ability to learn fast, fail fast, and recover fast. So far, it's been a conclusive choice, and the benefits far outweigh the risks. So what began as a pun is now becoming a rule that we apply as much as possible.
