Software. Startups. Outer Space.
Aaron Stannard is the Founder of Petabridge and creator of Akka.NET, building open source tools for .NET developers to build concurrent and distributed applications.
Azure released a major update to some of their VM images last week and it’s caused a number of problems for me:
mono support was removed from ubuntu-latest, which caused all of our FAKE v4.0 builds to no longer work1 for Akka.NET and several of our other mature projects;SignService, our workhorse for Authenticode signing all Petabridge NuGet packages for the past seven years, stopped working suddenly on the Azure App Service we’ve been using.I have no idea what Microsoft did to kill this service off, but my guess is they finally stopped supporting the ancient version of .NET Framework this was running on starting on April 11th or so:
We had owed a customer an update today and the race was on to find a replacement for SignClient - quickly. We quickly settled upon dotnet/sign - and then the race was on to figure out how to solve the infernal quagmire of Azure Entra / AAD permissions hell in order to access our Azure Key Vault where our signing certificate is stored.
This post explains how to do that.
I have a lot of respect for Geoffrey Huntley. So when I read his blog posts about AI over the past couple of months: “Dear Student: Yes, AI is here, you’re screwed unless you take action…” and “The future belongs to people who can just do things” among others, I thought to myself - “am I missing something?”
This image of his, in particular, summarizes his take on AI and the impact it’s going to have on the software development industry:
He’s essentially singing the same song that people who sell AI courses do: “if you’re not dropping everything to learn AI right now, you’re going to get left behind!” His conclusion to “The future belongs to people who can just do things” ends thusly:
Ya know that old saying ideas are cheap and execution is everything? Well it’s being flipped on its head by AI. Execution is now cheap. All that matters now is brand, distribution, ideas and [retraining] people who get it. The entire concept of time and delivery pace is different now.
Distribution, brand, et al are important - no doubt. The idea that any LLM, even ones with future capabilities, is a catch-all substitute for experience is laughable.
In a world where typing in the right prompt to a chat window is “all you need” for “execution,” this actually makes idea guys even more commodified and worthless than they already are - and they’re already worthless.
“You can build it cheap, fast, and good - pick two” is how the saying goes, referring to the inherent trade-offs in software development priorities. It makes intuitive sense but utterly fails in real-world applications. Two simple reasons why this correlation does not hold:
Price is its own independent quality determined entirely by the buyer’s and seller’s perception of value.
As the Dan Luu article I linked to mentions - it’s fairly difficult even for experts within a given domain to accurately assess the market value of their own services (or someone else’s), hence why price discovery has to be tested continuously1.
But let’s take a closer look under the covers at the price vs. quality and price vs. speed relationships.
This week FluentAssertions, a popular open source library designed to make it easier to write assertions during unit testing, changed its license from Apache 2.0 to some commercial terms under the name of a new business entity, Xceed.
The net impact of this is that FluentAssertions now costs $129.95 per seat for commercial use for version 8.0 and later.
Naturally the .NET community was in uproar over this on /r/dotnet and in a few other places, like this comment from the “.NET Eventing Framework” thread which inspired “.NET Developers Begging for Ecosystem Destruction”
In this post we’re going to unpack two things:
As of Monday this week, my company Petabridge turns 10 years old. I’ve been my own boss for longer, but my tenure at Petabridge is nearly 5x my tenure at every other company I’ve founded and at every place I’ve worked.
When you set out on a new venture, rarely do you expect things to go this well or last this long - so I decided to take some time to cobble together 10 lessons that have kept me sane throughout my entire odyssey with Petabridge.
My management style has evolved a lot over the years, but one constant I’ve kept from the beginning is to coach the best possible performance out of my players. That seems like an vacuous management platitude, but it’s not: doing this requires tremendous patience, brutal-yet-sympathetic candor, and an ability plus...
If you follow me on Twitter / X, you have likely seen several increasingly exasperated tweets from me about a legacy software project from hell. This project deserves its own series of blog posts and YouTube videos, but in service to a higher calling in the field of software I’ll reveal it now: these coding horrors all originate from our rewrite of Sdkbin.
More accurately: we decided the best path forward was to rescue Sdkbin 1.0 and not rewrite it after all, but we’re still conducting the software equivalent of tearing a building down to its foundation and starting over again.
For all of its faults, Sdkbin does generate a significant amount of revenue for us each year. We’ve kept it on life support for four years because its original author left it in utterly incomprehensible shape. In this post I’m going to talk about the plague that’s killed four years of opportunities and left this project swaddled in technical debt before it even served its first customer: frameworkism.
In this post we’re going to travel back in time to 2010 - a happier, simpler time for early-stage startup software developers. When Heroku was free and front-end developers hadn’t had a chance to ruin the JavaScript ecosystem yet. We will eventually make our way back to 2024 .NET-land.
Back in the MarkedUp and early Petabridge days, I worked out of Coloft in Santa Monica, CA - a pioneer in the co-working space in Los Angeles. We had lots of startups and software developers of every shade working out of the space - it was even Uber’s original LA office location until they outgrew it.
But one group of developers who left a lasting impression on me was a Ruby on Rails consulting shop that specialized in delivering SaaS and mobile back-ends for Apple’s fledgling App Store (back in 2010.)
What these guys had down was a one-size-fits-all universal template for delivering client applications:
When talking to members of our team about their projects and taking on more responsibility for their outcomes I will regularly recommend the following:
“You should hate your own work product and still ship it anyway.”
This advice is as applicable for shipping software as it is for sending sales emails, graphic design, sweeping floors, or writing this very blog post. But why give it in the first place?