Customer Convos #1: Revin Guillen, Ellie Mae

Recently, we reached out to people who’ve traded us some money for our goods and services, and asked them to tell us how it’s been working out. We didn’t pay them anything, and didn’t edit the content of their responses — just asked for their thoughts in their own words.

Over the next few months, we’ll be sharing the conversations we’ve had. Interested in sharing your thoughts? Drop us a line.

Q. Hi! Can you state your name and what you do?

A. Revin Guillen, Staff Software Engineer at a company called Ellie Mae, who makes products that help banks and lenders process mortgages. I’m one of the lead developers on a large team of sub-teams that are building the next version of the main product (it’s a web app; the existing product is a Windows desktop app). I “grew up” in the open source world and enjoy bringing the culture and mindset to enterprise teams.

How’s your day going?

Peachy so far. Been dealing with some finicky Angular 1 + Angular 2 integration work, working on designing architecture/patterns for the teams to use for pieces of our app, etc… Typical stuff.

Tell me the story of npm at your company. What specific problem did you have that private packages and Orgs solved?

The short answer is it was the simplest way to build proprietary/internal stuff that still worked with the grain of our JS tooling.

The slightly longer answer is, well, we’re building a web app, so that means lots of JavaScript. And by the time I joined the company, npm was already in place for doing general dependency management. Most of the JS devs aren’t really familiar with npm-centric workflow or how open source projects typically work (we manage everything on a private GitHub Enterprise setup), so we’ve ended up building a CLI utility that manages dependencies, does component scaffolding, configures and runs webpack builds, etc…. Similar in concept to the ember or angular 2 CLIs. And since we have a lot of teams building web apps that have a lot of the same components or needs, it just made sense to have our internal stuff be npm dependencies, but private to our @elliemae org. There’s a bit of dogfooding at work here as well, because we intend to export a platform/SDK on which our customers can build their own banking apps, and we’ll end up making some of these things public so those apps can use them.

Can you tell us a story about a specific package you wanted to make that private packages really enabled you to do?

I don’t really have a specific package in mind that only worked out because it was private, but we have a few that contain things like internal URLs or test credentials or things like that, that can’t be available to the public but are still useful to package up and make them easily installable by internal devs.

Does your company do open source? How do you negotiate what you keep private and public? (Feel free to be as vague as you need to be)

We haven’t released anything yet, but we intend to do so. I’m not 100% clear on how the negotiations on that stuff work, other than just, the default will be to open source everything, but upper management will look at something and say there’s too much of our “secret sauce” (or whatever) in that part, so don’t open source that. For the most part, at least for now, the really proprietary stuff will be living in the cloud services we’re using to power the web apps, and those won’t be open source at all, as far as I know.

To people who are unsure what they could use private packages for, how would you explain the use case?

For me it’s: 1) npm based workflow is largely simple, widely known, and greatly eases the pain of building apps as compositions of smaller pieces. 2) In an organization where you have multiple projects sharing dependencies that shouldn’t be public (for any reason, including legal issues), it just makes sense to build those dependencies just like “normal” ones, and limit access to them so they’re not public, but still work with the toolchain.

How’s it going? How’s the day-to-day experience of using private packages/orgs?

Overall, it works quite well. We do have some self-inflicted problems stemming from the wide range of JavaScript experience across our group: 1) people coming from environments where semver isn’t really a thing don’t understand a lot of the nuances involved, and 2) not everyone buys into Full Semver™, so versioning gets done slightly differently depending on who owns a package.

To keep things working, people lock the dependency versions down manually, down to the literal patch version. This makes package updates slow to propagate internally because the consuming packages have to all be manually updated, and it sometimes leads to lots of QA fallout because everyone needs to worry about breaking changes on every version bump. This is mostly a training issue; it’s easy to overlook in a large organization.

Probably the only slightly painful thing for me personally on it is that I have open source projects I contribute to on the same laptop as my work projects, so managing my two different npm logins can be kind of finicky. I usually end up copying around the .npmrc from each work project. Some are maintained by a shared npm account, some are maintained by my own @elliemae npm org account, and it’s not always clear to me which ones will work where. Supposedly, my user is an admin in our org, but there have been private packages that didn’t let me push new versions until I logged in as the shared account. It’s probably that some kind of permissions thing isn’t set up correctly.

How would you see the product improved or expanded in the future?

This may already exist in a simpler form and only needs me to go looking for it, but that issue above, managing multiple logins (and possibly even multiple registries) on a per-project basis easily would be nice.

Would you recommend that another org or company use private packages or orgs and why?

Yes, absolutely.

One of my biggest development philosophies is to choose tools that work with the grain of how you want to work, and work with the grain of your tools. npm based workflow is a successful model, so if you can’t make all your code public, it’s the perfect way to still use your nice tools without jumping through unnecessary hoops. Plus, if someone has any intention of releasing their work later, building it on npm from the beginning saves a lot of hassle come release time.

Any questions I didn’t ask that you wish I did? Please ask/answer them here!

“Q: why are your answers boring? Is it because you are personally boring?”

I would never ask that! But ok— what’s the answer?

A: possibly. But also there’s the issue that enterprise development inherently tends toward mediocrity, and the lines of business are typically fairly boring as it is (even if the technical challenges are fun to work on).

Any cool npm stuff your company has done publicly that you’d like to promote?

Not yet. Hopefully someday. There are some things going on internally, but I can’t really talk about them to the world yet!