DDEV: Looking Back, Looking Forward

This article is rewritten based on an interview with Rick Manelius.

The recent DDEV 1.0.0 release has given us a moment to look back over the last year and look forward to what is coming next. Our vision was to produce a tool to allow you to set up local development environments in minutes. It’s the center point of our vision at DRUD; to work with any CMS and framework you do, and on any hosting platform you need to deploy to. Here’s a peek into some of the decisions we’ve made along the way. 

“It just works” reflects empathy for users

Back in ‘99, I worked in a PC computer store where we built $3000 USD custom PCs from scratch. I built my own computer before I went to college thinking “Wow, I saved so much money!” I got it just the way I wanted it. That is, for about a two week period until both my CPU and my video card broke at the same time. This took multiple trips to the computer store to fix it, and just when I thought I had fixed it, it wasn’t fixed. I systematically replaced each part of my machine. Finally, I realized, wow, so for the $400 I saved, I blew 2 weeks of time during a semester at MIT. I spent time and got stressed while I was trying to do school work working instead on my machine.

After that, I immediately bought a Mac, and I bought into Apple’s whole “it just works” campaign. It was just the cusp of OS X coming out, so it seemed they made *NIX cool and accessible. Nowadays, Ubuntu is doing a fantastic job of making Linux to appealing to users that want a no-fuss experience. But at the time, Mac OS X had done something amazing. To me, the choices Apple makes shows empathy for users.

If you track Apple’s approach into mobile, people would criticize them for lagging behind. Android always releases features before Apple. But Apple knew that if they didn’t get it to a point where it was simple, it wouldn’t work. At two years old, my daughter could use the iPhone better than she could talk, with no instruction manual.

However, Apple’s products are notoriously less flexible. You’d have to go through hoops to even change something like your default browser. There’s an inherent tension between flexibility and reliability.

Delivering on a promise

With DDEV, balancing between flexibility and reliability affects all the choices we make. Sometimes you can make things reliable and upgradeable but you lose flexibility. When you focus on flexibility, it comes at the cost of being unmanageable and unwieldy. We have strong empathy for users who have been burned on dev tools in the past. We want to build a reliable foundation you can build on to users that want a no-fuss experience.

When people ask me: Why DDEV? Why can’t you just use native Docker? I explain that we want to make Docker accessible in a way the end user expects it to work they way they work. Most developers have bought into using Dev > Stage > Prod workflows. They want the flexibility of Docker with per-project changes and overrides. But they want it as simple and reliable as a MAMP.

DDEV tries to be more opinionated because we’ve seen the pain of lost time due to inconsistencies and unreliability of past solutions. Why fight with your tools? Or why change your workflow to match your tools? I want my tools to anticipate my workflow. Yet, DDEV can’t achieve that for everyone. There are always sacrifices to be made.

Of course our approach doesn’t make all users happy all the time and, as a result, we’ve received criticism about certain features we don’t have. ‘Oh, you don’t already have Varnish, Redis, support for CMS X, etc?’ The thing is, to achieve “just works” requires going way beyond the 80/20 rule (where you can get 80% of the way there with just 20% of the effort) and put in a lot of additional effort and care to get developers much, much closer to that 100% mark. It’s why a lot of other projects may have more features and yet more fragility and/or support requests because the number of variables to track and maintain is simply too much to track. Ultimately, we want users to trust us when we commit to supporting a specific feature, CMS, or operating system.

That’s why we have full test coverage against Mac, Windows, and Linux. It’s a lot of extra effort to get that in and make sure it works. We can’t just throw in features and say “Well we think it works, and if it doesn’t our users will tell us!” If users are telling you it breaks, it’s not a great user experience.

That’s a practical decision for us. If you’re giving something away for free, you have to consider the level of quality support you can offer.

DDEV also represents our products and services for everything we do. I ascribe to Seth Godin’s definition of “brand” as continually delivering on the promise and expectations you set.

“A brand is the set of expectations, memories, stories, and relationships that, taken together, account for a consumer’s decision to choose one product or service over another.
If the consumer (whether it’s a business, a buyer, a voter or a donor) doesn’t pay a premium, make a selection or spread the word, then no brand value exists for that consumer.” – Define Brand, Seth Godin’s Blog.

The expectation we’re setting with DDEV is that we understand that web development is hard because it’s getting more complex. The demands are higher because you have to do more with less, and manage more complexity with fewer resources. In order to advance we have to stand on the shoulders of giants, and build layers on top of managing that complexity. We want to provide a stable and reliable base from which you do your creative work.

Tortoise versus hare

In his book ReWork: Change the Way You Work Forever, Jason Fried addresses a simple product management question: How should you track customer requests? “Don’t,” he says, “Don’t write them down.” Not even in a spreadsheet!

“The requests that really matter are the ones you’ll hear over and over.” – Jason Fried, ReWork

Jason Fried has made an art of saying no to build Basecamp. For DDEV, Apache is one of those things that was an obviously important request. We know this is a demand, and we’re working on getting it in there and making sure it works.

The paradox in product development is that it’s easier to add a feature than take one away. Over the first year of developing DDEV we could have added support for everything out of the box. We’ve seen this with other products that seem to support many CMSs, but they are really just examples. It may not be something to bank your production team on. Will it be there in a week, or a month, or a year? This is not a criticism, it’s simply a different approach. You can add loads of features, see which ones die off, and pare them back.

We’re trying to take a slower approach. We add features incrementally based on what has the highest value. Then we make sure it’s right and solid. We want to give our users a stable foundation they can depend on now and in the future so they can commit to the tools we build for them.

Managing commitments

In Getting Things Done (GTD) David Allen talks about not managing time but managing commitments.

“Every commitment unfinished is an ‘open loop’; and when it is tracked in your psyche, instead of your system, it will require energy and attention to track and maintain.” GTD Best Practices

This reminds me of Gulliver’s Travels to Lilliput, where they lashed him down to the ground with many strings. Each commitment is like one of those strings. As I’ve written about before, it’s death by a thousand commitments. If you’re overcommitted and then try and move, this dragging force will prevent you from being able to go in any direction. As the product matures, and you have thousands of users, you can’t make breaking changes. We have the luxury now, while we’re small and growing, to feel this out.

Here’s an example of one such debate, for which we don’t have an answer to at the time of writing…

A practical element in a DevOps process is parity between development, testing, and production environments. Clearly, some users need Apache to achieve this, so we’re adding Apache. With the current single NGNIX container, users can toggle between all versions of PHP. Now that we’re adding Apache, should we use a one container strategy? What happens when you want a container to mirror the conditions in a host different from any other? If you have one container that does everything, you can never achieve parity.

It’s like Duplo versus Lego. With larger components, you can’t have as fine-grained a customization. The choice to change to smaller components seems obvious. But this causes problems because you need test coverage. Instead of having one file where I manage one container, I have to run my test against all these combinations. It’s not unreasonable to find agencies that use five CMSs or frameworks and five hosting providers. With 5 CMS’s x 5 hosting providers this is 25 potential combinations need to test.

So, we will be figuring this problem out so our users get what they want, but also the reliable, stable experience they need.

The space between the notes

One thing people have told us they like about our project is the level of responsiveness they get for issues and feature proposals. They may not get a “yes,” but they will get a response. Our users have come to us with brilliant feedback and requests that have shaped the project.

We’re sensitive to people’s feelings about these decisions. When something doesn’t fit it’s hard to say, “That’s a fantastic idea, but the answer’s no,” and have a user understand why. We didn’t get to this decision in a vacuum. We’re the ones that have to commit to it and support it well after user X was unblocked from feature request Y. We have to be financially responsible for it. And we have to navigate political waters.

Prioritization means saying no. There are going to be more ideas than we have hours in the day. We have to prioritize. I’m always considering. What can I get done in two weeks? What can I get done in a month? In a quarter?

We often hear requests like, “If you just did THIS, I would use DDEV.” If you chased every ultimatum like that, your product would have a bazillion small features. It’s so seductive to chase those things because you want to keep every user.

“If you chase two rabbits…You will not catch either one.” – Russian proverb

You want to catch a rabbit? Going in many directions, you won’t get anything. Forget about chasing both, and just chase one rabbit. You don’t want to wake up in a few months and discover your product is completely tangled.

As they say in music, it’s not the notes, but the space between the notes. And in sculpture, it’s the negative space you carve out around it. What makes products and services excellent is as much a result of what you leave out as what you include.

Music is the space between the notes – Debussy

Growing DDEV

We’ve seen some great growth in DDEV in the last few months. Over a 90 day period between April to July, we’ve seen more users, more activity, and more feedback.

* Everytime you “star” our project on GitHub, a DDEV developer smiles.

Thanks so much for your continued support. Sign up for our newsletter for more product news and announcements.
Join Newsletter

Photo by Michael Skok on Unsplash

Share this post: