This is an example of a weird use of “developers are the new kingmakers”:

There is a simple rule: developers rule. You run the global economy, right? Not politicians, not CEOs - developers are the ones running this global economy. What aspect of your life is not getting more digital? Everything, sports, entertainment, social experience or health, everything is becoming more digital. It’s a foundational aspect of all economy and human experience. We’re just seeing everything become a computer, replacing industries like oil that defined geopolitics for five decades. It’s now silicon and the technology supply chains that it enables.

Here, you have a computer hardware (chips) company saying that developers are the kingmakers and, I guess, the continual power-source of the kings. I didn’t watch the keynote, I’m just taking the idea in that text and commenting on it. Maybe Intel is on about something else. But I want to look at this idea of “developers as kingmakers,” apart from whatever is going on at Intel.

A Runaway Idea

I’ve recently been uncomfortable with how much people latch onto the idea of developers as king-makers. This is despite having worked at the firm, RedMonk, that was the main source of that idea back in the 2000s. Stephen’s book has several case studies of developers playing huge roles in technologies “winning.” If you work in any business that works with developers, then: YES!

BUT. For what feels like over a decade, the importance of developers has started to get way overblown and misused to over simplify, like, how things actually work.

Related to the above quote, let’s look at the hardware case. This is an area I have first hand experience with from when I did corporate strategy at Dell, covering software and cloud. Dell was super interested in the importance of developers. I did many, many reports, slides, big meetings, and studies about developers. Dell is still very interested in developer! They’ve obviously funded it an incredible amount more than when I was there.

Hardware without software is useless

Here is where it starts with a hardware company: Hardware without software is useless, it just sits there.

So, someone - more likely, some software company - has to write and provide/sell software to run on that hardware.

How is software made? Well, people program it. These people are…developers. But they’re not the only ones involved.

Yes, and, there are also product managers; testers; platform engineers/DevOps engineers, and ops/infrastructure people who either run it or run the labs and equipment that everyone uses; designers; general managers of business units that trickle down strategy from the corporate layer; the corporate layer that is making all sorts of choices about which technology to use and not use (see Adobe, Apple, and Facebook examples below); then there’s legal and regulatory requirements.

Also, now-a-days, you have to do a lot to manage culture and overall worker happiness. If you read through the past several years of developer productivity metric studies, you’ll realize that management’s ongoing “programming” of corporate culture is a critical part of the success of software as well.

On the buyer/user side: there are the people who select which software to buy; the people who procure it; the people who install and integrate it; the people who administer it ongoing; and then the business side at the buyers who determine how it’s used and for how long. Also, all sorts of cost/benefit analysis that’s done: is it worth while to upgrade our old stuff, or, like, do anything new?

With respect to hardware, there are strategic decisions like running on your own hardware (private cloud, edge), or in public cloud. There’s also just people who decide they like AMD versus Intel versus whatever. You have security people who will decide which hardware and software to get based on the reputation of the vendors - real and perceived. You have computer makers and hyper-scalers (Dell, Apple, Facebook), who are building hardware and deciding which chips and other things go in there, or just licensing(?) ARM and making their own. Maybe they don’t like Intel’s pricing, so for two years they’ll go with AMD just to stick it to Intel. Maybe they choose Nvidia because, like, it’s the best technology. Perhaps there’s licensing and patent barriers that force people into choices.

(I don’t think there’s much choice in storage - they’re all pretty much the same right, a commodity. I’m pretty sure developers don’t king-make hard drives? Sure, they gave SSD an early boost, but, like, SSD is just better, regardless of who’s deciding to buy it. You could argue that for the SSD market to exist, you needed the early developer market to buy the expensive SSDs before there was enough scale to build more and lower the prices…but…really? I don’t have the numbers for this, but I feel like if you took some contemporary estimates of the developer population, reduced it to those who could decide to buy SSDs, and figured out the spend, it’d be pretty small.)

Then there’s also marketing, especially brand marketing, lower level marketing - the people who put together giant keynotes and events. You’ve got the people who write documentation, manuals, training, staff StackExchange, and garden not only developer communities, but also the communities for all roles above.

You have people who manage channels and partners (at Apple, someone has to manage the relationship with all those phone stores and carriers to get favorable deals and make it all possible - if you could only buy iPhones directly from Apple…how would that have worked out? And see the partner/channel hijinks in RIA below!).

And so. And so forth.

Are the needs of developers taken into account for all of this? Sure. The hardware has to work with the software. Your developers need to understand it, sometimes even like it all. If the organization wants to use Kubernetes, your hardware needs to work well with Kubernetes and container-based architectures. These can be make or break considerations.

But so are all the other considerations and roles above. Often, developers have to fit their skills, desires, and work into the constraints that this whole system drives. It’s certainly not the case that there’s some kind of “great developer of history” theory of IT.

Developers are required, but so are all the other people, roles, and strategic considerations above.

Sure, you can have “indie” developers that collapse all these roles into one or two skin-bound entities, but all of those non-developer functions need to happen.

And, further-sure, if you’re talking about products and services that you sell to developers, then developers have a key, often king-making role…just as any customer for a product or service does.

There are many technologies that have won - or lost - because of non-developers.

This must especially be true lower down the stack, that is, with hardware. I feel like decisions about which software to support, the amount of brand management, marketing, design of the hardware, pricing, and getting your supply chain right have much more influence over the success of hardware companies than developers.

In other words, you should make good hardware that is sold at a reasonable price that solves the problem the buyer has. (I should put that in an airport business book!)

The Story of Flash

Here is a case that I lived through: Rich Internet Applications. In the 2000s, using HTML (web pages) for the kinds of applications we use now was magic. When GMail came out, few had ever seen an application that worked in the browser. It was hard to make rich, GUI-like applications for the web.

Meanwhile, browser plugins had been getting around this problem by not using HTML. Cheif among them was Flash, from Macromedia, acquired by Adobe. As Flash evolved past delivering delightful cartoons with limited user interaction, it allowed you to have desktop like applications (GUIs) in the browser. I’ve used many of them, especially enterprise software systems.

People - users - didn’t always like them, but then some people did like them (and some people nowadays have nostalgia eyes for them). As ever with software, it wasn’t the technology (Flash), it was how well you did the screens, “UX,” whatever. I

n the mid-2000s, there was a long-game/war between major software vendors to win the emerging smart phone market, which, actually meant winning the new PC platform. Microsoft wanted a version of Windows on smart phones. Adobe wanted a version of Flash on there. Sun wanted Java on there. There was also Blackberry! Winning the smart phone market was incredibly important because…well…look at the value of Apple today!

Apple shocked everyone (Well, I think? Me at least) when Apple launched the iPhone. Adobe tried to get Apple interested in Flash. They developed a whole other framework called Air that was, like, Flash++ (that might have been after Apple’s rejection of Flash, I forget). They made partnerships with other phone manufactures, streaming services (I think Netflix streaming used Flash originally, for a long time, right?), and so forth. But, at some point, Steve Jobs wrote a memo where he was, in summary, all like “Flash sucks.”

And that was it for Adobe! Did a bunch of developers petition Steve Jobs to do that? I don’t know the history, but I’m guessing not. I’m guessing Apple: (1) strategically was all “why would we let someone else own part of our fully vertical stack, are you insane?”, and, (2) it always seemed like there was a super-weird relationship between the two.

Also, people argued that Flash was just not good enough for the task. It was technically inadequate You could say “developers decided that,” but they would have decided that because it was the bad option. Imagine the case where, instead, developers chose Flash even though it was the worse option. They would have king-made Flash, but made the wrong choice. We wouldn’t be celebrating that.

Oh, and also: maybe it was just licensing. Maybe Apple and the hand-set carriers didn’t want to pay Adobe to include Flash in their stack. Flash could have been awesome - developers could have been clamoring for it! - but if the handset providers (with respect to Adobe, in strategy terms, the partners/channels) refused to pay Adobe and shipped something else. Well. Then you have Android (right?). As mentioned above, for Apple, it was an obvious strategic choice to make their own platform, regardless of what developers wanted.

Adobe tried to find traction for Flash and AIR for many more years, but eventually it just sort of died off.

Here is a sort-of contrast the Flash story. Meanwhile! Facebook was trying to figure out how to do mobile apps. At one point Mark Zuckerberg got really into HMTL5 as their app framework. The idea was that you should use the open web for apps. Strategically, this is similar to Apple rejecting Flash: using the open web meant Facebook had very little ties and dependencies to any company. This is, you know, very different than how Facebook and the entire web acts now - a closed off web with the gates made of network effects and user preference.

(You can also see, in recent, history why it’s was bad for Facebook to have dependencies on Apple. Apple changed how tracking for advertising was done a year or so back and this caused all sorts of problems for Facebook and others who’d been using those capabilities to track and target ads. I think Facebook figured it out, but, like, bummer on their cashflow!)

Eventually, Facebook was like, nope, we’re making native iPhone and Android apps. They still have HTML ones as well.

Here, you can see some developers contributing to this, but like, a handful of developers at Facebook, probably - not, you know, the millions of developers out there in the world. Also, I’m pretty sure it was a strategic choice.

Yeah, but…

First, I could be missing a major point in the smart phone cases above. Once Apple put its own app platform in place, it needed developers to actually write apps for it. And, like: yes! But, let’s go back to that laundry list of what goes into making software. Apple needed the software producing industry to make apps that ran on the iPhone…not just developers.

The container wars are another thing I don’t have sorted out in this “developers are just part of it all” thinking. Developers can play a large role in the success of technology. I’ve seen this first hand recently with the rise of Docker and then Kubernetes. But…to me, this is something more of a perception and business strategy “war.”

The actual usage of containers in production is incredibly low compared to how much we talk about “cloud native” and Kubernetes.

By 2025, 15% of enterprise applications will run in a container environment, up from 5% in 2022, hampered by application backlog, technical debt, skills availability and cultural change.

–From a recent “Gartner Forecast Analysis: Container Management (Software and Cloud Services), Worldwide.”

Also, the market (how much money people pay for) for container management is incredibly low as well. And then there’s the bizarre thing that the Kubernetes people keep saying that Kubernetes is not for developers: you know, platform for building platforms and all that.

I don’t have this whole container wars thing figured out, but I suspect there’s a lot more going on then just developer preference.

The cost of Kubernetes (free to download and install the hard-way); the brand-glow of Google (and then Red Hat jumping in and acting as a kingmaker and channel for it); the missteps of competitors (usually understandable with out reverse Halo Effect vision, just like Adobe and Facebook above); the price of alternatives (Pivotal Cloud Foundry is/was expensive compared to free - OpenStack sort of lost the plot); Docker’s strategy waffling and flameout; HashiCorp somehow not getting a foothold in platforms despite its foothold in other areas; and then all the existing VM-based “platforms” from the public cloud vendors to VMware (where I work), Microsoft, etc.

Also, there’s endless castle intrigue and rumors about people doing plain old bickering, acting on grudges, and all that petty bullshit that drives history. I wasn’t first hand to any of that, so I have no idea - but I’d love to know!

Again, we see an incredibly complex system where the part of one role - developers - is important, but not any less important than other roles?

(Oh, and then, how about OpenStack as a case from the other direction: what made that not work out? Further, was it the developers in telco that made and continue to make OpenStack successful in telco? Or maybe OpenStack is just fine?)

Perhaps you could say that developers can be one of the early gate-keepers of a technology. They can decide if the technology gets past the early parts of the diffusion of innovations curve. But, whether early on or along the curve (especially the fat part in the middle), so does every other role in the big system.

Pricing and procurement can be a king-maker: if the software is expensive and hard to buy, you’ll have problems…well, not exactly…you could hire an enterprise salesforce and sales engineers that can support this long process, do the marketing and product management needed to justify a high price, and then increase the prices to support the whole mostly self-inflicted hassle of enterprise sales. That all works perfectly in the ERP: witness Oracle, Salesforce, SAP, etc.

(Another side case that’d be fun to ponder. When I was at RedMonk, SAP cared a great deal about developers. Did all that effort matter? Was it make-or-break for SAP’s continued success? SAP was also heavily aligned with Adobe’s RIA stuff above.)

It takes a lot more than cheese to make cheese enchiladas

To say that “developers rule” is like saying that the cheese makers rule with when it comes to cheese enchiladas, or even queso. The cheese is important, but the decision process and hands-on work that leads up to putting a chip in queso is so complex, involves so many people, and, most importantly, user/eater preferences, that to say the cheese maker rules is weird. Maybe the proper mixture of spices, getting a ripe avocado, deciding on putting chilli con carne or not (and is it ground beef or brisket?) - I like a lot of pico de gallo myself. But, then, procurement wise, sometimes you don’t have the time and money so you just melt some Velveda and you’re perfectly satisfied - connivence is the king maker. (Is the developer the queso eater here, or the maker? I’ve lot track.)

Similarly, there are so many things, people, decisions, tricks of fate, grudges (I’ve heard!), etc. involved in making, buying, and using software that to assign an outsized amount of importance to developers is…weird.

Many of the people and roles involved in the lifecycle of process can have a pivotal role in it, developers can for sure! But people making strategic choices also can have make or break control (Steve Jobs and Mark Zuckerberg above, or the strategic choices they make at Concur to not update their software which are, I assume based on their software’s UX, very much in favor of controlling costs and driving profit since they have mental lock-in in their market - from what I can tell).

A designer who comes up with the best way to do a workflow for a user can have make or break effect - they could use “dark patterns” to drive revenue that keeps the company alive, allowing the developers, and everyone else, to keep doing their job. Someone in billing could just decide that you have to call (on the phone!) to cancel your subscription.

Despite all that, it’s still a big, important idea

At the time, the point Stephan was making was incredibly important because most people didn’t think about developers as having much of any role. Sure, there was the mythical idea of a garage of app developers, but from what I recall, caring about developers wasn’t a big enough part of the conversation.

It was weird. You had that whole “developers! developers! developers!” thing. And Linux and the broader open source world was driven by developers (as cataloged by Stephan).

But, still, the idea of thinking about developers strategically was only done by a select few, like Microsoft. Now, most everyone considers the developer. And this is fantastic! YES TO THAT. We do, after all, need software.

I just think, you know, let’s focus on all the parts, not overly on one, developers.

So, going back to the original quote a the top, I think what he means is “software.” Software is, like, pretty important now-a-days.

And, sure, developers program software, but there are so many other factors and roles involved in the life-cycle of software that also play a critical role (see above!) that, you know, developers, just like the cheese maker, are only one part of making a good bowl of queso.

Speaking of developers…

Next week, on October 17th, a whole passel of my team mates and I are hosting an online SpringOne Tour. It’s free to attend, of course. If you can’t make it to one of our in-person events, check this one out. There’s over 20 talks you can choose from, including mine on platforms.

If you’re a programmer - especially a Java programmer - or doing anything with cloud native apps, there’s something in it for you. Register for free, and check it out on October 17th.

Logoff

I got access to the ChatGPT conversation feature this weekend. It is pretty amazing, really. I’ve used it for my D&D messing around, and a little for other things: I’m thinking through a method of collaborative storytelling that could make it a better ChatDM. And, with the conversation thing, you could do it while walking the dog, washing the dishes, etc. I still don’t think it could do D&D combat, but I might be able to finally figure out how to get it to be fun.

How to survive giving a lot of presentations at conferences

I think it was John Willis who told me that a long time ago.

Relative to your interests

• What is Technical Debt? - “In practice, my observations are that most development teams, even in small companies, are too far separated from these types of financial models to reason about technical debt in terms of revenue, but absolutely do feel the pain of technical debt in their day-to-day work (even if they can’t quantify it in money).”

• Six Months Ago NPR Left Twitter. The Effects Have Been Negligible - “Six months later, we can see that the effects of leaving Twitter have been negligible. A memo circulated to NPR staff says traffic has dropped by only a single percentage point as a result of leaving Twitter, now officially renamed X, though traffic from the platform was small already and accounted for just under two percent of traffic before the posting stopped.” // I haven’t done a deep analysis, but I feel like I’ve seen the same thing with my stuff.

• Call it a bro-celet. It’s a male bracelet and once you see it, you’ll see it everywhere - And here I thought these were some kind of meditation, Buddhist token…

Next week, on October 17th, a whole passel of my team mates and I are hosting an online SpringOne Tour. It’s free to attend, of course. If you can’t make it to one of our in-person events, check this one out. There’s over 20 talks you can choose from, including mine on platforms.

If you’re a programmer - especially a Java programmer - or doing anything with cloud native apps, there’s something in it for you. Register for free, and check it out on October 17th.

Wastebook

• “revealed management practices”

• Software implements strategy for breakfast.

• “She leans 5’8”."

• Understand what you’re measuring, or you’ll just get measurements.

• “Going to count the minutes that the trains run late”

• An acceptable level of awful.

• “Nothing gets done, however, unless there are people responsible and held accountable for the measurable improvement. This is another area in which strategic plans sometimes fail.” Here.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Oct 17th SpringOne Tour Online (free!), speaking. Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!). Nov 15th DeveloperWeek Enterprise, speaking.

Discount code for KubeCon US - while I won’t be at KubeCon US this year, my work has a discount code you can use to get 20% off your tickets. The code is: KCNA23VMWEO20.

Logoff

I did a quick practice of some new slides as a livestream today. If you want to see the actual talk, check out the webinar Bryan and I are giving on Tuesday: free to watch!

Meanwhile:

bushwald

A post shared by @bushwald

Suggested outro.

No links today, but this:

Measuring Developer Productivity

Once you suggest tracking an individual software developer’s performance, you get into big trouble with the thought leaders. This is, you know, pretty much a correct a response. McKinsey decided to have a go recently, giving us all a chance to think about “developer productivity” again. In recent years, I’ve mostly thought about developer productivity in terms of build and deploy automation - I know, just mind-blowing thrill rides, right! That’s cloud native for you! - but this new round has been more higher up the stack. Though, come to think of it, I don’t know if that scope was actually specified.

Anyhow, I think these are what’s on the current stone tablets of developer metrics:

1. You should measure the developer team, not the individual developer.

2. Management should only measure business outcomes, not development activities.

3. Metrics will be gamed by developers and misused by management, likely, with bad results for the business.

I’m sure this is, as Dan North likes to put it, “reductionist,”1 but, sure…?

Homework

For this week’s podcast recording (it’ll be here once published this Friday), I went back and read the McKinsey piece on developer productivity.

It seems…fine?

Like, so much so that I was wondering if the McKinsey people went back and edited after the big stink-up about it.

With that confusion in my brain, I re-read three things three times:

• The original McKinsey piece.

• Gergely Orosz and Kent Beck’s two part rebuttal (part one, part two).

• Dan North’s review notes on the McKinsey piece.

I think I get what the rebutters are so upset. Let’s see!

McKinsey’s Four New Metrics

The authors at McKinsey are looking for a way to measure developer productivity that the, like, “C-Suite” (“management,” as I’ll put it) can use to make decisions about software development in their organization. A good goal!

They start with using DORA and SPACE, and adding in four new metrics:

The new metrics are the - what would call that? - purplish-blue ones2 - from the article (I just included the quick definitions:

1. Developer Velocity Index benchmark. The Developer Velocity Index (DVI) is a survey that measures an enterprise’s technology, working practices, and organizational enablement and benchmarks them against peers.

2. Contribution analysis. Assessing contributions by individuals to a team’s backlog (starting with data from backlog management tools such as Jira, and normalizing data using a proprietary algorithm to account for nuances) can help surface trends that inhibit the optimization of that team’s capacity.

3. Talent capability score. Based on industry standard capability maps, this score is a summary of the individual knowledge, skills, and abilities of a specific organization.

4. Inner/outer loop time spent. To identify specific areas for improvement, it’s helpful to think of the activities involved in software development as being arranged in two loops. An inner loop comprises activities directly related to creating the product: coding, building, and unit testing. An outer loop comprises other tasks developers must do to push their code to production: integration, integration testing, releasing, and deployment.

For the forth, I think what they should have meant was “developer toil,” but that inner loop/outer loop framing is so tempting.

Don’t Measure Individuals, Management Will Misuse Metrics

The reaction to this was not good. Here’s my summary of the sentiment based on the two rebuttals I read:

1. You should measure the developer team, not the individual developer.

2. Management should only measure business outcomes, not development activities.

3. Metrics will be gamed by developers and misused by management, likely, with bad results for the business.

Let’s look at each!

1. These business outcomes should measure the team, not the individual

This one is the foundation of the counter-arguments. Software development done well is very much a “team sport.” You know, there’s no “I” in “team” and all that.

It may be hard to detect from the outside, but software is not just the aggregate of individuals writing code. It’s like this: I don’t know what to tell you if you don’t just know that - you must not have ever been a developer and experienced it first hand?

For our metrics discussion, the consequence of this is that it’s very difficult to measure an individual’s contribution to the team.3 Rather…it’s a nuanced task. If you do allow people to specialize in certain parts of the code base and/or be “hero” trouble shooters then, like, it is easy to identify who’s important and valuable. Structuring the work so that it is individual based generally causes problems. Generally, allowing people to specialize like this is highly frowned upon.

Dan North brings up a more qualatative way to judge indivcidual performance:

If you are going to assess individuals in a team, then use peer feedback to understand who the real contributors are. I ask questions like “Who do you most want to be in this team, and why?”, or “What advice would you give to X to help them to grow?”, or “What do you want to most learn from Y?” An astute manager will quickly see patterns and trends in this peer feedback, both positive and negative, which are then actionable.

In this method, you are still rating individuals, just on how they help the team and their peer’s assessment of their skills. This feels right. If you’ve been on an application development team, I mean, you know that some individuals contribute more (“are more valuable” if you can stomach that phrasing) than others. You know who’s slacking off. You know who’s padding their estimates. You know who’s stopped learning. You know the bad performers, and the good ones. As a peer, you can also see through the “they’re not a failure, system has failed them” thinking. You know this because you’ll have tried to help them many times. You’ll have tried to change the system such that you can many times. They’ve taken advantage of the five free therapy sessions, and all that stuff. (Why just five? Does any HR department think that, like, any mental issues that are dampening my productivity can be solved in five therapy sessions? You’re going to need at least one just to introduce yourself and set context. Then you’re down to four hours. And, if you’ve been to therapy, you know you spend, like, half the time just meandering about as you and the therapist try to find something to talk about and how to talk about it. And then, even if you solve your problems in those four sessions, you need frequent reinforcement of the tactics you deployed to fit is. Five sessions is better than zero sessions, but if you’re concerned about the mental well-being of your staff damaging productivity, they’re going to need more. Which, I guess, you can, like, get from good health insurance if they provide it. Anyhow. Uh. I was talking about how peers in an application development team will know if someone is a low performer and can’t be helped further, good system or bad system…) And, like, you’re doing your job despite all the things…what’s their deal?

So, if anything, when it comes to individual performance metrics, base it on their peers. And, definitely, absolutely, don’t let management ever see those metrics, as we’ll cover below.

2. Management should only measure business outcomes, not development activities

As with a sales person, management should really just care about the business outcomes that application development teams produce.

“Business outcomes” are things like revenue (sales), cost savings, keeping the application up and running (performance, loosely put), and, though not really considered by the business much, overall application agility (how quickly and easily can you add new features or modify existing ones to change/help how the business runs). There’s always lots of other business outcomes, but you get the idea.

The McKinsey piece adds four metrics (above) that are based on the daily activities of individuals, and, worse from the perspective of the thought lords, there’s one that’s some kind of skills assessment. I didn’t seek out the definitions of these four new metrics much, so maybe they have tons of business value and team laced into them. I mean: they could!

To be fair, the McKinsey piece is not suggesting that these are the only metrics to track. They throw in DORA and SPACE into their overall metrics rating. Yay lots of metrics! Fill the dashboard!

Here’s all the metrics again. The new McKinsey ones are the “opportunity-focused metrics” ones:

There’s only a few “business outcome” metrics in there: customer satisfaction, reliability, lead time for changes, etc. Notably, none of the metrics are “made money for the enterprise,” or the like for non-profit/government organizations.

This is, really, the whole problem with “developer metrics.” All you really need to track is “did this software help the business?” That is, “business outcomes,” a phrase only just a little better than “business value.”

Gergely provides an example of how his team at Uber tracked the team’s business outcomes, which is awesome! The problem is that most organizations don’t track to these business outcomes, and I suspect it’s because (a) they just think of application developers as a factory4 that delivers apps to spec (you know, “waterfall”), and, (b) it’s hard to do.

If you can track the business outcomes of application development teams, that’s the only metric you need to track. Even if the team has “low performers,” who cares if the money’s good?

And, sure: measuring the business outcome of the team is what you should be doing. So, like, do that. It’s very difficult in most organizations, and not even considered a serious idea in not-tech organizations, as Gergely pointed out last year.

Even more wicked here, when you measure developer activities, figuring out the right activities to measure is difficult. So many things that a team (let alone an indivdual) does in development are unseen and un-trackable, as Dan North points out:

most of programming is not typing code. Most of programming is learning the business domain; understanding the problem; assessing possible solutions; validating assumptions through feedback and experimentation; identifying, assessing and meeting cross-functional needs such as compliance, security, availability, resilience, accessibility, usability, which can render a product anything from annoying to illegal; ensuring consistency at scale; anticipating likely vectors of change without over-engineering; assessing and choosing suitable technologies; identifying and leveraging pre-existing solutions, whether internally or from third parties. I am only scratching the surface here.

This is another one of those things that you only appreciate, and believe, if you’ve been a developer.

3. Metrics will be gamed by developers and misused by management, likely, with bad results for the business.

Given all of that - you should measure the business outcomes of the teams, you should measure the team not the individual - bad things will happen if you track individual performance. First, people will game the system and max out the activity based tracking. As the rebutters point out, if you value commits/PRs, developers will just make a bunch of tiny commits. And so on.

I find this gaming thing only half of the counter-argument. There’s whatever named notion that once someone knows how they’re measured, they’ll game the system. The second part that’s left off is that, yeah, sure, if management is dumb. We all know that metrics will be gamed, so you try to redesign the metrics ongoing and use them skeptically. There’s a spiral into cat-and-mouse games here, I guess.

Kent Beck points out an example at Facebook where that didn’t work out - and I think the outcome was they stopped doing it? Hopefully. On the other hands: that’s probably the least of Facebook’s problems, if they, really, even have any problems based on the shit-tons of cash they generate. Still. One should strive to be excellent, not just well paid. (At least, that’s what we should tell our management chain.)

But, like, does this mean we shouldn’t use the DORA metrics because people will “game” them? No, it just means use good metrics and adapt. Use metrics to get smarter about your qualitative (a fancy word for, I guess, “subjective,” rather, “your gut feel”) assessments.

This brings up the second part, here: you can’t trust management to use these metrics well…unless they understand how software is actually done. Gergely and Kent give a good, simple overview of exactly that.

So, the worry with the McKinsey metrics is that management will use them without understanding how application development is actually done. This means they’ll misuse them, either to fire people, not promote them, misallocate budget (giving too much to some teams and not enough to others), etc….all because someone didn’t break up their PRs/commits into small enough chunks. Hahahah - jokes! (But not too far off.)

What’d be better

As the rebutters all point out, what’d really be useful is to get management to understand how application development is done (above). With that understanding, you’d realize the above flaws and come up with some better metrics…or indicators and health checks.

The DORA metrics are trying to predict business outcomes without actually knowing the business outcomes (revenue, etc.). They’re saying “if you do well at these four metrics, then it’s possible for the business to do a good job…so…hopefully they do that.” Hey, hey! SILOS. Local optimization! FAT BOY SCOUT! But, you know, that’s probably fine.5

So, I think it goes like this:

1. If you could tie the application development teams work to actual business outcomes, then you’re all set. And if you can’t, you should figure that out.

2. Else, if you can’t do that, you should use the DORA metrics to measure your own local optimization.

3. Else, if you can’t do that, you should only rate individuals based on their peer reviews.

4. And, if you can’t do that, you’re working in an unenlightened, possible even toxic work environment.

5. And, if you can’t get a new job (or are adept at working in that system and maximizing your take with reasonable long-term stability), whatever you do, if you have the data on individual performance, first, destroy it and stop tracking it, and, second, do not let management outside of development see it.

And, if you have no idea what’s going on, must keep your commits small and your lines of code voluminous and you’ll probably be fine.

Next week, on October 17th, a whole passel of my team mates and I are hosting an online SpringOne Tour. It’s free to attend, of course. If you can’t make it to one of our in-person events, check this one out. There’s over 20 talks you can choose from, including mine on platforms.

If you’re a programmer - especially a Java programmer - or doing anything with cloud native apps, there’s something in it for you. Register for free, and check it out on October 17th.

Inner Loop/Outer Loop

In his write-up about developer productivityDan North has a discussion about the inner loop/outer loop model. Here’s McKinsey’s diagram:

As he points out, it seems to be in conflict with the “shift left” mindset. Without typing too much about it: yes?

In our cloud, DevOps, cloud native world, I don’t think we’ve every figure out a good answer to the question “what are things application developers should be doing?” These would be things the application developers should be automating, or letting other people do.

Unless you’re dhh, your application developers should not be racking and stacking servers. They probably shouldn’t be writing their own container management systems, nor working with kubernetes directly instead of layering a buffet of CNCF landscape on-top of it. They should probably not being creating your security risk models? If you’re of the Heroku/Cloud Foundry mindset, they shouldn’t be deploying their applications to production.

I’m blowing up the scope of inner loop/outer loop, sure. But defining what application developer “toil” is versus is not is both very clear (building clouds) and not very clear (doing compliance audits - not a great example?).

All models are flawed, just some better flawed than others. For the McKinsey piece, if you just replaced the inner loop/outer loop talk with “toil,” I think you’d be cool. And, of course, you’d need a footnote that said “one application developer’s toil is another application developer’s competitive advantage.” '

What we want to get at is something more like: there’s some stuff that’s a waste of time for application developers to do, and they should not do those things.

For example, Dan North points out that your path to production and infrastructure stuff (“A fast, automated release pipeline is a key prerequisite for frequent releases, and skill in defining, provisioning and evolving the infrastructure to support this is a differentiator”) is incredibly valuable.

Like, big yes (my monthly paycheck depends on that infrastructure being incredibly valuable!): but that’s probably the work of a team other than your application developers. That seems to be the case at the tech company darlings that have separate developer tools and platform groups.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Oct 17th SpringOne Tour Online (free!), speaking. Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!). Nov 15th DeveloperWeek Enterprise, speaking.

Discount code for KubeCon US - while I won’t be at KubeCon US this year, my work has a discount code you can use to get 20% off your tickets. The code is: KCNA23VMWEO20.

Management Misalignment

Related to developer productivity, charts/surveys that silo handoff problems are always fun. Here’s one from Cat Hicks and crew:

1. Schedule (“timeline”) is always a problem and misalignment. But, schedule is a problem in all walks of life. It’s not only developers that are bad at time estimates, it’s everyone.

2. Budget and cost is not shown (maybe “lack of technology resources” is a proxy?): management always wants to pay less (more for the shareholder and, thus, themselves). Again, as in life, so in business: "I'm glad I paid more than I had to," said no one ever.

3. Getting the requirements right is difficult, but a lean design approach can help: the business should take part in this and use the agile advantages of software. If you do software right, you can experiment and develop how the business functions: you don't have to get it right the first time. E.g., the commercial kitchen pivoting to measuring mayonnaise. This idea of "pivoting" is key and needs to go up to the business. It's a pun, right: Pivotal Software.

This last point is getting us closer to the business output dream. The enlightened stage of understanding how software is done comes when you get that you don’t have to be perfect each release. And, in fact, that is not good. If you’re not getting your “requirements” wrong frequently, you’re not trying hard enough to come up with new things and improve existing one.

I don’t know sportsball, but my understanding is that they don’t get the ball in the goal every single time they try. And this is considered a-OK, just fine. The hockey puck quipper also said: "you miss 100% of the shots you don't take." So, what if I told you with you software you could take, virtually, unlimited shots? Yeah. SOFTWARE.

Wastebook

• “Might-could be fixin’ be real peachy-like.”

• Sometimes you don’t squeeze to get the juice.

• “You know me: I don’t wear velcro shoes.”

Logoff

Per above, I have the second installment of the the path to production talk series coming up next week. There’s something scurrying around in this developer productivity talk that gets real close to what I want to discuss: what does it mean to think of and use your software “factory”6 strategically?

If we know the wrong metrics to monitor, and we know the right ones, that should be some kind of trailing(?) indicator of how to correctly think about software. We’ll see! Also, we were going to cover some OGSM thinking, which I’ve looked at many times and am always left bemused and puzzled.7

Also, yet again, as ever, ThoughtWorks has written the definitive piece on all of this before us Pivotal/Tanzu people can get around to typing it up. No, really, it’s great stuff.

You should register for it and watch it - all for free, you know.

Finally, a rare Garbage Chair of Amsterdam, Duivendrecht edition:

🎶 Suggested mid-week outro.

Just a few things today.

The Network is the Computer

Kubernetes Distro Usage

If you’re interested in marketshare, usage trends, and benefits/problems in Kubernetes-land, Torsten and crew at EMA has a new stack of analysis and charts about Kubernetes out. It’s a packed 84 pages that tries to get it’s hands around the Kubernetes world through many, many different methods: surveys, analyzing GitHub, and even things like finding as many detectable Kubernetes clusters on the public Internet as possible.

Here’s one slide estimating the Kubernetes services/distros in use:

Check out the rest, for free thanks to my work, VMware.

Wastebook

• “Q: Female artists still have to sometimes use urinals backstage, because clubs weren’t built with women stars in mind. Joan Jett: Oh, I get very friendly with cups. I mean, [expletive] a urinal. That’s not clean. I’m just in my dressing room, with a cup. Quick, easy, you don’t have to go anywhere. Try it next time! Solo cup. Check that Solo cup before you drink. [Laughs]” Here.

• “Stuffing the prompt.”

• “Good morning, would you like a breakfast calzone?” On the DTW->AMS flight. (I said, “no, thank you.”)

• “Reverse sales.”

• “a group of vicious squirrels”

Relevant to your interests

• The Musk Algorithm - “Question every requirement. Each should come with the name of the person who made it. You should never accept that a requirement came from a department, such as from “the legal department” or “the safety department.” You need to know the name of the real person who made that requirement. Then you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb.”

• Keep track of time in “metric time.” And, more explanation from Mike Olson. I saw him present (announce, I guess) this at Monktoberfest. Fun!

• Measuring Developer Productivity: Who’s Winning the Debate? - more from this weird nerd-fight about developer productivity metrics.

• How Dell Claims Apex Smooths out ‘Ground-to-Cloud’ Azure HCI Connections - Dell has a private Azure box.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Log Off

There’s now 700 of you subscribing - thrilling for me, of course!

If you like this newsletter, it’d be cool if you recommended it. I mean, come on, everyone who creates something like this wants as many people looking at it as possible. We all care about the numbers. And, thanks, for bringing some dashboard joy into my life.

Suggested theme song.

Just links and fun finds today.

Relevant to your interests

• VMware named a Leader in the 2023 Gartner Magic Quadrant - Nice spot for VMware in the MQ. // This is a pretty small market! Hopefully the market is selling around container management, the stacks of app dev support above it, and filling in all the Kubernetes gaps. I mean, that’s usually exactly how the infrastructure market works. // “The container management market has seen accelerated growth of 28.6% over the past year with a market value of $1.6 billion in 2022. The market is forecast to exceed $3.6 billion in constant currency by 2027, with an 18% CAGR.” And: “The business and technical benefits associated with container deployments are still mostly centered around enabling enterprise business agility and speed. Recently, more enterprises have commenced container deployments while seeking cost savings and defense against vendor lock-in. Both of these goals are attractive, but difficult to achieve with container deployments. In many cases, container deployments increase costs as enterprises add additional staff and technology assets. And although most solutions are Kubernetes-based, vendors add other components that make the entire technology stack proprietary, which often prevents portability, thus enforcing lock-in.” Also, some thinking on multi-cloud and apps best suited for Kubernetes.

• Work From Home Works - The man gets more productivity per buck from wfh: “So, we were shocked to find a massive 13 percent increase in productivity…. The productivity boost came from two sources. First, remote employees worked 9 percent more in minutes per day. They were rarely late to work, spent less time gossiping and chatting with colleagues, and took shorter lunch breaks and fewer sick days. Remote employees also had 4 percent more output per minute. They told us it’s quieter at home. The office was so noisy many of them struggled to concentrate.”

• Accenture’s full year generative AI revenues come in at $300 million out of a $64.1 billion total. There’s a long way to go, says CEO Julie Sweet - Assuming that at least half, or even more are, like, actual AI projects and just ones that involve AI stuff as a tool, this is still a lot of money for a year-ish old, mostly not enterprise-governance ready tech category: “Accenture says that its generative AI sales have doubled in the last quarter, adding $200 million in revenue to bring the total for the 2023 fiscal year to $300 million. Total full year revenues across Accenture came in at $64.1 billion.” And, they say it is, like, actual AI projects: “When we give you gen AI numbers, we’re being very clear it’s pure gen AI, so we’re not sort of talking about data and all of those things. So the real gen AI projects right now are still in that sort of million dollar-ish on average range. And we expect that’s going to continue for a while, right? That’s what we’re seeing because there’s a lot of experimentation.”

• An AI-assisted cloud? It’s a thing now, and here are six ways it’s already made my cloud experience better.

• The potential gap - People don’t use all the features in your enterprise tools, and that’s weird and probably self-defeating: “Which is kinda weird! If we pushed these tools to their limits, they could probably solve a lot of stubbornly persistent problems. Instead, it’s as though we’re hungry, go into a buffet, and never bother to walk past the appetizer station. We keep complaining about how we haven’t had enough to eat; new entrepreneurs keep creating new buffets that reconfigure the stations; we keep only eating what’s by the door, and declaring the restaurant insufficient.”

Path to Production Talk Series

My colleague Bryan Ross and I are doing a series of three talks on, you know, doing software better. They’re spread out over October, and if you’re reading this, you’ll like them - right? You can watch live or catch-up on the recording, just register already!

I have a new theory on all this “digital transformation” advice and chattering that I get involved in: you should actually do it now. When you look at the rates of people using CI/CD tools and survey reports about deployment cycles, it’s pretty bad after, like, 20 years. So, you know, if you’re not doing the basics of automating your full “value stream” (CI/CD), stop listening to us thought-leaders yammer on for six to twelve months and just go do that widely in your organization.

So much of what we’re all talking about is just that. So much so, that we often don’t even stop to ask: wait, do you have CI/CD in place already?

Our first talk is that topic. Register to see it for free next week, on October 10th. You can watch the recording, of course, once it’s out.

Wastebook

• “Whatever works is fine.”

• I ate some P.F. Chang’s orange chicken first thing here in the Detroit airport. There is no American Chinese food in Amsterdam - that I can find. That chicken is now a solid bag of concrete in my belly. It was delicious. NO REGERTS.

• “Doubling down on parallel SSH.”

• “It’s supposed to be ‘how to be nice,’ and it ends up being ‘how other people can be nice to me.’” Here.

• Woke up 4am, 4:30am Uber to Schiphol. First through passport line, in airport at 5:10am! (Woke up too early.)

• “Premium poultry concepts.” Seen on semi-truck somewhere between Brussels and Amsterdam.

• What if I prepared just for the work I needed to do, instead of also inventing and worrying about all the phantom work I make up?

• Giving the presentation gets easier, often fun, and sometimes even cathartic. The waiting to give it never does.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Monktoberfest, Portland, ME. Oct 9th Spring Tour Amsterdam Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

I’m at the Monktober fest today and tomorrow. Portland is foggy:

Software Defined Talk #434

That’s the opening topic of our podcast this week. Oh, and we talk about a bunch of tech shit too:

Watch the video above, or just listen to the audio only, edited podcast.

Do Less

My colleague Bryan Ross has been writing up some tiny videos I made last year. They’re fun for me to read: he adds a lot of depth to what were, basically, just snarky asides in my head that I turned into 60 second videos. His latest is out, and you should read it!

In recent research, consultancy firm Deloitte reported that 70 percent of digital transformations fail. That’s a shocking number, for sure, but if you’ve been through enterprise-scale modernization efforts, you’re likely not that surprised. In this article, we’ll look at how you can build a robust business case for your change initiative by starting with realistic expectations, ensuring stakeholders are fully engaged, and structuring your delivery plan to maximize value.

Take a gander.

Wastebook

• “I’m shocked - shocked! - that stock buy backs are going on in this establishment! Ah, thank you, I see that my 401(k) has gone up in value.”

• Ever hopeful, I still put lettuce on my children’s sandwiches.

• Questionable stamppot joke in PowerPoint.

• I didn’t have money for a gift, so I just got you all of these screenshots.

• “it’s pretty boring to watch someone yell at a toilet about how bad they are at being a toilet” Here.

• “A danger sign that fellow-obsessionals will at once recognize is the tendency to regard the happiest moments of your life as those that occur when someone who has an appointment to see you is prevented from coming.” - Peter Medawar, Memoirs of a Thinking Radish, cited here.

• “You don’t have to like everything.” Yes, and as the Mann says of things that you don’t like or understand, well, “this is not for you.” Robert.

• 01: For your next three presentations, force yourself to not use slide titles. It won’t work for all slides - you won’t be able to resist the urge to use a title. You’ll be scared and doubtful. That’s fine, put a title on those slides. But, start each slide without a title, and try very hard to not add one. You should have at least half with no titles at the end. What do you notice? What do you feel? Now, present it.

• 02: I refuse to believe that any color other than black should be used for the text in presentations.

• 03: “What are you talking about? Sure, I used your conference presentation template. It’s just that I know how to edit the master slides.”

• No matter what I’m listening to, even if I don’t realize it, I’m really just hoping the next song that comes up in the playlist is something by Stevie Nicks.

• I vaguely remember how this joke goes: A: Is next Tuesday at 7am Eastern a good time to meet? B: checks schedule No, sorry, I’m booked then. A: When’s the next good time? B: checks schedule the next good time is…never.

Relative to your interests

• A Close Look at the Ray-Ban - If they work well, and I could my prescription lenses in them, I would totally buy these. The first generation for horrible reviews, though, so we’ll see how this one does. Here’s more details, and it looks like you can get prescription lenses: we’ll see if it’s easy to figure out in Europe.

• The radical idea that people aren’t stupid - Some triple-turns-out’ing here, all making a good point. // “correspondence bias, the tendency to attribute other people’s actions to their personalities rather than to their situations. You see a dude get angry and assume he’s an angry dude, rather than he’s having a bad day.”

• macOS 14 Sonoma: The Ars Technica review - I just don’t get widgets - in general, since the beginning of time.

• When it comes to creative thinking, it’s clear that AI systems mean business - The theory is that AI can generate more “ideas” more cheaply than human white collar workers. I feel like they’re likely just as good: just because a human comes up with a business idea doesn’t mean is good! This either means devaluing the humans (paying them less or firing them), or the alternate upside (which doesn’t always happen, of course): you do more of that thing. Imagine management consulting engagements done monthly, if not weekly. In the beat cases, this is what happens with software development automation and speeding up: you don’t keep doing the same amount of work and, thus, need less developers (pay them less or fire them), you get your existing developers to do more work! The downside for developers is that they rarely get paid a lot more: that value (extra money from selling more or driving down costs) is paid out to the executives and the shareholders. Workers of the world, demand your slice of EV!

• The Screens are the Symptom. - There’s a lot more going on in that book than just book burning.

• Software Delivery Enablement, Not Developer Productivity - This seems right. // ‘“Business leadership is always measuring revenue and pipeline, but that isn’t making its way to the engineering teams, or it’s not being translated in a way that they can understand,” she said. “They’re always chasing their tails about revenue, about pipeline, about partnerships [and] about investment, but it really should be a full conversation amongst the entirety of business, with engineering as a huge consideration for who that audience should be.”’ // That said, it requires a whole new set of instrumentation and a strong connection between software and the business. Us vendors know this because the developers are creating the product sold: more revenue from the product, the team is doing good. This kind of linking is harder in regular enterprises. But, I suspect that’s because no one has tried to do it, at least enough.

• Should You Care About Developer Productivity? - Things to focus on to make developer’s work better. Also, the old focus on outcomes no activities angle. // File under: the only people who don’t like metrics are the people being measured.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Oct 3rd Enterprise DevOps Techcon, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Oct 9th Spring Tour Amsterdam Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

I'm considering pitching a new talk called "What's not platform engineering - AMIRIGHTWOOWOOHIGHFIVESPEWPEW."

Any takers?

I’m pretty sure I got all the slides and stuff done for my nutty week next week. Check back on Wednesday when I have a four hour layover in Detroit on the way to Monktoberfest.

The last time I was in Detroit, at the start of this month, this scene unfolded:

There’s a couple sitting across from me in the lounge, middle-aged. The wife is a bit tipsy and is trying SO HARD to get her husband to engage in fun banter with her.

She’s complained that they should be playing more Motown here in Detroit. She’s mentioned that about five times. Then she was like “do you realize we’re the ones who’ve been together the most of everyone we know?” And while he had asked her how many drinks she’s had a few times, he went to the bar and got her a glass of red wine.

Then this story:

Husband: That was Joe’s strategy: just drink two gin and tonics and pass out on the plane.

Wife: He needed to train more if it was just two!

Husband: …I found out later he owned a plantation in Kentucky. A tobacco plantation.

Wife: Oh, so he killed people.

Husband: Wait. What? He didn’t make them smoke.

Wife: Yeah. He supplied them…and killed them.

Husband: You’re ruining the vibe of this story.

After a long silence, a pause, she came back around, saying “I CAN’T believe they’re not playing Motown!”

And singing some to herself swaying her shoulders around.

I’ll report on anything that good that comes up.

Suggested outro.

Thought Leadership Hidden in Plain Sight

There’s a variation of The Plumber’s Problem that I suffer from: The Tech Marketer’s Problem.

When I see a new idea in tech bubbling up and I can smell the marketing strategy behind it (which, with my background, I usually can), I stop enjoying the, you know, story.

This becomes an anti-pattern when the idea and technology is actually good, and I grow suspicious and dismissive once I’ve smelled marketing and thought lording/ladying/theming.

Such as…

Recent examples are: Adam Jacob’s post-DevOps thought-lording (to promote how his new company does this), platform engineering (to promote Humanitec, and now all of us), and Steve Yegge on git sucking (he works at a version control company now).

In each of these cases, there are good ideas and technologies wrapped up in the marketing. DevOps did kind of drop the ball (so let’s wake it up and keep going). Now that we’re calling it “platform engineering,” the old idea of platform as a product seems to be catching on (thanks, Berlin!). And tightly integrating your dev, systems management, and infrastructure tools and stacks together can result in incredible dev and ops productivity (if can afford it).

But, with my jaundiced eyes, I have to spend a lot of effort to see past the marketing around all those great ideas.

Indeed, the best marketing is marketing a good product…but that is useless tactical advice (see most any marketing lessons learned from Apple). It’s the marketing advise equivalent of self-help and financial planning thought-leadering where the first step is “first, become a millionaire in your 20s.”

Beneficial Uses

The Tech Marketer’s Problem can be very beneficial early on in a technologies life before it has proven itself out. You can see this with Kubernetes.

Early on, even though there was a lot of interest in it, it was very, well, early. It was in the innovators and then early adopters section of the innovation curve. These are not phases of a technology that, like, a bank should get involved in…or really, any “normal” organization.

Seems like it’s fine now. (Hopefully for my bank!)

Sneak Attack on the Incumbents

However! There is a double turns out trap here: if you couple the over-hyping of a technology in the innovators and early adopters phase with an application of The Innovator’s Dilemma, you have the chance for lethal competitive surge.

Compared to the alternatives 5+ years ago, Kubernetes was under-powered and lacked a viable enterprise ecosystem. But, it was cheap!

In the developer (and DevOps-y) world, cheap means not just “low cost to free,” but it also means low friction to get started. Kubernetes was - and is - both of those. People ran around demo’ing installing Kubernetes in a 45 minute conference talk and deploying an app to it and scaling it.

All of the Day Two Operations counter-marketing in the world didn’t defuse that Day One thrill. Enterprise software is all about Day Two, where-as marketing new technologies like this is all about Day One benefits. This is a cunning use of The Innovator’s Dilemma crossed with some good marketing maneuvering.

(Docker was a better example of this: the Day One “mean time to adrenaline,” as people joked it, is quick when you start using Docker to deploy apps on your laptop. That is: trying it out is “cheap.” But, try to deploy those laptops to production in Day Two - hmmm…)

Avoiding The Tech Marketer’s Problem

I advise this:

1. If you are a marketer (or an executive at a tech company, or a enterprise sales rep battle worn CIO-type), be aware of this effect and catch yourself if you just automatically assume that anything in a press release or keynote talk is bullshit.

2. If you are part of a marketing strategy like this, very quickly go over your biases (or whatever), and focus on describing how real the technology is. “Hey, listen, I stand to benefit from the following idea because I work for a company doing it. But, just hear me out first as I explain the new idea…”

3. This has the added effect of nullifying your competitors hidden-marketing strategies: now the audience will be aware of the stealth-marketing technique and be wary of it.

And, look: I work in marketing. It’s like, my thing. I do all of this myself for a living. I do not think this stuff is bad or nefarious. A hammer can be used to build a house or smash a house.

Once you’re aware of a marketing tactic/effect like this, it’s just like anything else in the intricate enterprise software web of life.

Wastebook

• “The audience either really likes GitHub or Fireside Metrics are broken.” That’s what podcast metric analysis is like.

• “As it is free with Prime, I guess we will continue to have it.” Not the most thrilling product recommendation, but accurate.

• “Slides Benedict,” from Brandon. The post Mary Meeker Master!

• “If you can’t be happy with a coffee, you won’t be happy with a yacht.” Naval Ravikant, from here.

• “The world doesn’t need more of what it’s got.” Here.

• I’m considering replying to every email I get from procurement with “is this a joke? This must be a joke. This is not a very good joke” because, like, what are they even talking about? However, it’s always from an email address called do_not_reply@whatever, so, ok, but: I don’t think that’s how email works?

iPad Mini Update

The iPad mini continues to be good. I’m re-discovering/using Notes. As long-time readers/listeners know, I switch around my notes apps every 6 to 9 months. Notes and Bear have been in the rotation for a year or two. I like GoodNotes, but their recent version just bugs out too much with the pen - it used to be perfect! Notes is so close! I have two hang-ups:

1. It doesn’t use plain text files or markdown, and,

2. I can’t set custom background - I have scan of an old piece of graph paper that I really like using in GoodNotes.

But, Bear doesn’t do most of those either. Exporting from Notes is really terrible. Apple products are hardly ever built around the idea of batch exporting to plain text - whatever that is…uh…openness?

Anyhow.

I recently set the Lock Screen and wallpaper to Landscape with the Fall of Icarus. Action and clutter-wise, it’s one of the more boring of the Bruegel’s painting. But, once you contemplate the name of the picture and think to ask, “wait, what? I don’t see Icarus in the sky..” you look around and see that he’s all but slipped under the water after falling - look in the lower right, up and to the left a bit: legs flapping up, some feathers floating down.

Meanwhile, you see the farmer and the shepherd in the foreground, both of them seemingly unaware of the fall of Icarus. The farmer is busy doing some real, normal shit. The shepherd is just staring off into the distance, away from where Icarus fell.

This feels like the multi-year shift I’m trying to have in my life: I’ll let the younger of you out there try to fly into the sky, now. I’m content to just till the fields, or, better, zone out amongst the sheep.

As with all good paintings, there’s an alternate interpretation, as explained by Wikipedia:

The shepherd gazing into the air, away from the ship, may be explained by another version of the composition (see below); in the original work there was probably also a figure of Daedalus in the sky to the left, at which he stares. There is also a Flemish proverb (of the sort imaged in other works by Bruegel): “And the farmer continued to plough…” (“En de boer … hij ploegde voort”) pointing out the ignorance of people to fellow men’s suffering. The painting may, as Auden’s poem suggests, depict humankind’s indifference to suffering by highlighting the ordinary events which continue to occur, despite the unobserved death of Icarus.

Interpret as you will shall be the whole of the law.

Relevant to your interests

• The story of platform engineering - Straight outta Berlin.

• iOS 17 Notes and Reminders Features - MacRumors - Hmmm! I think he only lacking for me is no custom background on Notes. Reminders might finally be good enough for project management? I think you could do some Kanban with the column view.

• The Fight to Repair - GPL thinking finally goes mainstream, eh?

• B612 – The font family - Font made for readability in cockpits.

• Kubecost Cloud Manages K8s Costs for FinOps Teams

• Stone Knives and Bear Skins - “When I attempted to debug the problem, I found that, unlike the tools I am used to in application development, the ones used to debug an OS are primitive at best. In comparison to my IDE and its tooling, the tools I had on hand to continue debugging had more in common with stone knives and bear skins than with modern software.”

• Microsoft Cloud hiring to “implement global small modular reactor and microreactor” strategy to power data centers - I’m sure this is something much less than “Microsoft to build it’s own mini-reactor,” but if still (and even more so if it is that): I don’t man, is this how capitalism is supposed to work? What’s next, Microsoft making servers?

• CNCF Survey Surfaces Cloud-Native Training CNCF Survey Surfaces Cloud-Native Training Conundrum - Skills are always a problem, IT staff is too expensive to hire, but do we spend a comparatively small amount of time and money to train people. No. // ’A global survey of 135 contributors published this week by the Cloud Native Computing Foundation (CNCF) found more than half worked for organizations that don’t pay for training (53%), with slightly less (52%) also noting their organization doesn’t give them the time to pursue certification and training…. About 81% of respondents said cost prevented them from completing certifications in the past two years, while 43% cited time as a limiting factor. Cost and time were the top two constraints for training, selected by 62% and 36% respectively.’

• Confessions of a Viral AI Writer - An intriguing strategy thought in here: what if the AI writing tools are not for The Writers, but the readers. Readers are able to make good enough (or great!) stories on their own. You could say this cuts out the writers, but maybe it just means readers have more to read. Or it cuts out and guts the human writers. Technology!

• Should You Measure Developer Productivity? - I should read this in more detail, but, I think the answer is “yes, just don’t be a dumb shit.” That McKinsey PDF really got the danders up! Coté’s Metrics Law: the only people who don’t want to be measured are the people being measured.

• ChatGPT & Friends: The Cool Kids boosting my productivity - Om’s toolchain for people who think in text.

• 3 questions to get unstuck and start making progress - 1. What haven’t I done yet? Why? 2. What’s stopping me from doing this? 3. What is making me frustrated or discontent?

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Oct 3rd Enterprise DevOps Techcon, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Oct 9th Spring Tour Amsterdam Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

As you can see above, a lot going on next week. Plus, this week I’m try to work on those webinars.

Today I took about half the day off due to one of those mysterious "is it a cold? is it a flu? is it just allergies? or am i just being lazy?" sickness-episode. My dad raised me with the mantra “you don’t get sick, you have a strong constitution.” One, he did not play Dungeons and Dragons, he just liked using big words. Two, this is mostly true.

I need a sickness to either be obviously debilitating before I believe it. This in-between, sniffly nose, stare into the void of your eggshell colored ceiling bullshit is…bullshit.

Videos!

I finally got a good handle on what Backstage does today - not the outcomes it helps you get, but what it’s base, core capabilities are. Ben gave me a nice overview of the basics and let me learn-by-questioning a lot. Hopefully we’ll get together for two more parts: talking about the plugin ecosystem and then how you install, run, and manage it. There’s a podcast, audio only version if you don’t care for videos.

The Prisoner's Dilemma of Cables (in a Family Household)

If you meticulously keep track of your phone charger and laptop cables and wires in a family, everyone else will know that you always have the right cable.

They will stop caring to keep track of their own, losing them constantly. There’s probably no “stop” for the younger ones: it can seem like they never started in the first place!

Then they will come to you to "borrow" your cables. Which they will promptly lose. And then, there you are, with no cables.

So, why keep track of them in the first place?

Software Defined Talk

The three of us were together this week:

This week, we discuss why everyone is envious of Google’s Internal Dev Tools, examine the state of Git, speculate about how 37 Signals plans to reinvent software licensing with ONCE, and share a few thoughts on the Salesforce CEO’s recent comments about work from home.

Watch the video, or check out the audio-only podcast episode.

Relative to your interests

• The Power of a Path-to-Production Workshop - The lines are more important than what’s in the boxes.

• A Guide to Open Source Platform Engineering - The New Stack - ‘“In its simplest form, a platform is just the underlying set of services and capabilities that an application requires to run effectively in a production environment,” Johnson said. Platform-driven automation makes it really easy to do the right things and really hard to do the wrong ones.’

• What Predicts Software Developers’ Productivity? - As ever, better vibes, better work.

• What I learned in year three of Platformer - “the newsletter business three years in is that to be successful, you need multiple things to go right at once: to have the chance to work with a great partner; to generate scoops at some regular cadence; to create a complementary product that expands your audience; and to leverage whatever platform dynamics you can for as long as they last.” And: “thanks to the death of Twitter, it’s harder to promote your work: you wind up posting the same link to five or six new networks, and collectively get a tenth of the views that a year ago you could have gotten on the bird site.”

• The Eclipse Foundation Releases 2023 Jakarta EE Developer Survey Report - “When comparing the survey results to 2022, usage of Jakarta EE to build cloud native applications has remained steady at 53%. Spring/Spring Boot, which relies on some Jakarta EE specifications, continues to be the leading Java framework in this category, with usage growing from 57% to 66%.”

• Restricted Source Licensing Is Here - This is the best advice for buying from any startup/high growth mid-stage company, especially the open source ones: “Review your vendors’ financial health. One of the big concerns with such events is the financial health of your OSS vendor. What if it goes under? The potential loss of the platform will necessitate a search for alternatives, including the potential support of an open source alternative. New open source alternatives based off forked, older source code will take time to develop and may not provide the same experience in terms of adoption, support, and feature upgrades that were experienced with the original.”

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Oct 3rd Enterprise DevOps Techcon, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Oct 9th Spring Tour Amsterdam Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

I haven’t given you a D&D update in awhile. I’ve had the chance to play one of the many solo adventures out there, Solo Skirmish: The Cult of Mol'goroz. This is a very different approach with some at first clunky mechanics, focusing mostly on just combat and rolling for random finds, traps, and puzzles. But, it achieves its goals: it’s fast and action oriented. You have a one page, three part adventure that goes through a four part loop. First, you read the brief overview. Then you roll on a random table for 20 occurrences (anything from finding something, falling into a trap, or some actual story telling). Then you roll for a random encounter (goblins, etc.). Then depending on which stage you’re in, you a level-boss or boss fight, basically. As with all solo systems, there’s some variation here and there, but that’s basically it.

Fighting isn’t really the part of D&D that I like, I like the role playing. But! ChatGPT is pretty good at the role playing part and terrible at the action/combat part. It’s very hard to get ChatGPT to actually advance the plot and make decisions.

So, in the back of my head I’m still trying to come up with an approach to using ChatGPT for solo D&D gaming. The Solo Skirmish system feels like a good skeleton to build it on. You would run through the rigid, action/combat sequence in the printed adventure, and then there would be points where it would say “tell ChatGPT to now play a conversation between you and the guard. Pass ChatGPT this context about the guards…” That’s the kind of thing ChatGPT is good at.

I’ve also been experimenting with getting ChatGPT to come up with outlines for solo adventures (choose your own adventure format). It seems promising. You can give it a premise (a “hook”) and it can kind of come up with branching “go to page 7 to eat the meat-pie, or if you’re vegetarian, go to page 54.” We’ll see.

Rick Rubin’s Podcast

I like Tetragrammaton podcast a lot. (It’s one of those big deal podcasts that doesn’t actually have it’s own home page, which is totally weird - just search for it in your podcast listener or YouTube).

Why? One, it is luxuriously long, Rick Rubin really gets everything out of the guests. Two, he asks great questions: at first they seem naive and simple, but then you hear the answers and stories and you realize how great the questions are. Coming up with and asking questions that get great answers is very difficult.

I think most of his questions are either asking “how?” as in “how do you choose an album cover?” or “how do decide if a joke is good?” His other frequent question is “what was that like?”: he likes asking people in advertising or adjacent industries “was it really like Mad Men?”

If you’ve seen that meme that’s like “how a person looks at a bookshelf” versus “how a carpenter/artist” looks at a bookshelf," he’s always doing the second.

He’s just so chill too.

He very rarely has anything negative to say. You leave each episode pretty much feeling great and optimistic.

As an exception that proves the rule: in one interview you hear him almost putting down executive types at record companies who are more interested in selling than creating good content. He says, they don’t know what they’re doing. But that’s about as far as the negative vibes goes.

Some of the episodes are a little weird if the people he’s interviewing don’t have much to say. I skipped over some two part series of, you know, magic powder doctors early on.

The content is good, and long-term there’s some kind of world-building going on that’s attractive. He’s building a world of curiosity, creativity (even “art”), all bound up in a world-view of just chilling the fuck out.

I mean, he’s rich and famous. We’re hearing from the rare exception to the thousands of producers and creative types that didn’t make it big. But, if you can put aside the accurate but boring Halo Effect criticism, it’s good stuff.

Also: the ads he has are fun to listen to and many of them are super-weird (nutrition-scammy) products. Macadamia nuts? Powdered imitation-gatorade? But, the actual ad reads and production are fun!

Wastebook

• We’ve passed a fuck-line here in Europe. I’ve seen the word “fuck” on more surfaces than ever: t-shirts, for sure, laptop stickers, on cars. I feel like it’s still spicy talk in the States, but overhear it feels like part of the general European trend to just like, well, not give a fuck.

• “Clarity first, then consistency.” Here.

• Three groups of people were playing cards in the Zadar airport. Is that a Croatian thing? Who ever plays cards anymore?

• “The Church of Recurring Revenue.” Here.

Have you tried just following best practices?

Don’t let the factory rust.

• Why and how cloud native technologies give you more control over your software delivery process? A rough answer: Cloud native apps are modular, container-based designs. They run in container orchestration engines and, it is hoped, have much of the infrastructure and networking stuff automated (though, this is yet to be fully realized and creates a problem in its own). Assuming the happy path: they're designed to be efficient to run, fast to deploy, and decoupled. This means you get more cost controls and more agility. What's important, though, is to standardize on how you do this.

• Much of what you probably suffer from now is having to deal with a whole bunch of different ways of developing, managing, and running applications, tech debt, and having to spend time manually doing compliance and security checks. "The business" and developers don't have enough cycles to study what users actually need, experiment with the best way to solve it, all while making sure they comply to internal standards and regulations. Doing all that "not the actual UI" work (moving pixels on the screen!) takes a lot more time than you ever think. One person in banking estimated that amount of toil at 50% to 60% of their team's time.

• Before we get to any of that, though, you need to make sure you’re thinking of software as a core part of how your organization runs. Here’s a simple test: who decides what your developers do? Are they given requirements and “wire frames” from another group and given a date to hit? This probably means you’re doing it wrong. Are they told what you need to accomplish and why those goals are important for “the business,” and then they can decide how to deliver those “outcomes”? You’re probably closer to good software culture.

• No matter what tools you use, if you follow a command-and-control approach to software, your results will be less than ideal. People know this is lean manufacturing: you push the work closest to the people actually doing the work. It’s no different in software, and, in fact, is even more so. With software the developers and operations staff are both working on the line and building the factory at the same time. They should be the ones determining what to do.

• Eventually management can take a bigger role as they become more like developers, or understand how software works. In tech companies, many of the founders and executives are (former) developers, so they of course know how to manage and get results from developers and operations people. Is that the case in your organization? What is management’s background? The board?

Relative to your interests

• A new way of thinking about open source sustainability - If you’re using open source components in your IT stack, don’t forget that long term reliability and stability is costly, and worth paying for.

• “We gave a profession of bullshit generators access to GPT-4. You won’t believe what happened next.” - If the work you’re doing is predictable - in this case, a lot of the junior level work at management consulting firms to come up with new strategies and GTM - the AI can help. The positive side: if you’re considering getting the consulting firms to bootstrap your annual planning, try a week with ChatGPT instead and see if it feels the same. Then don’t hire them, as much? Also, the AI is good at hype-marketing.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Oct 3rd Enterprise DevOps Techcon, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Oct 9th Spring Tour Amsterdam Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Oct 12th Spring Tour London Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

I have a week and half before I travel again (see above) - and then it’s a doom-doozy of a travel week, plus more travel to follow. And, as you know, outside of the talk you’re giving or the meeting you’re having, very little gets done during work-travel. There’s also a series of three webinars in the works. And, I need to create/learn a new talk or two during that time. Meanwhile, there’s other macro-winds on the horizon way above my pay grade.

It almost seems all undoable! I wonder if that’s why I’ve been feeling more anxious than usual of late…

I’ve been thinking a lot about one of my annoyances working with experts/practitioners (well, anyone) over the years: they’re always telling me they don’t have time to take on new work, their backlog is full. And, I’m like, “I just want to record a podcast!” Turns out, you can just say no. Is that a way people work? Could I just say “oh, I have travel upcoming, a three webinar series, and then I need to make at least a podcast a week, and can you imagine how long it took me to type up that rant on analyst reports (a lot shorter than you think because I basically took one pass and didn’t edit it - but you get what I’m saying), so I can’t do that podcast”? Would my life and bank account be better? Would my work be better? Would my employers finances be better? At a startup…no? But at a regular company?

There’s something to be said for calibrating on “only work on things that matter, that have impact.” Which, I guess. But I also feel that in a big company, you hire a lot of people to do work on the mid-tier “impact.” The management/work advice we all soak in from startups and “high growth” companies seems hardly applicable to, like, the real world.

I have no calibration for those things. It’d be nice to have some, though.

(Also, I just ordered an iPad mini - I didn’t realize they had that size with the Apple Pencil. I love using my big ass iPad Pro with the Apple Pencil, but I rarely do it. Could this mini get me over that edge. In theory, it’s also the perfect form factor for Kindle books and even PDFs [I think you’d have to landscape the iPad mini and scroll through the PDF instead of going full page, but that’s probably fine]. My main concern is, like, protecting the pencil. I need to find some kind of tape on hard-case that I can have for when I want to do the whole throw the iPad in my bag things. However, the main scenario I’m targeting is a go-bag with my video recording gear [tripod and iPhone mount with hot-shoe, Rode Wireless II’s, various cords] and the iPad mini. Throw in a little foldable bluetooth keyboard, and this feels like a good setup for trips where I can leave my laptop behind. The only thing I really need a laptop for is editing slides, probably? I think you can record podcasts and even present from iPhones and iPads. THE DREAM.)

The infrastructure drives the app architecture

A cloud native applications is typically designed as a bunch of little components that coordinate with each other over a network. They may use events instead, and while that isn’t the same as point-to-point network communications, it follows the same idea: you have a bunch of indepedent-ish bundles of code that work together, as needed, instead of just one big chunk of code that does all the work. This is, you know, a distributed application. “Message passing” is one of the dreams of object oriented programming and Internet apps.1

Microservices!

Why you use a service mesh

Anyhow, if you’re do all of that, you need a way to manage all that network traffic. Each little bit of code has to know how to contact the other bits of code and work with it - so called “east-west traffic.”2 You need a registry that catalogs all those bits of code. You need to know information about that chunk of code: the version, how to connect to it, how to authenticate with it. You need to somehow make a call over the network, that is, get a network connection. You want it to be secure and encrypted, like, always now-a-days (I don’t really know what mTLS is, but EBC decks are fucking rife with it, so it must be great). And then the people running that network want to manage it: if some chunks of code are too chatty and filling up your series of tubes with too much crap, you want to throttle them. You want to gather metrics about your series of tubes and the messages sent down them. You know: network management. And, when you’re using it with Kubernetes, you want it to all think like and work with Kubernetes: how you configure and deploy it (yaml!), how configuration is rolled out and drift is done. Etc. Etc. (Check out Ivan McPhee’s service mesh overview for a lot more details and the vendors in the space.)

What drives me bonkers about this is that, like, this is what the Internet does. Why don’t we just use Internet primitives to do all of this? Why do we need to layer a whole new network management layer on-top of all the layers. Even more maddening, when you go up the stack into the application layer: the developers there have written all of their own stuff that handles all this functionality. You look at something like the projects in Spring Cloud and they’re, you know, doing all of this too. I’ve started to think that each of these layers happens because the people in the layers above you don’t want to talk with the network admins.

Anyhow, back to service meshes. They are handy! They do important things! For example, help you run your applications across multiple clouds, Kubernetes clusters (is that the right phrasing?), add in customized layers of security, and so forth. Big ol’ enterprises need all of this. I mean, everyone does.

So, what’s up with the whole category of service mesh? Well, Gartner is not so hot on it:

The hype around service mesh software has mostly settled down, and the market has not grown as much as was once anticipated. This raises questions about the usefulness and ROI of service meshes for most organizations. “Market Guide for Service Mesh,” August 2nd, 2023, Gartner.

The report notes that service meshes are used outside of Kubernetes as well. It’s like a whole new marbling of a layer around and inside your existing layers, be they VMs or containers. Yay…? Ivan’s take a little less dire, simply urging taking it slow before choosing which service mesh to use:

Avoid adopting a service mesh based purely on consumer trends, industry hype, or widespread adoption. Instead, take the time to understand the problem you’re trying to solve. Explore the potential tradeoffs in terms of performance and resource consumption. Evaluate your support requirements against your in-house resources and skills (many open-source service meshes rely on community support). Once you’ve created a short list, choose a service mesh—and microservices-based application development partner—that works best with your software stack. Ivan McPhee, GigaOm, August 2023.

Filling in the gaps

When I first head about the notion of a service mesh long ago, my first reaction was basically “wait, I thought Kubernetes already did that?” This was the first in a long series of that reaction over the years. It turns out Kubernetes didn’t do a lot of the things I assumed it did. This was an instance of confusing outcomes with capabilities: for all the praise Kubernetes gets for improving operations and developer productivity, I’d assumed it, like, had those capabilities. But, in fact, many of the outcomes Kubernetes achieves are done by layering in all sorts of other projects, products, and ways of working.3 Ivan’s report does good job cataloging all those capabilities: your eyes can start to glaze over after awhile, so be sure to read the vendor profiles in reverse alphabetical order!

So, you need a service mesh to get all of that basic, distributed app functionality. This is fine! That’s how Kubernetes was designed, whether the overall community over the years treated it as such or not: “platform for building platforms,” “a life of it’s own,” and all that.

That Gartner report identifies a key trend in the ongoing rollout of Kubernetes. People don’t want to pay for things, and this leads to a lot of unplanned for work on their part of integrate all the free components together and deal with them:

The current service mesh market is largely dominated by open-source offerings such as Consul, Istio and Linkerd. However, Gartner client inquiries about service meshes consistently show open-source service meshes suffer from difficulty of use, and a lack of sufficient skills for effective engineering, administration and operational upkeep. The lack of mature DevOps practices can increase the operational burden. These challenges substantially increase as the number of deployed container pods and services grows exponentially, especially in a multicloud environment.

Hey, you get what you pay for. For vendors, this does mean one important product management and strategy decision: you need an easy to download, easy to get up and running, and totally free on-ramp to your paid-for product. I mean: that’s just late 2000’s, open core and early public cloud basics, right?

That Gartner report is good reading if you have access to it.

On your radar

I’m guessing you don’t have access to Gartner, so you’ll probably be interested in this GigaOm report from Ivan McPhee (have I referred to it already here yet?), which you can read thanks to my employer VMware. It’s equally good, though not as strident. Here is their radar:

We also discussed the services mesh concept and space on last week’s Tanzu Talk podcast (podcast or in video form-factor). Also, check out this interview about service meshes on our podcast from July of this year.

Relative to your interests

• Second Wave DevOps - The tools keep changing: “Let’s face facts: our implementation is what’s letting us down. What worked for John and Paul in 2009 is, in broad strokes, exactly what we have been asking every single DevOps practitioner to do since. We’ve replaced all the individual tools in the system multiple times (look at the CNCF Cloud Native Landscape for the evidence): less automated infrastructure, more infrastructure as code; less monitoring, more observability; less data centers, more cloud; less svn, more git; less virtual machines, more docker; less capistrano, more kubernetes; less hudson, more github actions. The problem isn’t that we haven’t optimized each individual part of the system enough. We’ve built more efficient tooling at every step. But the way the whole system is put together? The experience of using it? That’s basically identical to how it was in 2009, and it’s the reason we’re stuck.” There’s two fronts to the “DevOps is dead” rhetorical war now: from the platform engineering crowd and the fraction within the DevOps crowd itself.

• Did I Make a Mistake Selling Del.icio.us to Yahoo? - Plan to never get past slide one: “Any decision was an endless discussion. I remember once, we had to present to a senior vice-president. We had a 105-slide deck prepared, and we didn’t get past the second slide because they ratholed about one fucking slide. It was a miserable environment.”

• iOS 17 release: everything you need to know about Apple’s big updates - A concise list. The journaling app comes out later this year.

Survey: Majority of US Workers Are Already Using Generative AI Tools, But Company Policies Trail Behind - “The new survey finds that 56 percent of workers are using generative AI on the job, with nearly 1 in 10 employing the technology on a daily basis. Yet just 26 percent of respondents say their organization has a policy related to the use of generative AI, with another 23 percent reporting such a policy is under development.”

Logoff

I was at SHIFT in Zadar, Croatia this week. I presented my platform talk on a huge stage! This was an arena and the stage was on the center, you were surrounded by the audience. That’s not normal: usually, the audience is all in-front of you. When I’m presenting, I tend to pick out three or five people in the audience that look at. You, of course, want to pick out people who are smiling and paying attention to you. They give you energy, and also help you figure out if your approach and content are working. In this case, I forced myself to circle around the stage, finding those people in all directions.

If you find yourself “in the round” like this, try to move around so that you can find more of those positive vibe people.

Also, the morning of I had some kind of anxiety attack. You know, the kind where there’s nothing to actually worry about and yet it feels like there’s everything to worry about. It wasn’t about speaking at all. In fact, I was looking forward to finally getting up there because I knew it’d drive out that general panic attack thing. And, it worked! Public speaking is a safe, calming space for me.