Hello once again to Readers’ Questions, presented by the Ember.js Times folks with a little help from the core teams
Today we have a question by wootag43 regarding how to pitch Ember.js at your company:
What are the best way to pitch Ember.js for the company that are looking forward to break apart monolith application into API and SPA.
‐ wootag43
This week’s answer is @katiegengler. Make sure to read and comment
The best way to pitch Ember is the same way you’d pitch anything at your company. This process will be particular to the company and project. First, you’ll want to figure out who the decision makers are: who can give the go-ahead to use Ember to implement the SPA? This could be your manager, upper management, a dedicated committee, an architect, or ideally, your development team. It will likely be the same person or group that made the decision to break apart the monolith. You want to tailor your pitch to those responsible for the decision.
Before you start planning, consider whether you need to “pitch” at all. Don’t frame the choice of framework as a momentous decision if it wouldn’t normally be considered one. Don’t involve management if they are not normally involved in tech stack decisions. Don’t hold a team meeting and spend an hour pitching Ember if you normally decide these types of decisions over lunch.
If your team will decide
Talk to your team about what has attracted you to Ember. As fellow developers on the same project, they will likely have a similar perspective to your own. If there are competing proposals, suggest that your team come up with a rubric for evaluating options for the SPA and to gain consensus on what is important in a framework for the project. Be sure to include the relative weight of importance of those factors in the rubric. Suggest building a spike or prototype in each framework to gain some experience and fill out that rubric.
Do not attempt to hide or ignore any of Ember’s negatives. In my experience, seeming like a zealot is a quick way to get teammates that wouldn’t normally care to oppose you. Being forthright about the possible risks of using Ember will make your proposal more credible.
Are you an Ember expert? Are you involved in the community? If so, that can be a good argument in favor of using the framework because you’ll be a resource to help the team. On the flip side, if you have a team member who spends their nights and weekends working on a competing framework, you’ll likely have a tough time garnering support for Ember. But if you have Ember experience, don’t let the person who’s “heard good things about BrandNewFramework” seem to be on equal footing: make your credentials well-known (without being a braggart).
Focus on the facets of Ember that really matter to the success of your project and company. Don’t bring up less important reasons why Ember is a good (such as “Ember is perfect for our project because there’s an addon for our favorite CSS framework!”) fit unless answering a question or filling in a point in comparison to another framework.
If forces outside the team will decide
In this case, it is probably best to gain consensus on the team first, then proceed through the organization on the way to to the decision makers (this depends very much on company management structure!). Always propose to those closest to the team first, working towards the decision makers, enlisting the help of those you convince on the way to propose to those after them. Provide as much data and facts as possible, preferably in a presentation format. Be sure to give a discrete proposal to consider; “Use Ember on the Project X reboot” is better than “What framework to use for Project X reboot?”
If you’re planning to pitch Ember you probably already have a good idea about its benefits, but here are a few things you might want to bring up:
Ember is used by large corporations such as Netflix, Heroku, LinkedIn, Sony, and others
everything you need is included out-of-the-box (router, data layer, build tool), but there’s also the flexibility to replace pieces if needed
there are many high-quality community-contributed/maintained addons. There are well-established solutions for common needs such as deployment, internationalization, accessibility, user interface elements, etc. (see more at emberobserver.com)
ember-cli makes it simple to get a local development environment going
LTS releases ensure you don’t have to constantly update Ember to get bug and security fixes
Ember evolves without making sudden breaking changes. API changes are signaled well in advance of a major version through deprecations, with the major versions merely removing those deprecated APIs
the ember community is active, helpful, and easy to find in the Ember Community Slack
This answer was published in Issue #35. Don’t forget to subscribe to the newsletter to get development news right in your inbox. You can also submit your own questions! You will find a link at the bottom of the newsletter.
Awesome write-up. I would heartily second any mention of the Ember community and core-team, Ember’s adherence to conventions, and the way that Ember is carefully evolved to simultaneously provide cutting-edge features and make the developer experience nice. It’s not a tangible thing that you can point to on a chart and say “look Ember scores better” but it makes a tremendous difference in maintainability, project and dependency setup, and allowing new devs to jump right in. We’ve upgraded one of our apps from pre 1.0 to 2.16 (soon to be 3.0) and maintaining the app over the years has never felt burdensome, and upgrades have always been straightforward if not easy.
FWIW I’ll share our recent experience breaking up a monolith app. We have always had our admin panel for our API baked into the API. I had tossed around the idea of rewriting the admin panel as a SPA, and other people had as well, but there was still some hesitance around whether we should do it at all, how long it would take, how successful an undertaking it would be, and whether an Ember app was a viable replacement for the panel.
We already used Ember for other applications so it would have been our default (though not only) option, but I decided to pre-empt a long drawn out discussion and just prototype it. After just a couple of hours I was able to set up a new project, implement authentication, create a similar application template and implement a few of the basic views with working controls/search, etc. This turned out to be really helpful for a couple reasons:
it demonstrated how quickly we could get up and running with Ember
it was something concrete to look at and compare, and was kind of a foot-in-the-door because we already had code written so in a sense the project had already started
one thing which was immediately obvious but which surprised everyone (myself included) was how much faster and smoother everything was, especially interactions that used to require a re-render and page load. That alone was seen as a huge benefit which we basically got for free
it allowed the less-technical people to talk about something tangible so they weren’t trying to pretend like they had an opinion on something they didn’t understand. They could just say wow yeah that definitely looks better and you said it was easy and fast? Cool let’s do it.
We have finished implementation and are currently in the process of switching all internal and external customers over to the new app permanently and removing the old one from the API codebase. So far the project has been a big success, and these are a few of the other benefits we’ve identified as a part of breaking the monolith into server/SPA (some might be pretty specific to our team/stack):
Not only does it clean up the API codebase, but it takes the burden of maintaining the app off of one of our chief API devs and spreads the load around a lot better
We can add new features much more rapidly and deploy them without depending on the API release process
Thanks to Ember and all of the great addons the project setup and maintenance/upgrades have been trivial, we have an increasingly great set of automated tests which are almost CI-ready, and we have a robust deploy system which makes releases and bugfixes incredibly easy.
In summary: while we didn’t have to fight as much over the front-end framework of choice, we did evaluate the project viability, time commitment, and whether or not an Ember app was a good choice. We selected Ember, hit the ground running, and haven’t looked back. It’s been a fast, smooth process and we feel extremely confident about our ability to maintain it in the future. Prototyping the app really helped to show people how rapidly we could make progress and how much better it was, and gave us a foothold in reality and in github.
A very often used argument against Ember is hiring. It is very difficult to find and hire Ember devs compared to React. What’s the best way to counter this argument?
I wouldn’t hire specifically for Ember developers, I would hire developers experienced with JavaScript and web development. I’ve had developers with no Ember experience, but JavaScript & React experience, join a project I was on and contribute by the end of the day.
Even if you choose Ember for a particular project, or React for a particular project, you may not use that framework for the next project, so why hire based on framework?
It’s been almost two years since my team introduced Ember to our IT department, and our managers still complain that, “It’s hard to find people with Ember on their resumes.”
I politely reply that they should realize that it is impossible to find anyone with experience building or maintaining our legacy systems - with their, er, “peculiar nuances” built up over the past 30 years. I have suggested that we focus on finding people who write software well within any good MVC framework, and who are willing to raise the bar on the quality and consistency of our software. These skills transition to other frameworks. We’ve done this with 3 or 4 full-time developers, and about half a dozen contract developers, and all but one of them have adopted Ember relatively quickly.
Status quo is a powerful thing though, and despite the reasoning and facts, this is still a problem with most of our managers’ perception.
