What are the pros & cons of being an early adopter of a framework?
This can be a loaded question due to misaligned incentives. Projects need early adoption to be successful.
But what is best for your career and/or project? Let's discuss it honestly.
When is "early"?
In the context of software, "early adoption" has multiple meanings.
For the sake of this conversation, "early" specifically means at least one of the following is true:
- The software is not yet widely used (not many case studies)
- Best practices have not yet been established
- The software has not stabilized (alpha, beta, sometimes 1.0)
It's not always clear whether using software is early.
Let me give a few examples, one of which may be counter-intuitive:
- Drupal 8.0
- Early
- Drupal 8.0 was a significant rewrite of 7. Because of which, best practices for building websites with Drupal 8 had not been established when 8.0 was released.
- Early
- Drupal 8.6
- Not early
- By now there are best practices for how to build websites in Drupal 8.
- Not early
- Drupal 9.0
- Not early(!)
- Unlike Drupal 8.0, Drupal 9.0 is NOT a rewrite of the previous major version. Therefore, using Drupal 9 does not come with the typical "early adoption" risks.
- Not early(!)
The takeaway is that early adoption can not be determined by looking at version numbers alone.
Should I adopt a framework early?
As always, the answer is "it depends". Here's the tl;dr:
- Developer's perspective:
- Pros:
- Become one of few experts in a niche technology
- Understand the framework more deeply
- Likely to become a contributor to the framework itself
- Others will value your experience
- Cons:
- Increased project complexity
- Typically no/weak documentation
- No best practices to follow
- Framework may be buggy and incomplete
- Framework may be abandoned, rendering expertise less valuable
- Pros:
- Client/project perspective:
- Pros:
- Very talented developers may be excited to work for you
- Cons:
- Risk of the framework being abandoned
- Additional cost
- Significant technical debt
- Pros:
Read on for a more in-depth explanation:
The developer's perspective
Ask a room full of developers whether they'd like to be an early adopter of a new Framework and you'l get mixed responses:
- Yes, I'd love to get in on the ground floor!
- Sounds exciting - I'd love to help build it!
- Sounds scary - what if the framework is abandoned?
- Sounds daunting - I just want to build my project, I don't want to build a framework.
Each response is as valid as the next.
Let's outline the pros & cons from the developer's perspective:
- Pros of early adoption
- You learn more about the framework's architecture
- You'll understand the framework more deeply than future entrants
- You get to work on the framework itself
- Others will value your experience
- You establish yourself as an expert with a niche skill
- Cons of early adoption for devs
- In addition to building your project, you may need to fix issues in the framework
- Documentation is (usually) weak early on. There are exceptions!
- Best practices for using the framework have yet to be established
- Brand new frameworks may not last long (may be abandoned), leaving you & your project stranded without upstream support
It's not for everyone. But being an early adopter developer can provide you with interesting work and accelerate your career.
Client (or project)'s perspective
If the developers use an "early" version of a framework for your project, there are a few points you must acknowledge.
- The developers will also be fixing (& fighting) the framework throughout the project.
- Your site will be built on ground which has yet to settle. There will be plenty of technical debt.
- Some developers will be excited to work on your project
- Your company may have more influence on the framework's direction
If the project is core to your business' operations it may make sense to invest in early adoption. Core contributors will be inclined to work for you and you can help set the direction for the framework.
The intangibles
It's true that frameworks need early adopters to be successful. And in many cases, communities are built around frameworks.
If the framework you're using has a community worth supporting, there is an added benefit to investing in the success of the framework.
First-hand early/late adopter experience
I have been programming since I was a kid, for almost 20 years now. In that time I've worked with all sorts of software - vBulletin, phpBB, expression engine, Drupal, Symfony, React, Laravel.. the list goes on.
I've built projects as both an early and late adopter. How'd it turn out?
Remember, the definition of early is not "version 1". It refers to software whose best practices have yet to stabilize, whose adoption has yet to peak, or, when looking at the past, to versions of software that work differently than newer versions of the same software today.
"Earlier" adoption
- Drupal
- I'm glad I worked with Drupal 6 & 7 before working with Drupal 8.
The history of the project is important, and it helps me understand why things work the way they do. The onboarding for "full stack development" in earlier versions was also easier than it is today, as there was no OOP knowledge required back then.
- I'm glad I worked with Drupal 6 & 7 before working with Drupal 8.
- React
- I'm glad I worked with React with class components (before hooks were introduced). I'm also glad I used it without JSX in the past.
The historical knowledge helps me feel more comfortable with newer techniques, as I feel I have some "under the hood" knowledge. P.S. React's backwards compatibility is great - old projects can continue running as-is.
- I'm glad I worked with React with class components (before hooks were introduced). I'm also glad I used it without JSX in the past.
Later adoption
While I've been doing PHP for as long as I can remember, I've picked up both Symfony and Laravel more recently. I must say - using thorough documentation and tools has been a breath of fresh air.
I am learning more quickly, and I feel confident that my projects are well-architected.
Should you be an early adopter?
As experience always teaches us, the answer is "it depends".
Hopefully this post helps you make your decision.
Need help with your projects or learning how to code? Get in touch!