Friday Links

  • Van Gogh Museum to present extensive Gustav Klimt exhibition
  • How Platform Engineering Helps Manage Innovation Responsibly – “Platform engineering’s primary objective is the efficiency of engineering within the organization,” he said. In other words, it is about enabling developers to build and deliver high-quality software more efficiently.
  • Security as a Product – Treating Security Like a Product at the U.S. Army Software Factory – “To meet the need, they developed a position called the application security validation engineer (ASVE)…. The ASVE is a code-first role with a focus on soft skills. This individual requires a high level of empathy to work between security, application development, and platform engineering teams. Often, miscommunication and misunderstanding occur between these teams due to competing goals, poor implementation practices, and misaligned incentives. The ASVE helps align teams and keep them moving toward a common goal while removing blockers and enabling collaboration and communication… When input controls, measurements, and defined goals are integrated into application development, security becomes part of the overall process and the final product instead of an afterthought or roadblock. Treating security like a product garners buy-in from the application team to focus on security outcomes during app development.”
  • There’s no such thing as data “SQL colonialism,” or “data as oil” is a ok simplistic or a metaphor.
  • Securing kubernetes stuff: a reference architecture and a hardening guide.

One quick way to find developer toil

Trying to improve how your organization does software? If you don’t know where to start, start looking for developer toil. Here’s one type: simple onboarding. Check out a systematic way to find more and speed up here.

Here is the transcript:

Let’s talk about developer toil. If you’re looking to improve the way that you build, you write software, you know, digital transformation stuff, the important thing is to actually get started.

And one thing you can get started on, if you don’t know what else to pick is to ask developers how long it takes them, just to get setup. I assume that you give them a fresh new laptop and find out how long it takes, it’ll probably take days, if not, maybe a whole day. And that will help you identify many things that developers toil over and give you something to start with as far as fixing it.

Now, why would I suggest this instead of the actual software? Well, the actual code that you’re writing, even the libraries and frameworks you use the technology, usually it’s just a matter of figuring out how it works and selecting one and experimenting with it and learning it.

But it’s usually the process, the governance, all that other stuff around it: what I think of as the arrows between the boxes, that was where all your toil and your waste is. And I think you experienced this in your everyday life: try to expense something, try to buy something and you’ll encounter a huge amount of toil, just stuff that doesn’t really contribute to the value of the code that you’re doing.

So that’s something to look at: how long does it take a developer to get something set up? 

Now there’s all sorts of other little things like that, if you click whereever, you can click on things, we are watching this, you can see a webinar that will list how do I identify all sorts of other developer toil and monitor it ongoing to fix it.

Good luck. All right. Do you think that worked?

Working Leftward – Make Sure You Have a Cloud First

When You Build an Awesome App Pipeline that goes Nowhere. If you have nowhere, click here to get a somewhere.

Here is the transcript:

Before you start building your pipeline, your secure software, supply chain, your CI/CD thing, whatever you’re using to frequently deploy your apps to production, you should work backwards from where you’re going to be deploying and make sure one, there actually is a place that you can deploy, instead of assuming that your infrastructure people are just going to set that all up for you and that they’re going to do what you need.

I was talking with someone at a large bank recently, and they had optimized their development process, done really good at putting up their pipeline. And then they found out that the infrastructure people didn’t care and didn’t have a place where they could deploy it.

Now, if you want to be clever, you can think about this as “working leftware.” You know, everyone likes this idea of “shifting left,” or whatever… which you can tell to me has become kind of a cliche at this point.

Or you can think of it as “working backwards,” start with what you have and figure out what you can do with it. Instead of aspiring to have something new and kind of forcing someone to change the way that they’re doing things upstream. 

So remember if you’re building out your pipeline, always start looking at what you actually have rather than dreaming what you would like to have. ‘ Cause otherwise you’re going to ship into a void.

Good luck!

Latest Getting Better at Software Prattle

I frequently give a talk on “what’s the deal with VMware and software development?” Here’s my script/storyboard for one I’m going to give next week.

Sometimes I’m told “don’t make this a vendor talk,” which, as you may recall, dear reader, actually means “don’t be boring.” In this one, I was asked to talk directly to what VMware does for software developers, so you’ll see that.

If you like it, you should come check out the discussion next week, be won’t be just me and I’m looking to forward to learning from my co-talker.

1. Why is application modernization relevant now, what even is it?

  • It’s been almost 12 years since that whole “software is eating the world” notion. We all understand that good software helps organizations run better, perform better, and so forth. To be specific, what I think about here is custom written software, the software that you build and run on your own. It becomes the core way your business runs.
  • There’s not really much dispute about the need to be good at software now.
  • Around 2015 I saw organizations sort of realizing the en mass, us vendors did a good job of spooking them that Google and Tesla were coming from, AirBnB! BOO! This kicked off several years of learning and even building new apps in a new, agile style. You probably remember all the “Labs” that big companies setup and did videos about in three or four years ago.
  • It took a couple years, but people learned the modern, product-mindset way of doing software. What does this mean? It means that your “developers” are working very closely with the actual customers/users of the software to continually discover what features their apps need, even what problems need to be solved. The way this looks is that the team includes not only developers, but also a product manager and often a designer. They’re building a product, not delivering on a set of requirements and wireframes (that’s a project). This means that, hopefully, the team is releasing software weekly, at most monthly. This means that, of course, they deliver smaller batches of code than you would every 12 months. But by studying how people are using their software, they’re getting feedback that allows them to learn and improve that software.
  • So, for example, one insurance company we work with, Liberty Mutual, had their team follow this pattern when they were building their Australian motorcycle insurance business. Their team studied how the sales people were working and sped up the sign-up process, meaning they could sell more. That’s the whole thing: instead of your software just running the business as is, your software becomes the primary way the business innovates and grows.
  • Anyhow, I think what’s happened is that many of the new and easy apps have been done or are being worked on, and now it’s the whole rest of the apps and services that organizations are facing. And what I mean by this, are all the apps that run the existing business and probably are involved in most of the revenue for the organization (or mission/purpose if it’s non-profit oriented, e.g., government). These apps and the services backing them need to be modernized to keep up the “software is eating the world” thing. You see that in surveys a lot where many executives say that tech debt, legacy software – whatever you want to call it – is holding them back from releasing new apps, putting new features in: 76% of executives said they are too invested in legacy applications to change .
  • Put another way, most organizations are now scaling transformation to their entire organization, and this brings them up against older software and older software practices. And, sure, there’s also a lot of organizations who haven’t even started!
  • There’s at least two things that get modernized:
  • First, as the name says, the actual applications, and services they rely on. Older app frameworks, services, and infrastructure usually aren’t up for the task of weekly releases, scaling to the type of usage businesses have, and, sadly, there’s also just a lot of forgotten lore about older apps.
  • Second, the practices, as you can imagine, change a lot. Shifting from developers just implementing what they’re told to and sort of throwing it over the wall to someone else, those developers now share responsibility for the business. That seems bonkers if you’re operating in the traditional way.

2) What VMware is working on here, as a reflection of the modern application “stack.”

  • When it comes to apps, you’re always thinking in terms of “stacks,” like a good hamburger.
  • To support a modern way of doing apps, you need a mostly new stack, and I think there’s three major parts to it: the infrastructure (usually based on cloud and kubernetes, now-a-days), the app platform (not just the programming language and framework, but all of the tools that surround the process of building and running apps), and the practices people follow (put broadly, the “culture”).
  • Handily, we at VMware have just such a stack!
  • This is a simplified illustration of that stack. Frankly, it doesn’t emphasis the third part, practices, as much as I’d like, but whatever (I’ll cover that a bit more later):
  • There’s the “raw infrastructure” at the bottom, either your friendly old VMware stack, public cloud, and sometimes “edge” (which is sort of an up for grabs term at the moment). The key thing here is that most organizations have all of it, or at least want all those types of infrastructure. This is what “multi-cloud” means, you’re not stuck with just one “cloud” or one type of infrastructure.
  • Now, what’s genuinely new in this stack is the middle layer, kubernetes. What kubernetes is doing is standardizing what that raw infrastructure looks like and standardizing how its used, configured, and run. So, instead of having many different ways to configure a server or deploy an application, there’s one (more or less) way of doing it. This is also true when it comes to how those apps are run in production, scale, etc. This removes variation and toil. It makes “multi-cloud” possible and economical, and gives you more options
  • With that standard layer in place, you get a whole new ecosystem of software tools, frameworks, and services that you can pick from. Most of these are all servicing the same basic needs any app has, but they’re fit onto kubernetes. What’s more key here is thinking about this part of the burger/stack as a “platform,” as collection of all the tools, programming frameworks, and services needed to not only run the apps, but build them. So, as you can see here, there’s build tools, for example.
  • From a developers perspective, the goal of this stack is to remove as much toil around managing the platform, coming up with how to do configuration and release management, and even monitoring and troubleshooting apps. You can think of it as making as much as possible self-service. But, also, what you’re doing is trying to give developers templates and guardrails so that they don’t mess up, for example, security.
  • Anyhow, we have a great stack, all the way down, that you can put in place that will get you that modern app dev experience.
  • Now, I mentioned the practices. We have a long history (through the Pivotal acquisition) of crafting a set of agile, product-driven practices that both developers and operations people follow to be “modern.” Here they are:
  • As with the tech burger/stack, any component on its own is kind of cool, but it’s putting them all together and integrating them that actually matters. The next key thing is to actually follow them! I joke about that, but what I’ve found is that most people know these practices, but they don’t actually follow all of them.
  • So far, this can all sound very “developer” oriented, but the way you do operations is equally important and involves a lot of changes.
  • In the same way that you developers take on a product mindset, working more closely with customers/users, operations people treat developers as their customers. You product manage the platform you’re providing, continually discovering what’s needed, experimenting with it, and refining it. This is a huge shift from how most infrastructure people operate.
  • These so called “platform engineers” also think about the supporting tools developers use, build pipelines and services. The reason for this is illustrated well by “DevSecOps.” A lot of what makes DevSecOps what it is is building security into the tools and process that application developers use instead of relying on the developers to follow policy. You see, you’re building “security as a product” for the developers, not imposing it on them. That same type of thinking goes to other parts of the stack.
  • Anyhow, the point is: to support doing apps in a different, better way, you need a new stack of technology, and a new “meat stack,” the way people work.
  • That’s the stack of stuff we have at VMware Tanzu.

3. What inf/VI admin types can do next, should be thinking about if they want to do all this.

  • OK, so now the most important part. You actually need to start doing something. That sounds kind of silly, but I see most people just sort of never getting around to changing. Everyone agrees that there’s new, better ways of doing software, that it needs to happen…and then years go by with not much happening.
  • So, how can you get started?
  • First, I’d spend a little bit of time (but only a little!) tracking down what exactly is in your portfolio. You probably know all the applications and services you have, at least the ones that are important. You need to pick a handful of these to start working on. They should be both technically “easy,” but also “real” to the business, something that is strongly connected to day-to-day operations.
  • You pick these apps, and you set aside around 6 to 10 weeks to modernize them. We have a process we call SWIFT that does this analysis and some tools to automate a lot of the data collection needed. Possible visual:
  • What you’re doing here is, sure, modernizing an actual app, but you’re learning what that means for your organization, what needs to change, what barriers you have, etc.
  • Your developers will learn a lot about a new way of working, and your operations people will quickly identify processes that need to be automated and secured.
  • What you’re doing here is optimizing the entire, end-to-end process of how your business evolves through its software:
  • The shocking thing you find with these little apps at first is that very few people know everything that goes into getting software out the door. I find that the problems are all in the arrows, the spaces between the boxes/chevrons – the hand-offs.
  • Until you start doing actual work, you won’t find all the problems – you can’t do a bunch of up-front analysis, or even PoC’s, you need to do real work – hence selecting those initial apps.
  • And, mostly, it’s the platform engineering team that will do a lot of this fixing and platform building.
  • There are a some things that you can predict and start doing. These are validated, more or less, by the fact that every organization encounters them. The chief one is security and, more broadly, “governance.” Security is going to be a problem instantly, so you should start working on that. This means getting security people on your team, understanding each other’s needs and dreams, and both of you “building” this platform…again, you’re thinking of the “developers” as customers. There’s some reference architectures for securing kubernetes out there, I’ve been liking this one from the US Department of Defense of late because it’s short and thoughtful .
  • Now, product wise, it’s really easy to start messing around with this stuff. If you’re running vSphere now, it’s likely you can just get kubernetes up and running to start looking at that. You can also get our open source kubernetes distro and app dev platform, the Tanzu Community Edition for free at tanzucommunityedition.io. And, more recently, if you’re using Docker Desktop, you can install it from there. And, of course, you can always ask Softcat for help. Getting all this stuff up and running for the initial poking around used to be very tedious, but in the past two years it’s gotten much better.

End/Q&A

  • Well, that’s a lot, probably.
  • Also, we haven’t really talked about the struggles people have: the hard work of improvement is getting over the hurdles to change. That’s a lot of what I get interested in and am always excited to learn about.
  • We have some time to take questions about whatever you’re interested in. And, I’d like to leave with this list of common problems, blockers, etc. people have when they’re modernizing how they do software. Have any of you encountered these? Do you have some experience to share?

Tuesday Links

What is DevSecOps? Part Two: Automating Verification and Guardrails

What is DevSecOps? Part 02: Automating Verification and Guardrails

What is DevSecOps? Here’s part two of what I think it is, actual new tools you can use when it comes to verifying/trusting what’s in your apps and putting out guardrails for developers. Plus, some repaving for you 3 R’s OGs.

Check out my write-up for what the other two are, and more details.

Also, here’s part one.

Here is the transcript:

As you recall, the first part of DevSecOps is a secure software supply chain, which means all the activities that occur to get your software out the door, but also tracking them, verifying that their third-party dependencies, services libraries use come in there and also the arrows in between there, the transitions. 

And this is where, actual new technology comes into play when you’re using things like containers and the way that things like Kubernetes package up and configure, and also can restrict the way that the various components of your applications talk with each other and has a huge amount of control over the way things are deployed, that means you’re given new abilities to, if you like, enforce the security policy that you want, you can establish guardrails that make it difficult for developers and others to change things to make it outside of policy.

This also means that you can automate renewing, or that is, repaving production because containers are very ephemeral you can benefit from being able to blow everything away in production and build back to a good known state. This is something that people like Wells Fargo who’ve been doing for some time, because they have a platform that uses containers in place. 

The next part of this is how do you get developers to actually use this and keep it up to date? And that’s the part that platforms have failed at in the past. And I think it’s because infrastructure, people, operations, people have built platforms to spec, to requirements that they have the enterprise architects and other people wanted at some point, but they didn’t actively product management and evolve that platform.

So what you want to do is think about security like you do your platform security as a product. You want to incorporate having a product manager, paying attention to developers as your customers and figuring out how to make the right thing, the easy thing for them by building in features and really iterating through how you do stuff and focusing on building that platform that secure rather than enforcing and mandating security that people follow.

So that’s a little bit of the second part of what DevSecOps is. If you want to read more, I’ve got a little blog post on the topic and you can also find the other videos about what it is. 

Bye-bye good luck out there. 

We don’t talk about PaaS…but we still want it

You can start to sound too much like an out of touch old person if you start saying things like “oh, we already did that back in my day.” Once people flip your bozo bit, then most anything you say get dismissed. “PaaS” is in this category now: you can’t go around saying that the focus on and conversation about “developer experience” is, like, PaaS. If you’re working on building an integrated stack of frameworks, middleware, tools, and even developer tooling on-top of cloud/kubernetes, you can’t call this PaaS. That’s just how things are right now.

This is not a video about PaaS.
This is not a video about PaaS.

What’s annoying is that we don’t have new terms for these things, so they’re hard to express and talk about. Analysts are sort of coming up with the categories, some have great diagrams. But, because the chattering class (thought leaders) that determine words early on in technology cycles usually can’t get analyst reports, analysts have very little input into the discussion.

Basically, the words and concepts are now defined by Tweets. That’s probably…good?

Why is “PaaS” a forbidden word? I think there are three reasons, more or less in priority:

(1) “Lock-in” and control. A key aspect of a PaaS is that developers don’t need to spend much time on setting up, acquiring, and managing infrastructure. There is much automation and self-service. Every application developer wants to remove this kind of toil and focus on programming their applications. But, my colleague Rick Clark theorizes that there’s a vocal minority of developers that want to build and control that stack on their own. They are the only ones who make noise about the need to control this stack because they have special needs that the PaaS restricts them from and don’t want to get locked into some stack out of their control. I think that minority is mostly wrong, but they’re the only ones doing the talking, so they control the conversation. Once each development team (or cluster of them) believes that they have special needs that an off-the-shelf PaaS doesn’t do (or can’t be modified to do), you get each team building their own stack. This means you get a lot of different stacks in a large organization, which is a mess and counter productive. It’s great for vendors who deploy The Janitor Strategy! I don’t know – valuable lock-in discussions are dependent on the context you’re discussing them, what developers actually need, and a deep understanding of “compared to what?”

(2) Kubernetes. Sure, it’s great that kubernetes (seems to) have become the de facto infrastructure design and runtime lifecycle definition. That is, it’s a standard way to package, configure, and run applications. This is a huge deal that we’ve sort of forgotten already – in that respect, kubernetes has finally become boring! Historically, kubernetes came at a time when the idea PaaS was just figuring out the product/market fit for enterprises. Kubernetes became huge distraction from that: the vocal minority got very interested and that shifted “everyone”‘s interest to standardizing infrastructure instead of standardizing the appdev layer. Again: kubernetes is good! Just bad timing for PaaS developing as an idea and product in the market. This shift in interest spooked all the PaaS vendors who now had to focus on customer requests to do kubernetes stuff, most too late to ride the kubernetes wave of interest. Which lead to:

(3) PaaS vendors didn’t “win.” There have been several rounds of PaaS vendors, including Pivotal where I worked (now part of VMware, where I still work) and several other vendors built on Cloud Foundry. There were and are many successful users of Cloud Foundry PaaSes. But for all sorts of reasons, these PaaSes never achieved wide enough use to “win.” Tyler Jewewll’s annual developer landscape puts the PaaS marketize at $5.26bn, which seems large, but is actually not when compared to the estimate of $49bn for developer all stuff in the landscape. And, you know, AWS made $62.2bn last year. Since I work here, it’s best that I don’t speculate too much. (But, you can see some in the Tweets Matt Asay includes in a recent column, as well as other people’s.) Brian Gracey always has good commentary, listen to his explanation. Despite this notion, there are many large organizations that are running Cloud Foundry with happy developers. Brian also did some good analysis of the PaaS space back in 2015. The burger he came up with is still basically the same for the “we don’t talk about PaaS” stack, except there is only kubernetes at the bottom and it’s not labeled PaaS:

Internal Development Platform, 2015 ed.
Internal Development Platform, 2015 ed.

The three of these add up to PaaS having a bad reputation as a word, which I think is why we don’t talk about PaaS.

There are two phrases that are getting a lot of use:

(1) Developer portal – this is, mostly, a synonym-phrase for Backstage. Here is a Gartner report you can read for free that defines the phrase well. I think it’s good. I don’t know why you’d choose to use the word “portal” in 2022. Below is Gartner’s diagram for a developer portal from that report. You can see that it has most everything except the actual runtime. Developer portals are being conceived of as a, I don’t know, sort of overlay for kubernetes – the tools you use to build and do all the SDLC (see below) activity for apps you end up running on kubernetes. Here’s a recent write from my co-worker JT and me on the topic.

Everything except Kubernetes
Everything except Kubernetes

(2) Internal Development Platform (IDP?) – pretty much a PaaS. In fact, there’s a Tweet on the front page of a definitional that says soThat site, by the way, is a great try at doing some gorilla thought-leadership, almost at the Heroku’s 12factor.net level. We’ll see!

So, you know, whatever, let’s get some new words!

As I said, you end up sounding like those old people who are all like “we’ve always been doing agile/DevOps/SRE/DevSecOps, we just never called it that.”

Bonus:

Other old phrases that are forbidden to use and also lack new words:

  • “Middleware” – we end up saying “services” (as above) which is too broad.
  • “Application Life Cycle Management” (ALM) and “Software Development LifeCycle” (SDLC) – these mean “all the project management and tools developers use that does not involve actual coding.” The phrase “developer portal” is set to take over here. I hope not: “portal” is just sort of…ugh.

How far down does this mountain go?

To get to a higher mountain, you have to first climb down the mountain you’re on. So a profound thought-technology goes.

But, to make that profoundizing real, how you think through accepting a job that pays less?

This climbing down has been an “opportunity” many times in my career, and sometimes paid off (like working at RedMonk), and sometimes not (I’m sure switching to 451 Research was a good climb down, so much as a quick punch-out).

But, at some point it’s possible that you’re overpaid, over-valued – not unlike all the software companies that have had their valuation slashed in the past few months.

Moving out of metaphor, though, how do you think about that for yourself, for moving between jobs? Placing your bets on stock options and future IPOs is sort of cheating once you realize how much of a crapshoot that is, and, how much of a young-person’s life. I have, as a friend once called it who wanted to me to work with them for less pay, “expensive hobbies”: a mortgage, three kids…a life that requires cashflow, not net worth (valuation) growth.

Anyhow, what’s y’all’s thinking on that?

 What is DevSecOps? Part One: A Secure Software Supply Chain

What is DevSecOps? Part One: A Secure Software Supply Chain

I’ve been trying to figure out what exactly the Sec in DevSecOps is for a couple years or so, and I think I’ve got something. Three things in fact. Keep in mind that DevSecOps isn’t all of security, it’s just a small subset that focuses on the software you write and run.

Anyhow, here’s the first.

A “secure software supply chain.” That’s a fancy word for trusting and validating the code goes into your apps, the builds. This is code your write, other services you use, and nowadays external services you might rely on. Not only that, but the tools that you and your developers use to put together the apps. Source control, collaboration, and project management tools: everything is a target!

To figure out what to do here, chart out every single activity that happens from idea to coding to a person using that feature. What are you doing to secure each step? And pay close attention to the arrows in between the boxes, that’s where a lot gets hidden.

Once you’ve verified this, you’ll need to document it and make sure it obeys the policies you have in place. Most all organizations have their own security policy and also external policy, such as laws and regulations, they need to follow. You’ve got to document it!

There’s more to it, or course. To read what I think DevSecOps, check out my write-up, and look for the other two tiny videos on DevSecOps, here’s the second one.

Here is the transcript:

I’ve been trying to figure out exactly what DevSecOps is for a couple of years now, and I think maybe I’ve got a good idea of it. There’s three parts to it. 

Secure Software Supply Chain

The first one is a secure software supply chain. Now this is just a fancy word for saying that you trust the entire process of your software being built. This can go all the way back to specifying what it looks like. Definitely writing the code and compiling it, verifying the third-party libraries, you use don’t have any problems in them and fit to the policy that you have, but also looking at the configuration and the deployment things that you have. 

Now, what’s important to pay attention to here, I think, are what I like to think of as the arrows between the boxes and this is where the idea of a secure software supply chain is something different than what we traditionally do.

And that says that you look at this entire chain, the activities, the boxes that are occurring, but then also the handoffs between them. When you move, for example, the code you’ve built the finished application over to testing, and then you move it from testing over to production and knowing that nothing changes outside of what you want to and that means that you still trust and have verified this code as it moves through that supply chain. 

Third-party Dependencies

Now, this also means that the third-party libraries that you depend on you verified and trusted and are compliant with your policy.

Your Tools

The other important part to think about, and again, you have this wider view of everything every activity that it takes to build your code is to think about and check on and verify and trust the tools that you’re using, whether it’s version control , even project management tools, the registries that you’re pulling third-party components from, but you need to also look at that part of your supply chain and ensure that you trust it. 

Also, this means that you need to be able to trust third party services that you use – services that you might use in the public cloud or wherever else.

General Idea

The idea of a secure software supply chain is that security problems can happen anywhere in the life of the application, not just when the application is running and even not only when you’re using third-party libraries or if your developers have put bugs in there that are security problems, but the whole process of creating the tools around using it, how it’s configured and deployed. The scope that you’re looking at with DevSecOps is all of that supply chain.

Read More

There’s more, of course, including the other two things. To check it out look at a write-up that I did recently on DevSecOps, which you can click on wherever the clicking might be, or you can go to TanzuTalk.com/videos to read that write up. 

Good luck.

How to write better copy for the while “digital transformation” urgency, “change or die” thing

I love the narrative arc of saying that a problem technology was once the darling technology that saved the day. But, now that previous hero-technology has become the problem child.

This isn’t the tech’s fault, it just was allowed to wilt by vendors and users – it could also have been customized so much that it’s now unchangeable (e.g., many ERP and help desk systems).

There is a lot of empathy to have for “legacy” technologies!
When you want to say that the technology most people currently use is old, crufty, and unhelpful…and so they need to urgently get some new technology, you only need to make this point once and not spend too much time on the back-story.

Once you’ve spent 2 to 4 sentences being all like “you’re held back by your legacy stuff!”, what’s more valuable is talking about (1) what the desired, new, better end-state is, and, most valuable (2) how to get from here to there.
Your reader will know and be convinced that they need to change – otherwise, they won’t be reading your text/pitch. They are most hungry to know how.

Originally in my newsletter.

Saturday Links, May 28, 2022

I’m in Istanbul to give a talk tomorrow at Java Days Istanbul, the kubernetes for developers one. Here’s some catching up I did on the plane: heavy on the platform engineering.

  • Kubernetes security survey – “According to Red Hat’s State of Kubernetes security for 2022 report [PDF], the majority of 300 DevOps, engineering, and security professionals survey respondents (55 per cent) said they had to delay the debut of an application in the past 12 months because of security concerns. Fully 93 per cent of respondents reported at least one security incident in their Kubernetes environment in the past 12 months, with 31 per cent saying this led to revenue or customer loss.”

The Toby Ferris Worldview

Perhaps that is what these paintings are: the slow-decaying trace of a performance carried out in the mid-sixteenth century: the ghostly flicker of Bruegel’s hand dancing six inches above the panel we now look at. No code, no message, no useful information. Just a mysterious relic of a life lived in some other place, some other time.

Short Life in a Strange World: Birth to Death in 42 Panels by Toby Ferris

What to make of Toby Ferris? Rather, what he writes. Is he perpetually trying to figure things out, or just always pulling things together, almost reflectively. He says little about his own life, that he calls his family (wife and two kids!) back home, stories from his childhood. They all seem detached, dreamy. It’s his main narration that’s dreamy, some strange world just slightly detached from everyday life. Just like Bruegel.

He cares about projects, doing things: he points out (complains?) that his father did nothing momentous, and then Ferris spends lots of time on his two big projects, Norbiton and the Bruegel book.

How does he think about my eternal question: what is life apart from those projects, from work? How do you balance the “thrill” of work, the routine of everyday life, the missed chances to work on things like Short Life and Norbiton? Does “the failed life” mean failing at doing anything “big,” or failing at a normal life? Failing at the first allows for time, energy, attention for the second. And failing at the second buys space for the first. Can you only choose one?

——
In contrast, here is Tyler Cowen on his motivation:

I think I’m on a quest to assemble and gather information, and satisfy my own curiosity and see as much of the world as possible and also try to give some of that back to others. So I think it’s somewhat of a selfish missions, has some altruistic byproducts but I enjoy the really selfish part of it of just learning things.

As that write-up of the Cowen world view says: “The world is rich and full of wonder. Always keep exploring and pushing your curiosity into new areas.”

Perhaps this is the opposite of the “failed life”…?

How to do fun and interesting executive dinners, round tables, etc. – online and in-person

Here’s what I’ve learned in doing 30 (maybe more like 40?) executive events in person and online over the past four or so years. Over my career, I’ve done these on and off, but it’s become a core part of my job since moving to EMEA to support Pivotal and now VMware Tanzu with executives.

At these events, I learn a lot about “digital transformation,” you know, how people at large organizations are changing how they build software. But, below are some notes on what I’ve learned about doing the events themselves.

The events

These usually get together a of 8 to 12 people who’re up “upper management” and involved in changing organization structure, practices, and “culture” to get their groups better at software. They’re usually very large companies: banks/insurance, manufacture/pharma, government, etc.

We used to host dinners, in person to meet these people and tell them about Pivotal, now VMware Tanzu. These dinners were eight to about twelve people. You have pre-dinner drinks and hanging out, sit at a table and eat a meal (fish, meat, or chicken – usually very good from a luxury hotel kitchen), discuss “digital transformation” during dinner, and then have drinks on the bar with about four or five of the attendees who stay.

This doesn’t work when you’re in lock-down for two years now. So, we shifted to doing these events online. I’ve been the primary anchor – the entertainment, as it were – for something most of these in Europe that are in English.

When we started, we didn’t know if they were going to work or how and had to figure it out along the way. Now, we’ve got a good formula and here are some things that work:

  1. First, the format, or “run of show”: fun chit-chat as people join the meeting, an introductions round, the novel event, a short presentation to establish the topic and provoke some questions, open discussion, and then a thanks and tiny vendor pitch at the end.
  2. Do an introductory round at the start. Each person gives their name, title/role, what they’re working on, and most important what they’re looking to get out of the event. This is good for both parties (vendor and attendee) to get to know each other, and their interests good. It also comes into play in moderating the discussion at the end. For discussion in the group, this part is really handy because it lets everyone know what people will be interested in talking about.
  3. Have a “novel event,” a fun activity some kind that often involves something you’ve sent the attendees. For most of these, we’ve had a sommelier do wine tasting. We ship three little bottles of wine to each attendee and the sommelier walks through each wine for about 30 or forty minutes. The one we work with is fantastic, telling the history of the wine and the region it’s from more than the mechanics of drinking. We’ve also had beer tasting, and in the States they’ve done bourbon tasting. For Christmas we did gingerbread tasting. I once ran a Nutella tasting. A nice dinner is the “event” of an in-person round-table, and you need a hook for these online ones.
  4. Alcohol is a good ice-breaker and the best event to have. I don’t know what to tell you: it works and people appreciate getting free wine. The wine is good, but the stories and conversation around the wine get people’s in a sort of learning/thinking mode.
  5. For online events, have a PowerPoint. I use that word instead of presentation because it evokes the most cringe. For in-person events, interrupting a sit-down dinner with someone going up and presenting slides is practically taboo, and certainly weird. It just makes things too commercial and introduced a formal tone that messed up the conversation. But, online, things are very different. We ended up coming up with a 10 or 15 minute presentation that basically describes what good software development looks like with a few customer examples: “product, not project” to use one framing. I found that doing this is much less about discussing exact technologies (or “vendor pitching”), and more about level-setting what we’re going to be talking about, introducing topics and problems to discuss. It’s important to have at least one story that illustrates this point. The mechanic of this presentation is to say “this is what we’re talking about, here’s a language for it, and here is one example we can refer to.” Without a shared vocabulary and some anchors, you’ll end up spending all of your discussion time on definitions. This defines “the what,” the end goal that attendees are shooting for. Most people are struggling with “the how” of getting there. So, at the end I put up a list of common hurdles and problems. This is what drives the third part:
  6. Moderated open discussion about people’s challenges and successes in changing their organization (transforming). I end my little presentation with a list of about ~15 common hurdles. Then I ask people to share their stories, things that have worked, that they struggle with. Sometimes getting people to start talking is like pulling teeth. I’ve had to specifically call people out before. But, often there’s at least one person who will start with a story, e.g., “you listed finance as a problem. I agree, we are struggling with getting finance onboard with shorter development cycles and being open to changing plans.” At that point, people start talking, often even giving advice to each other. I love this part!
  7. After the first few comments, this is where I’ve forced myself to do actual conversation moderation. I say forced because, if you know me, you’d be shocked that I would be doing this – I don’t like talking with groups. I’ve learned to figure out the people who are talkers, the ones who are reluctant to talk, and to balance out the two. This requires two things: predicting a topic that someone could comment on and abruptly changing the topic of conversation, often by calling on someone new to talk. Predicting what people can talk about is usually drawn from the introductions, or past comments they’ve made in the chat. You don’t want two or three people to dominate the conversation, which is a common risk. So you have to draw people in. To do this, you can ask them directly to follow up, or you can just change the topic of conversation all the sudden and have them kick it off: “Those were some interesting comments on dealing with finance. Now, I’m interested in how you’re dealing with legacy systems. In the introductions, it sounded like the bank Alexandra works with had a lot of legacy systems: Alexandra, how have you been dealing with that?”
  8. At the end, you wrap up by saying “let me tell you a little bit about what we actually do and how you can engage with us more.” If you keep this to five minutes and thank everyone for showing up, it’ll be fine and not too “don’t do a vendor-pitchy.”
  9. In person events are slightly different. There is no presentation. Instead I have to sort of wing it and rather than being methodical and laying it all out (a presentation!), I just talk about what it means and looks like to do software better: the practices, an example story, what new tools make all this possible, and a few common hurdles. This generally works to get people to the open discussion, which is the goal of these get togethers. I’ve gotten a little rusty at this as all the events have been online for the past two years, but after a couple so far, I’m starting to remember how to do this.
  10. For in person events, I think it’s handy to have about 30 minutes of hanging out before things start, and even an event or some type. Most recently, we did a Formula One simulation game. An event is always fun and relaxes people, but all of this time also allows me to meet people and find out what they’re interested in. It’s totally workable (and not weird) to ask people what they work on and what they want to get out of this event. People will just tell you – and happily! And then you can start up conversations with them that you later draw on.
  11. Again, the goals of all of this is for people to get to know one another and learn from each other. You can do a surprising amount of that in 90 to 120 minutes. I think this is because people are genuinely interested and engaged/learning and because my co-hosts and I have learned how to moderate and drive conversations.
  12. Sometimes, instead of my short presentation, we’re lucky enough that to get one or two customers to speak. These are great, I usually I ask a few questions and sometimes the customer does a short presentation. We’ve had people from Audi, Rabobank, Daimler, Tesco Bank, Cerner, and other places. When you do this, you of course need to spend time with the person up front: not so much on content (you should let them talk about whatever they want however they want), but more just get friendly with them to set the tone of the meeting. And, of course, it’s a chance to meet and learn from someone new! Having a customer talk is always preferable, but rare to be lucky enough to get.

Behind the scenes

I don’t do much or the behind the scenes work for these, and it’s a lot of work. I’ve been very fortunate to have the support, belief, and, really, my ongoing nurturing/training from my co-workers who actually run all of this. My friend Hinada Neiron has done a lot of that work and she’s done a great job putting up with me and making sure I don’t slack.

Here’s the behind the scenes stuff that happens:

  1. Finding and recruiting the attendees. I’m not too sure how this happens as we work with an agency that helps us. They’re great at it. Also, sales people and inside sales people also try to recruit people. I haven’t done much work here: I think I got two people to show up. The problem here is that you’re trying to meet new people, so you need to find them.
  2. The agency also reminds people to show up and will call them if they haven’t shown up yet (like, on the phone!). This actually works well and brings in people who wouldn’t have made it otherwise.
  3. We spend a lot of time on the landing page/description of the event. At first, I thought this was too much, but I’ve come to realize that it needs to be near perfect because people you’re inviting don’t know us too well or what we do, so we need to get their attention and interest.
  4. It’s important to make notes and plan followup right after the last person leaves. It’s then equally important to talk directly with whoever it going to follow-up with customers. The goal of these events, on the vendor side, is meeting new people to start working with, so you have to push your people to do that.
  5. I send a thank you to all the attendees on LinkedIn, asking to connect with them. And, we of course send a thank you email.
  6. Ongoing, I think it’s good to discuss with the team what’s working and not working, to come up with new things to try, and always be trying to make things slightly different. You don’t want to get stuck doing the same thing every time, otherwise you won’t find new things that work even better. Also, it just gets boring if you’re not experimenting a little here and there.

My own transformation

Overall, these events are great. As you can probably tell by some of my comments above, it’s not natural for me to talk with groups of strangers, or even individuals. I go out of my way to avoid it on my life – I love self-checkout!

So, I was very worried about that at first, but with encouragement, just doing it over and over, and also experimenting with what works and doesn’t work, I’ve gotten over it.

Most of all, I’ve made sure I enjoy these events by talking about things I’m interested in and asking people whatever questions I’m curious about. You could call this “listening,” which I suppose it is. Several years ago when I was talking about this nervousness with my wife, she reminded me that I love talking about tech stuff, and learning about it…and that’s exactly what we talk about at these events! Once I realized that these were the kinds of conversations I wished I could have all the time and people I wanted to meet, it was easier to transform myself a little bit.

Anyhow, they’re good events, and I enjoy them. Hopefully I’ll see you at one of them!

(Speaking of, the next one we have is in person is in London on June 22nd, 2022. There’s more coming up as well, I’ll post them to my LinkedIn and Twitter as they open up. I don’t host all of them, but we generally have them during our SpringOne Tour dates too, most soon in Toronto and New York City.)

Trendz! Internal Developer Portals

Here’s a write-up from myself and JT of a new trend in the kubernetes/DevOps/app dev world: developer portals.

With people building out the appdev layer on kubernetes (or “DevX”), many organizations are looking at how they support all the tools and internal community for developers. What’s interesting, and new, about projects like Backstage (now in the CNCF, so pretty closely tied to “we’re running our apps in kubernetes” strategies) is that backstage is looking to add tools right along side the usual “knowledge base” and project management stuff you get for internal dev portals, sites, “Confluence” stuff.

Anyhow, check out this article that JT and I wrote covering whet a developer portal is and why it will make your org. run better. Also, we’ve licensed a Gartner report on the topic which you can read for free: it’ll go into a lot more details.

Warm Smiles – a Fictional Case Study in Digital Transformation

I’m back to working on the ongoing book(let) project, The Legacy Trap. Marc has been adding in the real meat of the project, how the methodologies VMware Tanzu Labs uses for planning and doing application modernization, like Swift. Here’s a corny example story I wrote for the introduction, linking together business needs with worrying about legacy software.

Let’s look at a theoretical example of that business problem in insurance. Let’s say The Mid-Eastern Warm Smiles Insurance Company wants to grow revenue. They’ve done a great job over the past 140 years insuring houses, cars, and grew revenue in the early 2000’s by acquiring a point-of-sale warranty business. 

Business has slumped now, and the share price is boring. A management consulting company compiled a large report that suggested three pillars for improving shareholder value. One of them was to enter new types of insurance. Playing off the synergies of that warranty business, the consultants suggested entering short-term insurance: coverage that would last for 24 hours or less. For example, a customer might go to the beach for the day and want to insure their new, $1,300 iPhone against damage and theft. The likelihood that anything will happen (especially if they have newer models that are water and sound resistant) is low, so collecting the $50 for that one day of insurance is almost like “free money” to the insurance company. Now, imagine if that happens thousands, hundreds of thousands of times a day, globally. 

After some business and actuary work, the CIO is given a new set of applications to create. First, the application for the insurance, next the actuary back-end for approving insurance, then the account management for these policies. Seems simple enough: it’s software! You can just add a feature!

A situation like this is where the legacy trap is often sprung. Developing the actual web app for an application is often easy, but integrating with the existing backend services is often near impossible. In the case of Warm Smiles, the backend systems that maintain policies only support annual policy terms. That will need to be updated. Payments must be done through bank ACH or physical checks (here, the CIO thinks, “well, it did always seem weird that customers had to fill out a PDF to pay their policies”). These payments can take up to 10 business days to clear. Warm Smiles will need to modify their payment processing system. And what if someone actually losses their iPhone and wants to file a claim? Usually, claims processing takes 5 business days and requires an adjuster visit…but we’re just talking about an iPhone here. Our CIO friend also keeps hearing the mobile team say something about “batch jobs” and something called an “enterprise service bus.” Those need to be updated as well.

And so on, and so on. Meanwhile, Warm Smiles rival, Southeastern Friendly Pats on the Back Assurance Group, has launched their own short-term insurance business and has seen a 3% rise in share price.

This is a made up example, but this kind of situation repeats itself over and over in large organizations. Warm Smiles is squarely in the legacy trap. Their software portfolio does not support the business fitness and agility needed. At some point, the portfolio was great – the company has saturated its market and survived for 140 years. But, slowly and then all of the sudden, their portfolio became “legacy” and urgently needed to be modernized.

Originally from my newsletter.

Creating new appdev capabilities

I like this point from a recent write-up of the US Army’s software development transformation:

He added that the technology being developed is often secondary. “A lot of times, people get really caught up on what type of software you’re developing, and we look at it as the software that we’re developing is the intermediate step,” he said. Instead, the desired result is having a slew of technology-savvy professionals or “autonomous product teams that we can send out across the Army and hand to a commander without them knowing what they’ll be potentially working on.”

There are, indeed, some interesting apps they’ve been working on. And I obsess over apps because I want to hear the stories of how they were created. But, the bigger task going on is just building up software development skills, a new capability that’s ready to use when needed for whatever. Just like regular military training, I suppose.

The idea of a battlefield programmer has come up a lot recently. That’s a new capability they’re trying to create.

This group at the US Army is a great source for learning how large (like really large!) organizations get better at software. What they do – the practices – are good, but how they’re getting there (and how they’re changing their minds/culture) is always more interesting.

Here’s some more notes from the article:

  • Started in January 2021. “In the past year, 55 soldiers and civilians from those two cohorts went to work on agile software teams that focus on different modernization priorities. The software factory has produced eight applications and averages 99 days from development to production for soldier use.”
  • “Then participants swap uniforms and last names for civilian clothes and calling one another by their first names as they embark on a six-month technology accelerator”
  • “participants are assigned to tracks that include product management, user interface/user experience design, application engineering and platform engineering.”
  • ‘the cohort starts practicing extreme programming and paired programming, an intensive learning model in which individuals sit “shoulder to shoulder all day for 40 hours a week” to learn from industry professionals’

If you really want to dive into this software factory stuff, check out this talk from them from last Fall.

Things that help companies get better at software

When we standardized and enforced controls in the CI/CD pipeline the quality improved dramatically. Everyone knew the standards they were held to.

“Global Bank”

Here is an April 2020 McKinsey report that tries to show a relationship between being good at software and making money. I don’t know math enough to judge these kinds of models (as with the DevOps reports too), but, sure!

Here’s their relative ranking of how various developer tools and practices help: