Building Success: How To Foster A Developer-Centric Environment
The Engineering Culture Podcast is brought to you by the guys behind InfoQ.com and the QCon conferences.
Shane Hastie, Lead Editor for Culture & Methods at Wix, talks with Aviran Mordo about creating a developer-centric culture, building a platform as a runtime environment to speed up development, and moving left in design through developer and designer linking in this episode of the podcast.
Major Takeaways
- The whole company has been simplified in a developer-centric culture to help ship software quicker.
- Because all of the structure and framework are prebuilt, the platform as a runtime allows for speedier development.
- Wix’s Platform as Runtime strategy allowed them to cut between 60 and 80% of the lines of code that developers had to create, significantly reducing development time.
- The platform infrastructure team views the platform as a product, and its clients are the developers for whom the platform is being built.
- Developers and designers working together with common tools speed up front-end development by “shifting left.”
Transcript
Shane Hastie says Good day, everyone. Shane Hastie is here for the InfoQ Engineering Culture podcast.
Today I’ll be speaking with Aviran Mordo, Wix’s VP of Engineering. Aviran, please accept my greetings. Thank you for taking the time to speak with us now.
Mordo, Aviran: Good evening and hello.
Shane Hastie says Thank you so much, and good morning to you. I’m from New Zealand. Aviran is in Israel, so thanks to modern technology, we can talk in real-time. Aviran, first of all, I’d want to introduce us to our visitors.
[00:48] Introductions
Mordo, Aviran: I’m Wix’s VP of Engineering. I’ve been with the company for a total of twelve years. Before that, I worked for a number of large companies, notably Lockheed Martin. I had my own companies. So I’ve been here for quite some time. At Wix, I’ve been an active promoter of the DevOps culture.
We call it the developer-centric culture because we place developers at the center and then the company helps developers ship software quicker, which is our goal in trying to figure out how to ship software faster.
Shane Hastie says So, how does a developer-centric culture look and feel?
[01:24] The whole organization has been simplified in a developer-centric culture to help ship software quicker.
Aviran Mordo: Think of the development lifecycle as an assembly line for vehicles. Developers are the assembly line since they create the product. So the software is the product, and they are the most knowledgeable about it.
They know it better than QA, testing, and the products that try to define them since they actually coded the thing. So the overall developer-centric look is that the entire company has a support circle with trained professionals that supports developers and basically helps developers shift products quicker.
Shane Hastie says And, for the individual developer, how can we avoid the sense of “Work harder?”
Aviran Mordo: Because it’s not about working harder, but about working smarter. You do more in the same amount of time that it would have took you before the continuous delivery trend or discovering methods to do things better.
If we’re talking about platform engineering or low code development, where you’ve stated a lot of things ahead of time and basically have to write less code and do much more in a shorter amount of time with fewer people, which we all know engineers are incredibly rare and difficult to attract. So, if you can do more, you just need less developers.
Shane Hastie says So, before we started recording, you pointed out the idea of platform as runtime. What exactly do you mean?
[02:52] Platform as a runtime
Aviran Mordo: Platform as runtime is a new idea that Wix has been working on internally. It is about platform engineering. However, if you hear all the talk about platform engineers, and a lot of companies are talking about platform engineering on the CI, Kubernetes, and all those areas of the platform, Wix is basically past that thing because we built this platform many years ago and we took platform engineering to the next level to codify basically a lot of the concerns that developers have in their day-to-day life.
However, in our own fields of business, which are basically business models, we construct websites, blogs, events platforms, and booking systems. All of these are business applications.
And for any business app, you basically have identical ideas or issues that you must deal with, such as delivering domain events, representing your companies in a multi-tenant style, GDPR concerns, GRPC communications, and how all of those things work together.
So, in most cases, we design our own frameworks and libraries as an alternative to the popular libraries that developers simply put into their microservices deployable. And this is a problem because, when we build those libraries, we concurrently write a massive amount of documentation that developers must understand in order to use those libraries. Okay, for GDPR, you must be a privacy expert.
And how does the AB testing system work, because every company has its own AB test for feature flag systems, and how do you communicate via GRP? What are the headers you need?
There are plenty of documentations that developers must learn and understand. And what we did was codify many of these ideas into our platform.
So we basically looked at the number of lines of code that developers have to write, and by studying them, we discovered that 80% of the lines of code are basically wiring stuff and configuring things, rather than writing the business logic that you have to write, the business value, that is what we get paid for, to bring business value to the business, not to wire things.
And we create our own serverless cloud, as well as our own serverless infrastructure, and we host the framework on it. Developers no longer need to compile this code themselves; they just build against an interface of some kind and deploy the app into the cloud, where they get the framework.
[05:58] Platform as a runtime benefit
Aviran Mordo: So, successfully, the platform is the runtime. It performs their business logic on behalf of them. That additionally offers us with the option to have a choke point and update. When you think about it, Wix has over 3000 unique microservices networks.
If we look at the Log4j security issue that was revealed a few months ago, we had to ask all of the Wix teams to rebuild 3000 microservices in order to recompile with, “Okay, we update the framework, we update the dependency.” Everyone needs to rebuild, recompile, and reinstall everything onto the cloud.”
And this takes a long time. Of course, many things are overlooked along the road.
So, by removing the platform and framework from the microservice and placing it outside of the microservices as a runtime, we can control these whole common libraries that exist everywhere else in all the microservices from a centralized point called the runtime. This results in a significant increase in velocity. So, before we started building, we codified all of this logic. Developers no longer need to read hundreds of docs to understand how things work. Things just work for them.
During this process, we were able to delete between 60 and 80% of the lines of code that developers had to write to achieve the same goal, greatly minimizing development time.
It took us about two to three weeks for a new microservices that doesn’t do anything. Basically, a basic crowd operation since you have to work really hard to complete all of these wiring tasks in a short of hours. So today, in two or three hours, developers might have a new microservice running on the cloud with all of the legal requirements, business needs, infrastructure requirements, and ecosystem requirements that exist.
Shane Hastie says Who is the team in charge of maintaining this platform?
[07:59] Maintaining the platform
Aviran Mordo: We have an infrastructure team that works in the same way as any other product team.
So we looked at our platform as a product, and we have technical products that are sent to different departments within the company. They sit with them, study their code, write code with them, and try to extract and discover commonality across different business units. “OK, this is something that a lot of developers do,” they comment. As a result, it is common for Wix’s business areas. And we will extract those elements and form a team of employees from various sections of the business. “Okay, what is the commonality code?” we try to figure out. Put it on the platform and sell it as a product. We had this idea before we experienced this mental transformation.
Infrastructure teams have a propensity to design things that are so wonderful that they say, “Okay, this is what developers should know and understand.”
Then, frequently, the products developed by infrastructure teams are not used or are used in just a tiny portion of the companies. So we created one primary KPI for our infrastructure team in our platform engineering team: you do something, you commit to adoption, you’re not successful just by finishing this new stunning infrastructure. It’s the same as when you create a company product and want buyers to come and buy it. The same is true for infrastructure teams. We are committed to adoption.
Our success depends by how many developers in the company use the new infrastructure. And if they don’t use it, it shows we didn’t create the correct product for them.
Shane Hastie says How do you avoid this becoming a single point of failure? How do you maintain the platform’s quality?
[09:52] Maintaining platform quality
Aviran Mordo: In any system, there is always a single point of failure. Wix places a high value on quality, especially for the infrastructure team. We use best practises for test-driven development and are continually checking things. However, because it is a distributed system, the single point of failure is not truly single.
There are hundreds of servers in service. So, unless there is a bug, you must repair it. But for that, you’ve got test, slow rollout, AP testing, and feature flex.
So all of the industry’s best practises avoid that. However, if a service goes down, it is only one between hundreds or thousands of clusters that are failing. But that happens on a rare basis. However, we consider this runtime as an important infrastructure, much like an API gateway. It’s just a vital structure with a single point of failure.
So we think of it just another layer, like a load balancer or a gateway server. This is the platform, this is the runtime, and it must be of the highest quality and performance available.
Shane Hastie says Another topic you mentioned before we started recording was moving left in the design space. What exactly are you doing there? It sounds instead interesting.
[11:13] Design shift to the left
Mordo, Aviran: We discussed how we are continually trying to boost our development pace. So far, we’ve only discussed the backend. So let’s get started with the front end.
We use the most frontend devs in Israel and the largest design studio in the nation since Wix is a website development platform. So we have a lot of experience watching how frontend developers and designers work.
And we discovered that they don’t truly work together, but rather cooperate. So, in most situations, when you want to develop a new web application or website, you have the designer design in whatever design programme they like, such as Photoshop or Figma, or any other design tool that they are comfortable with.
The designs are then handed over to the developers, who try to turn them into HTML and CSS to the best of their skills and tools.
It is a browser. So it’s two separate tools with features that aren’t always compatible. And there’s always the ping-pong game between designers and coders. And then, for every change, even within a product’s life cycle, for any change that marketing or the business product wants to make, they have to go back to the developers and say, “Hey, I need to move this button from here to there.” Please adjust the colour, or we are going to do a test.” Or anything along those lines.
And it is a waste of developers’ time and skills because if I need to move something on the displays, you don’t actually need a developer to do it. As a result, we want designers and developers to use the same tools. This is when the flow code movement comes into play.
So, who is one of the players in this field? So we created Editor X, a software that allows designers and developers to work on the same tools as designers move components around. They display it on the screen, and developers use the same IDE, which is basically a visual IDE, to codify their components.
As opposed to developers… I wouldn’t call it a waste their time, but rather spending their time in trying to move things around or make the pixel perfect, playing about with CSS and browser compatibilities, developers and designers operate as one team.
As a result, the design becomes just another developer’s duty, while developers define the real business logic that runs below the component. As a result, we formed an entire group capable of working more efficiently and effectively. And if product managers are interested in changing something on the screen, they don’t have to go to developers, who are the organization’s most expensive resource.
Because you are working in the same environment, our developers might have designers or UX experts play around with the design and tweak it without affecting the code.
Shane Hastie says As a result, this is a greater level of cooperation. These are frequently folks with extremely varied skill sets as well as viewpoints. How can you bring them all together as one team? How do you create a single team culture?
[14:50] Creating a one-team culture
Mordo, Aviran: As a result, this is something that is built into the way Wix works. Our organizational framework can basically be described as corporations and guilds. Companies create of it as a collection of individuals who are in charge of specific business areas.
So they really build the product, and they have their own 1, 2, 3, or as many teams they need. So, in this team, you have developers, QA, product managers, as well as UX experts and designers, and they all work together.
Then there are the groups, the professional groups that are in charge of having the standards and professional competence, as well as developing the tools for each profession.
So having everyone on the same team, with the same business goals, offers a holistic team that, instead of throwing the work over there, and this fits in with all the DevOps, continuous delivery culture where, instead of throwing the responsibility, “Okay, I’m done with my work now,” Okay, product manager, you’ve finished your task; now go developers, create right away, and QA test.” And in our system, they operated, we created an entire dev-centric, developer-centric culture where it’s one team with experts, topic experts, they’re all working together as a team to basically help the developers ship the product. So designers just become a member of the development team.
Shane Hastie says With the corporations and groups, that structure makes sense; what you’re calling the company there, I’d call a value stream. How are these businesses rewarded?
[16:33] Internal company motivations
Mordo, Aviran: They have their own business KPIs, and it’s not a profit and loss statement, especially at Wix because we have companies whose products generate revenue. For example, an e-commerce platform is a revenue-generating product. You have folks coming in and buying things. But we also have another business, such as a blog company. The blog is an afterthought. It is a must for the whole Wix ecosystem because most websites need a blog. However, a blog is a free product. As a result, every company has KPIs.
So, if the blog’s key performance indicator is uptake or the number of customers, they are not paying customers.
However, we can see that the product is being accepted. Many websites have blogs installed, but the econ platform or the supplier of the payment, who are in charge of accepting and processing payments, have their own KPIs. So payments are not something you sell, but rather something you handle. So their payments KPI will be the number of transactions we handled or how many customers choose to install, for example, Wix payments rather than just use PayPal or any other alternative payments, so they have their own KPIs and the e-commerce platform has their own KPIs, correct?
They know the amount of stores or the number of transactions or the GPV, and every company has their own metrics.
Shane Hastie says And how do you keep those goals in sync with the general aims of the organization?
Aviran Mordo: I’m talking about our organizational framework. We name them companies rather than value streams because we see them as startups within bigger companies. As a result, every company has its own quote unquote CEO. They are referred to as the company’s CEO, and they have their own engineering manager. And they are basically sponsored by Wix as a whole. While they have their own KPIs, imagine startups, which have boards of directors who match them with strategic goals.
So every company has a chairman, who is effectively the board of directors.
The chairman is a member of Wix’s senior management group. And, between the CEO and the Chairman, they can make 95 percent of decisions without engaging the whole Wix executive team. So the chairman, who also serves on the board of directors, aligns the business with Wix’s goals while also taking into account the needs of this mini-company within Wix. So it’s the same as every other startup.
Shane Hastie says Interesting company, and it seems like a fun place to work. Thank you kindly. Some wonderful examples of tools and strategies to boost velocity, and I believe our readers will learn a lot from this. Where can folks locate you if they wish to continue the conversation?
Aviran Mordo: They can usually find me on LinkedIn. I’m also on Twitter, although I prefer LinkedIn.
Shane Hastie says Wonderful. Thank you really a lot.
Mordo, Aviran: Thank you very much. It’s been an honor.
As you wrap up, consider fueling my creativity with a $1 coffee boost!
