Beyond Angry Birds: Developing Transformative Enterprise Apps

Countless developers have set out to strike it rich with a one-off consumer app that somehow breaks away from the field and, against all odds, becomes a massive, and massively profitable, hit. Think Angry Birds, Fruit Ninja, Cut the Rope and many others. As high profile as these examples might be, the fact remains that the work of enterprise developers—that is to say, the developers who work on apps that are not meant for public consumption, but are instead used within the company—can have an equally profound impact on individual businesses and, indeed, on entire industries. John Jeremiah, a digital researcher for Hewlett Packard Enterprise, spoke with HPE Matter about the ways in which the core principles inherent in DevOps are transforming how enterprise developers create and deploy code, how empathy can increase productivity and why the phenomenon of “distributed trust” has so much power—and has become so commonplace—among developers and non-developers alike.

As the DevOps methodology and the notion of continuous delivery gain traction across a wide variety of enterprises, how critical is the element of trust between development, operations and production team members?

Whether a team is building and deploying a mobile app, a website or an internal enterprise app, trust—both in one another and in the process itself—is central to the effort. But actually, there’s another more telling word that’s commonly used around DevOps these days, and it’s a word that often throws people for a loop: empathy. This means empathy for the work of others and an understanding of what every person is responsible for and how they’re accomplishing what they set out to do. If you’re a developer, it means having empathy for the folks on the ops side of the house and if you’re in production, it means knowing what the developers’ responsibilities are, and so on.

Doesn’t everyone involved in this process—developers, operations people, the entire team—have to exhibit empathy for the end user, too?

Yes, definitely, and this touches on the role of continuous assessment. We talk a lot about continuous delivery or continuous deployment of code, but we can’t underestimate the power of bringing together feedback, monitoring and an understanding of what users are doing with that code. Let me give you an example. MyComp is a mobile app used by members of Hewlett Packard Enterprise’s sales force. These members work on commission and they use it to gauge what their compensation is going to be for any given period of time. In order to enable and drive continuous assessment, the app team created MyComp with a telemetry package that provides constant insight into how fast the app responds when a particular button is clicked and how quickly the app launches. It tells the team when the app crashes and what the user was doing right before. It tells which features are being used and which aren’t, and then it summarizes all of that into a single number called the “fundex.” That is, how much fun is a user having and how engaged is she with the app? The team uses this information as part of their continuous effort to assess, improve and enhance the experience. So, again, that’s where empathy for the user comes into play.

Talk a bit about the role that speed plays in today’s development cycle.

When I talk about developing and deploying faster, I don’t just mean pushing code and changes through a fire hose into production. What I really mean is that teams are moving faster because they’re getting continuous feedback on any changes they might push through. The ability of a team to give and get feedback quickly—this worked, this didn’t, this is what we have to change—is one of the fundamental principles in DevOps. But all too often, the only message that people hear when DevOps is discussed is that code will be delivered faster. Period. They hear that Amazon, for example, deploys code changes every six seconds, and they freak out. What’s missing from that discussion is that when Amazon is making changes at that pace, the vast majority of them are very small and the team making those changes is listening intently to the feedback from an experiment and reacting to it. This is the reason Amazon is able to deploy at that velocity.

We’ve talked about trust, both inside and outside of the enterprise environment. One of the transformative forces in the online economy today is the notion of “distributed trust,” in which people who purchase or exchange goods and services from individuals rather than traditional vendors expect transparency in their dealings. How big a deal is distributed trust, really?

It’s huge. Think about it. When you buy something on eBay, what’s one of the first things you do? You check out the ratings and reviews of who you’re buying from to see whether you’re his or her first auction or the 50th. The same is true with Uber. When I look at the rating of the driver who’s coming to pick me up, I can decide to cancel the ride and re-request it. And, by the way, he sees my rating, too, and can decide whether or not to take me. Then there are hacker communities operating out there on untraceable routers—a separate Internet, in a way—and they’re selling and sharing hacking scripts and credit card numbers and what have you. Well, guess what? The ratings and reviews of the buyers and sellers govern that economy and that market, too! So distributed trust is hugely powerful and it’s everywhere. In the open source community, if some code goes south or if a Wikipedia article suffers in quality or accuracy, people rush to fix it. That’s a form of distributed trust.

In the end, though, all of this transparency is excellent protection against getting scammed. The more transparent transactions are, the more transparent relationships will be and the easier it is to make choices with at least some understanding of the sort of risk you’re dealing with. I don’t know if we’ll ever prevent risk entirely, but because of this culture of transparency, which is thriving today among developers, we can all make decisions armed with more information than we’ve ever had before.