Technology Done to You, Not for You

About 6 months ago, I teased a series on the idea of facadeware, largely starring our lemon of a Grand Cherokee, but speaking more broadly to a problem with how we’re developing technology.  Specifically, I defined this concept as:

Facadeware: superficially advanced gadgetry with an actual net-negative value proposition.

I’d like to start unpacking that and write my series.  Now, I’m not going to do what so many bloggers do and promise to write regularly again, since I have no idea if I’ll be able to back that up.  But I am now through my two relocations in two months, settling into a permanent location, and hoping to have at least a thin sliver of free time to once again indulge my deepest passion: ranting discursively on the internet.

(I won’t belabor the point here, but for anyone interested, I’ll add a personal update as a footer to this post.)

Before I tell the tale of my Jeep in subsequent posts — and tell it, I will, rest assured — I want to expand on the concept of facadeware.  I also want to reemphasize that I would no longer feel good about applying the label “technologist” to myself, descriptively or aspirationally.  And that’s not because I now mostly do bureaucratic business ownership stuff for a living.

It’s because I no longer thing “technologism” is worth aspiring to, given the state of technological advancement.

Handing in My Technologist Card

Before going any further, I’d like to reiterate that I still like to program, build, tinker, and improve.  Hell, just tonight I performed some quixotic field surgery on a Keurig, successfully bringing it back from the dead briefly, before it re-died in a blaze of cooking circuitry. It isn’t a question of my tastes or interests changing, but rather that I increasingly don’t think that the way we, humans, are advancing technologically is a net positive.

In fact, I’d go so far as to claim that I think we have collectively, technologically regressed over the last 10-15 years, notwithstanding a never-ending slew of phones that are slightly bigger, or thinner, or… something… each time.  Technology in this time has advanced, in a sense, for some definitions of “advanced.”  More computations are happening, and the cost of that computing is going down.  Various things are getting faster, more parallel, and certainly they’re spewing shit at us in higher volumes than ever before.  Endless scroll wasn’t around 15 years ago, and we now have that.  So, that’s, uh, awesome, I guess.

Things are progressing down a path.  There are undeniably more gerbils running in more, bigger, gerbil balls, flinging more gerbil poop into the universe than ever before.  Nobody can look at our world and be anything but impressed at the advancements in gerbil poop per cubic meter per hour.

But does gerbil poop, impressive in its volume and efficiency, make anyone’s life better?

A Meaningful Definition of Advancement

At this point I’m going to back slowly away from the gerbil metaphor and trust that you’ve absorbed my implicit point that more-faster-cheaper isn’t a synonym for better.  But if more cores and circles on the back of my phone aren’t necessarily better, what is necessarily better?

What indeed is the purpose of technological advancement?

Well, I’d argue that the purpose has historically been to improve the lives of users of the technology.  For most of my life, and the 20th century preceding my life, I think one could argue that this was generally the primary goal of most technology (allowing for the exception that a lot of advancement comes from weapons research and is later repurposed for benevolent applications).  Technologists built stuff to make their and others’ lives better.  The user was the hero, and the technology was the enabler of the hero’s journey.

To drive this home consider the fictional Star Trek universe.  I’ve recently learned a term “solarpunk,” that, if I’m understanding it correclty, could describe that universe.  In that world, the crew of the Enterprise says things like “computer, make me an 8 course Thanksgiving meal” and it just happens without a lot of navel-gazing and mythologizing about how the computer does it and how it’s disrupting the farming industry.

The fabricator, the warp drive, the holodeck — these things all just serve the occupants of a galaxy with a substantially better standard of living than we enjoy.  Centuries of technologists focused on improving the lives of others led to meaningful, life-changing outcomes.  This is what I signed up to participate in when, 30 years ago, I started to consider myself an aspiring technologist.

And this is categorically not what we’re doing any longer.  So I’m out.

Where We’re Heading Instead

When I first arrived at our new home in Phoenix, the plumbing wasn’t yet hooked up to our fridge, so I was temporarily forced to make ice cubes in trays, like some kind of savage of a bygone millennium.  I went to Walmart and bought a couple of ice cube trays and found myself pleasantly surprised by an advancement in this technology, even though I paid like 40 cents for them or something.  They had a lid that fit over the top with a coverable hole in it, so that you could easily fill them and walk to the fridge without sloshing water all over yourself.

I thought to myself, “this is a legitimate, genuine improvement that makes my life better in a meaningful, if tiny, way.”

I then realized that was more than I could say for most of my SaaS subscriptions and gadgets.

Google has recently pioneered new ways to punish me for using uBlock Origin.  Our Jeep has recently showcased a major breakthrough in showing ads on our nav system.  Netflix and other streaming services have explored sophisticated ways to annoyingly turn off my TV if they think their engagement stats are dropping, and they’ve happily shared that knowledge with traditional telecom companies.  And everything, and I mean everything, has some kind of moronic AI chatbot that nobody wants, and serves only to explode the failure density of every applied technology in our lives.

Technology is no longer done for us.  It’s done to us.

We are no longer the beneficiaries. We’re the marks.  Improving people’s lives via technology has taken a backseat to extracting money, time, and attention from them via the same.

And, again, with that, I’m out.

Read More

Generative AI and the Bullshit Singularity

I haven’t forgotten about my promise to discuss the concept of facadeware.  The slings and arrows of outrageous fortune continue their assault on me as I navigate, among other things, two relocations in two months.  I want to write the series, and I plan to write the series, but I’ve been busy.  Nonetheless, thanks to those who read the first installment and the smattering of donations that were eventually refunded.

Anyway, as I thought about how to continue that series, I realized that I’d have to talk about generative AI.  In the year of our Lord 2025, if I were to avoid talking about GenAI for as long as 15 minutes, I’m pretty some kind of Harrison-Bergeron-universe agent would break into my house and electrocute me.

Generative AI Isn’t Facadeware

First, let me say that what I’m describing as facadeware predates generative AI’s explosion onto the mainstream in 2022.  I also don’t think GenAI is an example of facadeware.  At least, not exactly.

In the previous post, I briefly defined facadeware as “superficially advanced gadgetry that actually has a net negative value proposition.”  And while GenAI clearly has a (to date and for the foreseeable future) net-negative value proposition, I wouldn’t categorize it as superficially advanced.  It is genuinely advanced, and it is an impressive feat of experimentation and human ingenuity.

And so because of this, GenAI/LLM techs don’t really have a place in the facadeware series (though I think the concept of “agentic AI” does qualify).  However, I want to dump my bucket on this subject both because I know people will invariably bring it up for discussion and because I think a relationship, if not direct, does exist.

The Role of Bullshit in GenAI and Facadeware

Bullshit, as a concept, plays a foundational but different role in both GenAI and in facadeware.  The role of bullshit in facadeware is relatively simple.  To sell anything with a net-negative value proposition, almost by definition, requires bullshit.  Bullshit is the fuel of the facadeware engine.

GenAI kind of inverts this.  With GenAI, the fuel of the engine is human ingenuity, and the output is bullshit.  In other words, some of the best and brightest minds in all of enterprise Silicon Valley have produced a technological advancement that is to bullshit what cold fusion would be to energy output.  It was an improbable and unexpected giant leap forward in humanity’s collective capacity to generate bullshit.

So if you were to look for a relationship between facadeware and GenAI, the most likely scenario is that you would either use GenAI to generate facadeware or simply to market it.

Defining Bullshit Somewhat Rigorously

Now, before I go and make you think this is a simple exercise in Luddite shitposting, let me be clear that I actually have nothing against bullshit in moderation.  Anything you do on social media is more or less bullshit, and plenty of self-soothing and self-indulgent narratives, like schadenfreude fantasies, are bullshit.

Now, let’s actually define bullshit with some precision before I lumber onwards with this rant.  The dictionary in Google give us a short, sweet take:

Read More

My Experience at DevOps World, 2023: Empowering Enterprise Engineers

Editorial note: This post originally appeared on the DevOps World blog, arising from me attending that event as “press.”  I’m going to be at the next one, this Thursday, in Silicon Valley.  If you’re in the area and able to make it, let me know and we can have lunch.)

I have a renewed sense of hope for the condition of the enterprise software developer.

For anyone familiar with me or my career, this is quite a statement. For the rest of you, to whom I’m some internet rando, I won’t bore you with more details about me than are absolutely necessary to understand my take. Suffice it to say that in 2017, I wrote a book whose central thesis was that software developers should initiate an exodus from the enterprise.

Fast forward 6 years to now, when I just spent the day as “press” at DevOps World, listening to a series of talks and interacting with participants and sponsors. Based on what I’ve seen here, my outlook for the future of enterprise developers is far less bleak than it was back then.

I’ll dive into the specifics of why, but the overarching theme is that it seems organizational change in the enterprise has evolved from a long history of something being done to software developers into something being done for them.

At this conference, I heard and saw a lot of innovation aimed at earning developer buy-in, relieving their toil, and sending them back to their various enterprises with pragmatic, actionable ways to improve their situations.

Where It Started: The Endless Agile Transformation

One more biographical detail, and then I’m done. I promise.

In the mid-aughts, starting about 10 years ago and running up until I wrote my book, I earned my living as a management consultant in software, almost exclusively in the enterprise. I specialized in static code analysis for strategic decisions, but often found myself in enterprises, helping them answer the basic question, “why is our agile transformation not working?”

Back then, DevOps was scarcely on the radar for enterprises. Instead, everyone was doing a so-called “agile transformation,” which generally meant having a different, Scrum-flavored series of meetings and changing very little else. These firms were usually in year 6 of a 2 year transformation, and were still working on the “define what agile means” OKR.

The Bad Old Days of Shifting Burdens to the Left

If that sounds cynical, fair enough. But ask anyone in those orgs at the time, and they’ll almost certainly laugh ruefully and call it accurate.

One of the day’s speakers, Thomas Haver, referred to these sorts of institutions as “technology museums,” and I can’t think of a better turn of phrase. When you’re gluing Perl scripts to mainframes as part of some internal line of business initiative, you’re not using the latest and greatest, and you’re probably not knocking out that agile transformation any time soon.

But I think the central problem that engineering groups in these organizations encountered back then was neither the comically old technology nor the glacial pace of organizational change, per se. Rather, developers found themselves buried under the crushing weight of endless todo lists, as their employers heaped an ever-growing mountain of burdens on them.

Organizational Change Done To Developers

I can remember some interesting characters that I met during my consulting travels:

• The “schema specialist,” who did nothing but review developer-proposed changes to any database, anywhere, and give them notes on what to do instead.
• The “environment administrator,” who did nothing but review (and usually reject) requests to move JARs from one non-prod environment to another, and make sure the proper digital paperwork had been submitted.
• The “integration architect,” whose contributions I never managed to figure out, but could reject seemingly anything that created an interface between two dev teams.
• The “demo guy,” who engineers would have to work with to create power points for their sprint demos (instead of the customary “working software”).

I could go on, but I’m trying to make a point, not supply fodder for xkcd. And my point is that everything these organizations did heaped work on the engineers, including the creation of roles that seem like they should theoretically specialize work away from those same engineers.

To earn a living as an enterprise developer in the age of the agile transformation was to be an endless collector of bureaucratic toil. Write your software, submit compliant schema requests, fill out the JAR movement form in triplicate, please the integration architect, and make sure the power point guy knows that you’ve been delivering enough story points.

By the end of my consulting years, I hit peak cynicism. I thought developers should leave and not tolerate this situation, and I thought enterprises should give up on creating software and delegate that activity to vendors and future acquisition targets.

I’m pleased to see that things look different than when I left consulting 6 years ago.

Moving to Organizational Change For Developers

DevOps World had a common, refreshing theme. Tracy Bannon captured it well during a discussion panel: “The idea of shift left is not ‘dump it on the development team’.”

In opening remarks for the event, CloudBees CEO Anuj Kapur pointed out that a poll of CloudBees customers found that developers only spend 30% of their time, well, developing. The rest is lost in some flavor of dark work or another.

Everyone at the event seemed to agree that this is a wholly unacceptable state of affairs, and that the path forward is one that involves a rethinking of what is asked of developers and what is done for them.

Removal of Toil

The first main event theme that I observed centered around eliminating toil. Rather than schema and integration specialists forcing checklists on the developers, conference participants explored the use of tooling and organizational tactics to eliminate as much toil as possible from the world of enterprise engineers.

In the conference keynote, “Go Big, Say Yes,” CloudBees announced product changes with a direct impact. They made CloudBeesCI highly available and highly scalable, meaning that organizations have immediate relief from problems such as bottlenecked jobs, needless time waiting for workspace downloads, and infrastructure-related build failures. All of this rolls up to a very simple value proposition: developers using their time instead of killing it, waiting for infrastructure.

When the engineers present saw the new Pipeline Explorer feature demonstrated, they burst into spontaneous applause, even though there was no break in the presentation. And the reason is obvious: they could see an end to loading some gigantic text file into an IDE so that they could search awkwardly for the reason a build bombed out. Pipeline Explorer lets them get there immediately, without the pain.

This idea wasn’t limited, either, to product announcements or even the talks. I watched the folks at Gradle, one of the sponsors, demonstrate a way to identify and troubleshoot flaky unit tests and the ability to use machine learning to prioritize executed tests based on changes to the codebase.

And Redgate did a demo of an offering that allowed source controlling database schema changes and keeping them consistent, in sync, and drift-free across environments. And all of this without a “schema specialist” in sight to scold them – just engineers safely changing the schema as needed.

Developer Buy-In

The engineer enablement theme wasn’t limited to tooling, either. One of the main takeaways that a recovering management consultant like myself couldn’t help but notice was the theme of getting buy-in to broader goals from the folks tasked with delivering them.

For instance, Katie Norton explained the concept of a software bill of materials (SBOM) and the broader concept of a software supply chain. Rather than a checklist of context-free “best practices,” this talk, aimed at an engineering audience, used practical analogies and diagrams to illustrate the challenges around and the gravity of managing the risk presented by using open source components.

This seems a lot better to me than how this risk was typically managed 10 years ago in enterprises: “don’t use open source.”

There was a talk that explained the idea of attestation and why it matters, encouraging teams to move compliance from a rote series of tasks to an objective, auditable and, most importantly, automated set of data. The mission was to avoid what presenter John Willis referred to as “governance theater,” wherein engineers would rename incidents to “cases” because of the reduced scrutiny that invited, or simply upload the same screenshot of a test run for 2 years to demonstrate that they had achieved code coverage.

Instead of tsk-tsking, this deceit was recounted with understanding. Of course teams did this when they were trying to ship features on time – it was the only way to get their work done. The developers here don’t need to change; the organization does.

Practical, Actionable Advice

Perhaps the most powerful motif of the event was that it distilled advanced practices and industry insights into easily actionable takeaways for participants.

For instance, speaker Julia Furst talked about the impact of generative AI on DevOps practices and suggested a series of tools that attendees could go and investigate. Ali Ravji and Mihir Vora from Capital One distilled hard-won experience building scalable CI/CD pipelines into concrete suggestions: focus on reusability, parallelization, and failure planning.

And, how’s this for practical and actionable? “Contribute to open source and adopt a plugin.”

Mark Waite, Senior Engineering Manager at CloudBees gave a really cool talk about how contributing to open source goes well beyond putting collateral good into the world and is actually good business. He relayed his experience building a CI solution for his XP team back in 2003, before Jenkins existed, and how that required a dedicated team member to maintain.

A much better solution, had it existed, would have been to contribute to Jenkins and use it. So he encouraged attendees to go contribute to open source to improve it, fix defects, and patch vulnerabilities that can help their organizations upstream, before things become expensive.

The Joy of Being Less Cynical

While I certainly enjoy a good, cathartic rant from time to time, it’s not exactly fun being cynical. Usually, it’s a sign that you need to take a vacation or start a different job.

So it was nice to circle back to the world of enterprise software development, after years away from it, and find it far more promising than I remember. It was nice to see an enterprise less focused on crushing engineers under the weight of endless compliance tasks and more focused on helping them ease that burden.

If schema specialists and build administrators must exist, at least they can do so in supporting roles and with powerful tools, instead of the promise of toil for their colleagues. DevOps World was a fun event, sure, but it was also a philosophical palette cleanser for me.

Incidentally, the next stop on the tour is in Silicon Valley October 18th and 19th, and I’m planning to attend that event as well. If you’re in the neighborhood and so inclined, grab yourself a pass and we can have lunch or a beer at the happy hour.