It’s an honor to announce Andy Palmer, Co-Founder and CEO of Tamr and Founder of Koa Labs, as a supporter and investor in AppMap. Andy is a legend in the tech community, having helped found and/or fund more than 60 startups spanning the software, healthcare and life science industries.
Andy has a long history with Elizabeth and Kevin. He was a founding board member at their first company, Conjur, and has helped guide their careers as serial entrepreneurs and technical leaders over the past two decades.
We spoke to Andy about why he decided to invest in AppMap and what he’s most excited about for the company. Read on to learn more.
Why did you decide to invest in AppMap?
What Elizabeth and Kevin are doing at AppMap is transformational. By building a system to enable the visual representation of code, AppMap 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 AppMap 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 AppMap 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 AppMap 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 AppMap 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 AppMap?
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. AppMap 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?
I learned two things from the late, great Marvin Minsky:
- No algorithm is useful without great data.
- Machines and humans need to work together.
When developers use AppMap, 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 are you most excited about for AppMap?
AppMap’s story reminds me of GitHub’s. The pace at which developers are adopting AppMap is unprecedented. For a lot of companies, it takes time and lots of users to grow and scale, but AppMap feels more like GitHub in the early days. It’s so intuitive and so useful that developers will quickly come to rely on AppMap, just as they’ve come to rely on GitHub and their favorite code editor.
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 AppMap is going to be a wild success and I’m thrilled to be on their journey with them, yet again.
Get AppMap