Engineers and customers
Today I took the train out to Long Island to meet up with our New York sales team for a visit with a prospective customer. You never know with an initial meeting, but this one was great. I thought I'd share a bit about what made these guys so excited which is the same stuff that gets me excited about what we're doing at Delphix.
First though, there are some engineers who have never spoken with a customer. There are some engineering organizations in which requirements are collected from customers, correlated by product managers, handed to engineering managers, and given to engineers. It's a fine workflow, but this needs to be balanced against engineers engaging directly with customers, hearing their issues, and brainstorming solutions technologist to technologist. Engineers talking to a small number of customers may miss broad trends or fail to connect certain dots, but it's a complementary activity and part of being a holistic engineer.
I've heard software engineers groan that the right technical decision was trumped by business concerns. Those people might be good engineers, but they aren't great ones. Engineering can't stop at the boundaries of software; it must necessarily consider the whole ecosystem of the product and the company. Yes, we might not have architected the feature this way if we didn't have legacy customers support, but we do (and we should be happy for it). (And, of course, this logic can be taken to the other extreme with equally bad results.) This doesn't mean that a great engineer collects all data first hand, but the whole system must be considered, and walking into a customer's office from time to time is a reality check.
In today's meeting, the customer was learning about Delphix for the first time. And they got it right away. As with many enterprises, they have a initiative around virtualization to enable more self-service and more empowerment of their developers. The data in their relational databases is a big anchor weighing down those efforts; the time and effort required to copy and provision databases is a huge drag. Smart guys, they oscillated between how Delphix works -- a super-smart, database-optimized storage gateway -- and what Delphix does -- virtualizing their Oracle databases, bringing the agility and cost-savings of other virtualization technologies. And the slide-ware made real through a demo of the product GUI elicited an terse expression of comprehension: "That's cool."
And maybe the best reason for engineers to get into the field is to witness customers who get how cool the product is.
Delphix Next
It's rare to get software right the first time. I'm not referring to bugs in implementation requiring narrow fixes, but rather places in a design that simply missed the mark. Even if getting it absolutely right the first time were possible, it would be prohibitively expensive (and time-consuming) so we make the best decisions we can, hammer it out, and then wait. Users of a product quickly become experts on its strengths and weaknesses for them. Customers aren't beta testers -- again, I'm not talking about bugs -- but rather they expose use cases you never anticipated, and present environments too convoluted to ever conceive at a whiteboard.
When I worked in the Fishworks group at Sun, we learned more about our market in the first three months after shipping 1.0 than we had in the 30 months we spent developing it. We found the product both struggling in unanticipated conditions, and being used to solve problems we could have never predicted. Some of these we might have guessed earlier given more time, but some will never come to light until you ship. That you need to ship 1.0 before you can write 2.0 is a deeper notion than it appears.
I joined Delphix a couple of weeks before our formal launch at the DEMO conference. Since then, we've engaged in more proofs-of-contept (PoCs) and more customers have rolled us into use, and we've continued to learn of new use cases for Delphix Server, and found the places where we needed to rethink our assumptions. And we knew this would be the case -- you can't get it right the first time. Over the past several months, we in Delphix engineering have been writing the second version of the most critical components in our stack, incorporating the lessons learned with our customers. The team has enjoyed the opportunity to revisit design decisions with new information; it's fun to feel like we're not just getting it done, but getting it right.
When building 1.0, you make a mental list of the stuff you'd fix if only you had the time. In the next release, you figure out all the whizzy stuff you now can build on the stable foundation. We're excited for the forthcoming 2.6 release -- more so even for new ideas we found along the way that will be the basis for our future work. We've got a great team working on a great product. Check in on the Delphix blogs in the coming months for details on the 2.6 release and the other stuff we've got in the works.