Being a project lead at Delphix: Improved Replication UI

Written by Brett Lazarus, MIT 6-3 '12, MEng '13

Written by Brett Lazarus, MIT 6-3 '12, MEng '13

Since graduating from MIT (6-3 '12, MEng '13), I've been a part of the Front End team at Delphix. It's been an incredibly challenging and rewarding experience - with such a small team (around 5 engineers responsible for the entire UI) you're immediately put in a position to make a big impact on the product. It's amazing how much you learn and grow as an engineer in a year when given this opportunity. One of the more impactful experiences I've had at Delphix has been as a project lead during the most recent release.

Let me give you a quick rundown of how things work at Delphix. We release major new versions of our software to customers roughly twice a year. In a given release we'll have a number of projects going on in parallel (each project represents a feature or significant chunk of related work that will go into the next release - read more about this process here).

I find it awesome that every project is led by an engineer (recent college grads and senior engineers alike). Others have written about the importance we place on being a "holistic" engineer, and I think there's no better example of this than having the opportunity to serve as a project lead.

This past release I was tasked with leading a project to rewrite the replication screen. Replication is used to copy objects from one Delphix Engine to another and has a number of use cases, including backup and disaster recovery. The old UI was written in Flex, an outdated, flash-based technology, and had a number of usability issues. In this project we wanted to bring the implementation into the modern world of HTML and Javascript, as well as give it a fresh, clean user experience.


Old 'n busted I had at my disposal a document, called a 1-pager, that some other engineers had put together which described some of the high-level shortcomings in the old screen. It was my task to take that and figure out what exactly we wanted to build, and what it would take to build it. I started by scoping high-level features, and realized that an additional developer would be needed to complete the functionality by the end of the release. I then began making some rough wireframes of what the new interface might look like using a tool called Balsamiq.

Early draft wireframe from Balsamiq

The next step was gathering feedback on these initial designs. I shared them with others on the front end team, as well as other engineers working on replication. Ann, one of our awesome Program Managers, helped me identify and reach out to members of our professional services and support teams who had worked closely with customers on replication. This turned into multiple interviews during which we talked about customer pain in the existing UI and how we might go about alleviating that pain in the new UI. More iterations on the wireframes ensued.

Around this time we brought on a new user experience lead, Jaime, who began to help smooth out rough edges in the designs. Aaron (the other developer on the project), Jaime, and I spent hours in front of the white board nailing down the nitty gritty details of the design. Once we had a design that solved real customer pain, we worked with contractors to turn these mockups into high fidelity renderings of what the UI would look like, and to produce some of the styles and icons we would need on the page.

Jaime's improved wireframes
Jaime's improved wireframes

Around this time, the front end team made the decision to adopt AngularJS, a popular Javascript framework for building single page applications in the browser. We decided the replication project would be the pilot project for integrating AngularJS into our technology stack.

Thus, when Aaron and I set about implementing the new replication screen, our first task was to build common infrastructure that the entire Delphix UI team could use to integrate AngularJS into the existing codebase. I used JIRA, a project management tool, to break down the tasks we would have to accomplish and split up logical areas of work between us. I also coordinated with the QA lead for the project, Roma, to make sure she was up to speed on what should be tested and the expected behavior.

In only a couple months, we were able to build the infrastructure and user interface for the new screen, and have already integrated it into the product. In the end, I'm happy with what we built, but my job does not end here. I'm excited to get the new UI into the hands of real customers and gather feedback about how we can continue to improve the user experience.

new UI

While we overcame a number of interesting technical challenges, the real learning for me came outside of any coding. Understanding who the stakeholders are in your project - who has opinions and expertise on the functionality, conducting meetings and interviews to understand the totality of the problem space, making decisions and then communicating those decisions back out to stakeholders - that's the real challenge.

Understanding this is immensely valuable in the real world, even at a small company like Delphix, and is not something you are exposed to in school. Being a great engineer does not mean you do everything yourself. Being able to interact with others, plan, and communicate is just as important as coding.

The skills I gained and lessons I learned during this process are not unique to Delphix, or even software. However, the fact that I was given this opportunity so early in my career is unique to Delphix. If you are a student conducting a search for an internship or full time position, consider the incredible learning opportunity the Engineering team at Delphix can provide.

To apply, submit your resume at our Careers Page.