Defining, Communicating, Generating, and Verifying Modern Personal Apps: A Comprehensive, Accelerated, and Understandable Approach

Introduction

The most important task to begin the process of creating an app for customers is to understand what they really want. This is not an easy question to answer. There are three reasons behind this: 1. There is no optimal way to define the app from a technical standpoint; 2. The Discovery process requires a lengthy time to produce a comprehensive definition, receive feedback, revise and reiterate. 3. There is no optimal way to communicate the definition to the customer. In this article, we consider the drawback of the existing approaches and suggest future directions to overcome these issues.

About the Author

I am the founder and CTO of Apsy, where we use machine programming to automatically generate repeatable parts of the apps to lower the cost as much as possible. Before Apsy, I worked at the head of engineering a director of digital platforms and senior director of advanced systems leading projects to build apps and digital systems. I am also a Ph.D. student at USC researching machine programming and app theory.

Problems with Existing Approaches

From a software architecture perspective, the existing approaches to express app specifications date back to the 1990s. There has not been much development beyond UML diagrams or similar tools. While such tools are great to describe enterprise or complex systems, they are unconscionable when it comes to accurately and comprehensively describe a typical modern personal app like Uber and Postmate in a way that leaves out any ambiguities from functionality and usability perspectives.

From a product analysis standpoint, ideally, one would like to have a 100% accurate definition, covering 100% details of what will be implemented to be available immediately after the customer explains what she wants. The only thing we can think of having these two 100% attributes is the code itself, but it cannot be available right away. It will be, of course, when the project is over. Agile processes can help with an internal project where stakeholders are part of the same organization and can be reached out and frequently negotiated without any hard feelings but are not applicable when we would like to sign a contract for a less-than-3-month app project where the contract has to be signed within a week.

Lastly, from a communication standpoint, expressed in information theory jargon, we deal with a low signal source, a noisy channel, and a lagging receiver. The source is the customer normally has some general idea about what the app should do but has not thought through all the features and scenarios involved. People who have a background as a developer know that even with a well-defined set of requirements, they come across many cases that requirement is vague or contradictory as soon as they start writing the code. The channel being the media over which the requirements are communicated normally a textual description as much as PMs try to make this textual description structured and detailed — like following the typical user story template of “as an X when Y then Z” — users cannot 100% understand it until they see it. Finally, the receiver being the developer, is constantly falling behind. Before finishing what they thought was agreed upon, they are told they have to throw it away and start working on a new version.

Our Proposed Approach

What if we could develop an approach that can address all of these three concerns: an approach that can generate a comprehensive definition within a few days, conveyed in a form that the customer can easily understand? From an app builder's point of view, this would significantly lower the cost of building the app since it can minimize the amount of wasted work. It can also increase customer satisfaction since she will not come across missing or unexpected features during the alpha release. It means a shorter time for both the builder and the customer to complete and use the app, allowing them to embark on what they intend to do after the app is ready.

We want to achieve an approach that can help us realize a comprehensive, accelerated, and understandable app definition.

Having access to such a definition, we can continue applying novel techniques in machine programming and automated verification to generate and verify apps completely at a very low time and cost and with a much higher quality and customer satisfaction.

Different Perspectives

We can study the entire lifecycle of creating an app from 4 different perspectives:

Software architecture

Research approaches that can express an app comprehensively yet not excessively.

Communication

Research on approaches that can convey the information obtained in the first step in a non-technical visual fashion so that users can completely understand it and provide relevant feedback using the same approach very quickly.

Development

Research on approaches that can turn the descriptive artifacts into code in an automated fashion. These approaches can benefit from ML techniques like machine programming.

Quality Assurance

Research on approaches that can verify the app has addressed every expected requirement.