AppLand — using the machine to improve understanding code
Why I am Backing AppLand
It’s an honor to announce that I am backing AppLand as an investor and advisor.
I have a long history with the founders — Elizabeth and Kevin. I was a founding board member at their first company, Conjur, and have been privileged to be part of their entrepreneurial journey for many decades. Kevin and I started working together at Trilogy back in the 1990's.
Why I decided to invest in AppLand?
What Elizabeth and Kevin are doing at AppLand is transformational. By building a system to enable the visual representation of code, AppLand has the potential to improve the productivity of all developers, and enable enterprises to unlock the potential of legacy infrastructure and minimize the risk of aging code bases.
So much time and effort goes into writing code that goes into production, but when that code needs to be upgraded, changed or when it breaks, it takes an inordinate amount of time for developers to understand the code base of interest. Elizabeth and Kevin have created a framework at AppLand that enables any developer to quickly and easily understand any code base — no matter how antiquated or complex it may be — so developers can fix bugs, upgrade/maintain the code base as operating systems change, enhance the code base and ultimately replace the system effectively.
Consider the old languages that run on mainframes: COBOL, Fortran, etc. Last spring, there were only a handful of COBOL programmers capable of understanding and responding to collapsing state unemployment websites. This is one example of literally thousands of situations that occur every day as we begin to deal with the legacy of all the code currently in production. If what Marc Andreesen said is true — that “software is eating the world” — then AppLand is ensuring we don’t have continuous indigestion.
All software projects have technical debt. At a certain point all code bases need to be fixed, upgraded and replaced. And to do that, you need to be able to understand how the code was written, especially any underlying dependencies and endpoints. The ability to see complex code clearly described in AppLand is a transformational experience for developers. To go from ground zero on a code base to full understanding in minutes is truly a remarkable experience.
Why hasn’t technology like AppLand’s been done before?
People have been trying to make software development more accessible for decades. In the ’80s there was CASE, and in the ’90s there was Microsoft’s Visual Basic (which later became Visual Studio). There’s also UML. One of the fundamental flaws of most of these initiatives was the temptation to use visual methods as tools to author software. Elizabeth and Kevin’s approach of using UML-like methods to describe existing code and enable developers to understand and collaborate on code is a major shift in the use of the visual methods represented by UML and other visual tools.
This shift from graphical tools for authoring to graphical tools for collaboration has also occurred in data engineering. The emergence of AirFlow as a popular data pipeline orchestration system, and its inherent use of Directed Acyclic Graphs (DAGs) as artifacts that are generated from data pipelines written in Python, is another example of the same design pattern that Elizabeth and Kevin are using for software, albeit more broadly.
How can enterprises benefit from AppLand?
Companies depend on their software infrastructure running continuously every day in order to keep the lights on, so the potential impact of one of their software systems failing is enormous. The ability to quickly triage a problem and develop fixes depends first and foremost on understanding how the existing system works.
If there are upgrades to the core infrastructure where the software runs (e.g. in the hardware, BIOS or operating system), all of these changes require testing and represent potential failures of the software — which again requires understanding how the code works in order to fix/adjust the code to function effectively on the upgraded infrastructure.
Also, every software system is really more like a service. It’s constantly in need of enhancement and can always be improved in some way. Delivering any enhancements requires yet again to be able to first understand the code.
The reality is, the software that enterprises use to conduct business is made up of decades of borderline unintelligible code written in lots of different languages by lots of different people. In the enterprise, the quantity and complexity of code will never be capable of being understood without using the power of the machine and visual methods. AppLand is the “coding exoskeleton” that’s absolutely necessary to do superhuman acts with code, even if that code is a tangled mess and decades old.
What’s the ideal role for automation and machines in software development?
Two of the most important things I learned from the late, great Marvin Minsky:
- No algorithm is useful without great data.
- Machines and humans need to work together.
When developers use AppLand, they’re effectively standing on the shoulders of machines. Machines aren’t replacing them or controlling them; machines are enabling developers to work more efficiently, collaboratively and creatively by representing code using visual methods to help developers better understand the structure, behavior and interaction of the code.
For enterprises, with their enormous code volumes full of massive idiosyncrasies, the power combo of machines + visual methods + developers working together will be the ONLY way to effectively keep the lights on, let alone have a chance of getting ahead in the digital transformation game.
What I am most excited about for AppLand?
AppLand’s story reminds me of GitHub’s. The pace at which developers are adopting AppLand is unprecedented. For a lot of companies, it takes time and lots of users to grow and scale, but AppLand feels more like GitHub in the early days. It’s so intuitive and so useful that developers will quickly come to rely on AppLand, just as they’ve come to rely on GitHub and their favorite IDE.
I firmly believe that when founding teams have previously worked together, that’s a primary signal the company has an unfair competitive advantage. I’m privileged to know Elizabeth and Kevin as friends and trusted colleagues for a long time now. They’re incredible founders who work very well together. Other than VMware, I can’t think of another example of such a powerful husband and wife founding team. I know AppLand is going to be a wild success and I’m thrilled to be on their journey with them, yet again.