The Future Of DevOps: Continuous Design/Continuous Integration

As the Parabeac team explores new tools and processes for enhancing application development we see an impending inflection point in the story of developer technology. Agile processes and DevOps tools have become mature contributors to the evolution of developer operations but recent innovations in DevOps foretell a brand new family of developer technologies that we call Continuous Design / Continuous Integration (CD/CI). If we are to exploit this trend we need to understand exactly how our industry has gotten to this turning point and what it means that we are here. The starting point is recent innovations and what they tell us about what’s still to come.

DevOps Innovations

DevOps is the term used for the tooling infrastructure surrounding Agile methodology and it enhanced much of the development process by automating & integrating operations. Its key contribution was making processes continuous. Legacy DevOps tools address different parts of the Agile development cycle: tools that enable teams to regularly add changes and deploy projects (Continuous Integration & Continuous Deployment); support consistent progress as a project is designed, developed, tested, integrated, and deployed (Issue Management); enabling a single point of truth (Distributed Hosting); etc.

But most exciting are the recent innovations around the Design and Build layer. Design and Build include low code/no code innovations, code generation, and handoff tools all of which address the designer/developer workflow but in very distinct ways.

No-Code tools are often used by entrepreneurs to launch Minimum Viable Products (MVPs) and by small and mid-sized businesses to solve operational problems or support discrete marketing efforts.

No-code platforms are generally model-driven tools where a non-coding end-user can decide on an app design by dragging and dropping from a pre-set menu. No-Code enthusiasts (sometimes called “devsumers”) may stitch together many No-Code tools in building applications. Examples of these tools are Bubble, Glideapps, Airtable, Zapier.

Low-Code tools are frequently used by enterprise companies in which IT teams are creating internal tools or simple external applications on behalf of general business operations. These tools include Mendix, Vantiq, Unqork, Retool, etc. While many of the low-code providers have very similar tooling, such as a UI editor & low-code ‘IDE’ for writing logic, they often specialize in specific verticals. For example, Vantiq specializes in low-code applications made to connect to IoT devices.

Design-to-Code tools are code generation tools that interpret design files and generate code. These files can be architecture design, UI/UX design, schema design, and others. These tools include Parabeac-Core, Supernova, Visual Paradigm, DraftBit, etc.

Handoff tools like Zeplin, Avocode, Miro, Figma, etc. aid the interaction between system design & development. These tools help the developer understand the communications that the designer makes through the design files but, unlike design-to-code tools, handoff tools do not actually generate code. They do, however, allow for continuous communications during the entire project.

Design and Build Challenges

Expectations vary on the impact of low-code/no-code. Many argue that low-code/no-code will replace the entire development process, ultimately obsoleting traditional developers. Others argue that these tools have only specific use cases within the process. Historically, no-code has automated and replaced only a small subset of development in the various areas in which it has been adopted.

WordPress is an example of automating the development of static, manually created HTML and CSS sites. However, despite the impact it has had on website development, WordPress has had minimal impact on web app development because project needs are generally too complex to automate and it is too difficult to integrate the no-code/low-code output into the developer workflow.

Handoff tools give the developer more context, but while the process is continuous, it lacks direct integration into the workflow. In contrast, design-to-code tools are a direct integration of design and development, but these tools do not ensure that the process is continuous. Instead, when a designer hands over a new generation of design requirements for an existing project, there is an immediate requirement for manual copying and pasting. This is a frustrating nuisance that can become costly and time-consuming as the project matures.

These shortcomings are all the more curious because in recent years the design process has moved from physical to digital whiteboard through tools such as Figma, Miro, and AdobeXD. Since design is now established digitally, this should have presented a clear opportunity to automate code generation. Why then is there no popular digital tool that performs high-quality Unified Modeling Language (UML) to code generation?

Tools that have attempted to do so have consistently failed to provide the quality of code demanded by developers. Adobe, for example, invested into building its AdobeXD to Flutter converter only to see it deemed unusable by many across the Flutter developer community because of the poor output code quality. What accounts for the difficulty?

Unfortunately, even as design was digitized, how we communicate fragmented. Agile’s impact on removing segmentation within development teams led to the disparagement of ‘software architects’ and a disagreement on how to design architecture and utilize UML. Teams created their own unique flavors of UML or diagrams to describe their designed architecture depending on the context of the project.

UML’s lack of standardization and functionality around architecture definition led to UML diagrams that are too often ambiguous and subjective. Context-driven design was meant to solve this by making things simpler for other humans to read but in doing so it added complexity in the way non-human tools can interpret design files.

While digital whiteboarding introduced platforms that communicate as well as provide APIs for interpretation, the rise of context-driven design complicated these interpretations. So, can a process be created that combines the benefits of both design- to-code and handoff? Can this process be continuous and integrated? At Parabeac, we are betting on it.

Continuous Design / Continuous Integration

The interaction among the many tools already in the design & development space all point to a completely new emerging category which we call “Continuous Design / Continuous Integration” or “CD/CI”. How will it redefine DevOps?

First, it is important that from the very beginning we are precise in our definition of CD/CI. The driving goal of CD/CI is to remove the duplicated work from design into development. To be genuinely CD/CI, any tool, whether ours or others, must satisfy what we call the Parabeac test, namely does the platform meet at minimum three requirements:

• Generate usable code
• Allow for continuous design updates
• Directly integrate the design workflow into the development workflow

To be considered CD/CI, a tool must capture the continuous design process seen in handoff tools while leveraging the direct integration in design-to-code tools. For example, in a UI/UX Continuous Design / Continuous Integration platform, code should be generated each time the designer creates new UI updates, and those changes should be merged automatically through the use of git. In a CD/CI tool every design file automatically generates a pull request. That’s what we are building toward.

This will be transformative. Writing the design into code is redundant work because the developer is simply transcribing into code his interpretation of what the designer has already created and often doing so imperfectly. Automating design to development is a clear and compelling opportunity for a major leap forward in development productivity.

How major? According to industry observers, creating the user interface typically takes up to 60% of development time. This easily represents the most attractive opportunity since Agile itself to redefine how apps are built. Not only is it an enormous cost component in building apps, but mistakes between designers & developers increase the cost of the development even after launch.

The Challenges

This brings us back to the question we raised earlier regarding UML to code; if CD/CI is so compelling why hasn’t it already been introduced? It is because while automating the conversion and integrating design & development make obvious sense, there are plenty of challenges. Since CD/CI represents a higher standard than simple design to code conversion those challenges become even greater.

Once again, the problems center around context-driven design which we mentioned earlier. More human-like design input (good) makes interpretation complex (bad). CD/CI tools will support context-driven input, but they will also need context-driven output. To establish context-driven input, tools will need to create protocols or standards to which the input will map. To establish context-driven output, tools will need to ensure the way they generate code is both configurable and dynamic.

Each development team has its own set of design patterns and its own standard for “quality code” so expecting a statically generated code converter to meet that broad set of very specific and different expectations is a bad bet. The tool must be manipulable and flexible in order to produce output code that will pass a modern “Turing test”, so good as to be indistinguishable from that generated by a human.

Many current tool providers have underestimated the critical requirement of high-quality code and ignored the fact that each developer team programs in their own unique way. It takes substantial investment and repeated iteration to create a tool that generates code that is both high quality and highly configurable. Early providers have tried to be all things to all developers and have ended up being nothing for anyone.

Consequently, the market for effective tools is likely to fragment around specific development frameworks because the best platforms will be ones that have selected sweet spots against which to direct their resources. At Parabeac we approached those challenges with two specific strategies that may likely be adopted by future CD/CI providers in other segments of the category.

First, to meet the output quality demands Parabeac chose to focus on one output format, and only one. We standardized on Flutter, precisely because we could direct all our resources to it and, in doing so, become the design-to Flutter experts and produce truly excellent output. We just could not accomplish that if we were trying to force one tool to generate in multiple output formats.

If you are building in Flutter our web app, Parabeac-Nest, is an outstanding CD/CI option. But if you are building in another output format someone else will need to help you. That is how the category will develop.

CD/CI platforms that guarantee superior code quality bring the additional potential to extend directly into the low-code/no-code space. Existing low-code/no-code tools like Bubble do not produce actual code which means developers cannot create plugins for it; others like WordPress generate code so complex that it is not usable. Because specialized CD/CI platforms will actually generate quality code, those technical limitations disappear.

Parabeac’s second major strategy came from our obsession to make certain we were building what developers actually needed and that our code was aligned to real-time developer demand: we decided to open-source our conversion tool, Parabeac-Core. We anticipate the other CD/CI tools will follow this strategy because a global open-source community means active developers are constantly contributing to the way our generator exports code. The community becomes the real-time standard of excellence and utility for a CD/CI platform. By relying on an open-source strategy we do not decide what developers think is high quality; developers themselves do.

As CD/CI tools mature, they will reinvent bilateral communication between design & development. To continue the improvement of the CD/CI workflow, changes on the development side will need to be communicated back to the designer. The ideal functionality is one in which the tool automatically turns every design change into a pull request in git. In order to start that flywheel, Parabeac chose to create a design language to map design files to Sketch & Figma on the input side. We fully expect proliferation of the CD/CI category will eventually include other design tools and platform choices along with codegen extensibility.

The Opportunity

In important ways, CD/CI is Agile’s natural extension. Agile gave adaptive energy to the build and deploy stages of app development. CD/CI simply extends that backward to include the design stage as well. CD/CI, like Agile, integrates previously segmented workflows and embraces frequent iteration. In Agile’s case, the process led to the development in recent decades of a fleet of new DevOps tools.

CD/CI may mature in reverse; the true CD/CI tools that are just now appearing at Parabeac and elsewhere will lead the extension of process transformation in the design stage in ways that we, frankly, can only imagine. When CD/CI platforms become an integral part of automating developer workflows, the staggering 60% potential reduction in development costs may actually be a smaller long-term benefit than the unshackled design creativity that can now be purely and seamlessly translated into code.

If you made it here, thanks for reading! Would love to hear your feedback on how this trend will shape out. This article was part of a longer doc which you can find here: http://parabeac.github.io/CD-CI