7 Things You Can Stop Worrying About With Multidev

We say on our home page that with Multidev "Website development will never be the same." Sounds kind of cocky, right?

Game Changer

Well, let me try and put some substance behind the hype. I've been in this game for a while, here is what is going to change.

Multidev solves these 7 website development killers:

1. "It worked on my machine."

This is the single worst phrase you can ever hear in a team meeting, and it happens all too often. Chances are you work with developers who use whatever tools and equipment they need in order to move fast and be productive. As a developer, I wouldn't have it any other way. The problem is, with literally millions of possible combinations of hardware, OS, packages and libraries, there's absolutely no way to be sure that that whatever you got working on your laptop or workstation will run in production.

2. Wrangling with MAMP, WAMP, XAMP, etc

Local development is liberating and fast, but it can be a time sink in and of itself. When it breaks, it can cause productivity to grind to a halt, and take hours to figure out. Sometimes you end up having to re-install/rebuild from scratch. Local development requires everyone to be a sysadmin on some level in order to stay productive, which is a waste of time for some, and a virtual impossibility for others. 

3. Wondering if the code will scale

Another problem with local development is that there are plenty of things that run awesome on your laptop but don't work so great on servers in the cloud. Taking the network out of the equation is great for moving fast, but not so great for understanding how it will work in production.

4. Out-of-sync development databases

It's work to stay in sync with other developers in their own environments if you're rolling your own system. The problem is that if the labor and friction of syncing cause you to skip it, you diverge. Divergence is risk — it's a great way to have phantom bugs nobody else can replicate, or to miss out on critical dependencies or building blocks created by your team.

5. Delaying sign-off because there wasn't a stable environment for review

Or, in the reverse, delaying development in order to do QA and acceptance testing. Being productive means being able to parallelize your efforts. If you have to call a halt — or just slow down to take more caution — because you need to make something "stable" so it can be approved, you're burning project time.

6. Introducing bugs in a QA iteration

Likewise, if you have a process for setting up QA that's manual, and you don't have exactly the same setup as production, you can actually introduce bugs at this stage by "fixing" things that behave one way in QA and then another in production. It's the same kind of problem as local development platform fragmentation, except the culprit here is the testing infrastructure, not the developer's workstation. 

7. Maintaining development toolchains for your team

Do you have the smartest, most talented and experienced engineers on your team working on all this infrastructure — the local dev, the sync scripts, the git workflow, etc — instead of on the really important thing (the project)? Do you have a huge chunk of the budget earmarked for "development infrastructure"? If so, you could be getting further, faster, and with real cost savings if you built with Multidev. 

Bringing it all back home

We invented this feature because we know the pain. We've lived these problems, and we're tired of the friction and drag they create for the industry at large. Drupal doesn't reach its destiny if the smartest people in the room are stuck keeping the plumbing working. It's time to move up the stack, level up our game, and make every project a best-practice showcase. With no set up time. 

That's Multidev. That's a gamechanger. 

Topics Education

Let’s get in touch