Author: geostock

There’s an interesting phenomena I just learned the name for, even though I’ve experienced it dozens of times in my career (probably more), called “right-half-plane zero”.

Basically, right-half-plane zero is the idea that in order to correct an issue, sometimes you’re required to go the opposite direction first. The author uses a bicycle turning right from a stop, you have to turn ever so slightly to the left first. This can be confusing and nerve wracking, but without going in the wrong direction first, you won’t be able to succeed.

The idea and its implications are fascinating, and I encourage you to read more about it, but for this moment today, what are some situations in software development where executing a half right plane zero makes sense?

Here’s a few I’ve thought of. Hit reply and tell me yours.

• Refactoring a codebase
• Implementing TDD
• Tightening Hockey Skates (not about Software, but something I had to do just this morning)
• Diagnosing hard to find production issues

We put more value in agile than we could ever possibly gain from it.

Agile started as a lightweight development methodology to compete with waterfall.

What is it now? It’s everything and everywhere.

I have no data to back this up —- only anecdata, but it appears to me as if we place more value in what we want agile to be than what it is.

We want it to be the solution to building software. Is it? Empirically?

The answer is empirically “no”, and like any good defense, when an agile project fails, we look for the True Scotsman. “No one who really followed agile would have tracked story points” or some such.

While this is maybe a little bit a comdemnation, our current situation is, at its core, remarkable, that is, worthy of remark.

Software is maybe 60 years old, certainly as a commercial industry younger than that. We are still very much in our infancy in figuring out how to build software reliably. Software runs the world, and any mistake has an outweighted value over the fact that just 60 years ago we would never have bet that self driving cars would be a reality.

We’ve moved pretty quickly for not knowing what the heck we are doing, and I believe there is value in figuring out how to build software better. Is agile it? No. But it’s been an improvement over what came before it.

What’s after agile?

My 3 year old daughter has a hankering, yes, a hankering for the song “Let it Go”. Keep in mind, it’s 2022, and the original Frozen came out in 2012; but to her, every day is “Elsa” day. Every moment in the car, she wants Elsa. She has her sister’s elsa crown, she has multiple pairs of elsa jamas that she wears every night, and she is in love with the elsa bodywash. She even has an elsa palace that when she hits a button, plays, you guessed it, Let It Go. She’s seen Frozen, Frozen 2, Frozen Fever, and she’s read both the Golden Book styled Frozen, as well as the giant illustrated Frozen, and loves to color on the Frozen coloring book she has with the Frozen markers that are just made to not get Frozen colors over anything that shouldn’t be colored.

The interesting thing about each of these is that they all tell a piece (or all) of the Frozen Story (which itself is inspired by Hans Christen Andersen’s The Snow Queen), but each of them are markedly different. More importantly, you can’t tell the same story with the same effects from two different mediums.

We have the same constraint in software, though our medium is the architecture by which we build the software. If I say to you “website”, you automatically jump to a certain architecture. If I further say to you, “marketing website”, you narrow further to a specific type of architecture special suited for that. If I say, “data ingestion heavy”, you automatically start thinking of the right architecture — or medium — to make that happen.

But notice the interplay there, the architecture (medium) fits the purpose for the software (story to be told). And when we run into architectural trouble, it’s often not hard to see that the problem is either we didn’t use the right medium for the story, or we decided to tell an entirely different story using the previous medium.

The story and the medium fit together and go together.

Not too much happened last week; but what did happen was rather alarming. Nothing like a Zero-day RCE in Microsoft Office to get your blood pumping. Let’s get to it.

Zero-day vuln in Microsoft Office: ‘Follina’ will work even when macros are disabled This is a wild vulnerability that basically allows code execution even in a situation where you’ve explicitly set up Office to not allow code execution. Microsoft’s response to this has been wishy-washy, by closing the initial report, and then saying, Yea, “msdt executing with macros disabled is an issue” and then opening CVE-2022-30190 for it. This is not a rousing endorsement of when their PR and security practices collide. Oh, and in the intervening time there was an unofficial patch released if you are the daring sort.

Also shockingly, the zero-day was mentioned in a 2020 thesis. 🤯

---

Microsoft is on the cusp releasing ‘classifiers’ that will scan computers for messages that fit into one of several categories: “Leavers”, “Corporate Sabotage”, “Money Laundering”, “Gifts & Entertainment”, and more. Rightfully people bring up the false positive rate. I mean, who wouldn’t accept a $50,000 bribe from me so I can get the new Elder Scrolls before it’s released? 🙀

---

Code Signing is moving to a hardware key that will absolutely make it harder to sign certificates. If you can do your job, the security isn’t strong enough. 📵

---

Amazon SNS for the .NET Developer, Getting Started Quick and Easy Everybody and everything claims to be quick and easy, just once I want someone to lean in to long and hard. Like Python the Hard Way (which by the way is a lie). 🎂

---

Cory Doctorow talks about Apple’s sabotage of “Right to Repair” in a guargantuan twitter thread. In a time of rising inflation, we can ill afford the costs associated with a monopolized repair system. 🛠

---

And lastly, Gen Z is smarter than all of us: Quit Early and Quit Often. If you want employees to be loyal, offer them contracts. Contracts. With Severance. Yea, I said it.

---

Have you heard of sampling? To not get too technical about it, it’s a way to understand how many people prefer a particular thing without asking every person in existence. The idea is, mathematically you can determine how many people you need to sample to achieve a high likelihood of being able to extrapolate their answers across the population you want to know the answer to.

For instance, I could ask “what percent of the population prefers Vanilla over Chocolate ice cream?” And I could sample around 2000 people and get a definitive answer to that question for the USA (statistics folks will note it may not even take that many, but I am a student of statistics, not a practitioner, I leave that to far more capable people than myself).

You may think there’s no way 2000 people are representative of a population of 330,000,000, but depending on how the sample is chosen and depending on the questions and depending on the answer rate, it’s not only possible, but you can answer it with a 2.6% error rate, which is great considering you’d go bankrupt long before polling 330,000,000 people.

But that’s not why I bring it up. I bring it up because if those numbers shock you, and you think that clearly it’d be more accurate to always poll more people, you’d be wrong.

More than that, though, the part that’s interesting is that we do that all the time in software. We take our expertise and try to apply it to things we aren’t experts about. You see it in UX discussions, you see it in design reviews, you see it just about all facets of our work. If you’ve ever claimed SQL is superior to NoSQL or vice versa — without defining the context you’re talking about, you’ve even committed this fallacy.

When we step back and realize we aren’t experts even though we are smart, we allow room for the experts to help guide us. That silence is worth it.

After you’ve mastered how to implement a feature or pattern, and after you’ve mastered to design a module, and after you’ve mastered how to design a system, and after you’ve mastered how to ace KPIs and OKRs, what’s next?

It could be mastering how to communicate with your users, or how to take feedback, or how to prepare for the next downturn, or how to anticipate the market shifting from your current role to whatever it finds valuable, or how to be at peace with the decisions you made.

If you work in software, technology is at the easiest part of the skill tree. All the hard stuff comes from branching out past technology into how using and building technology serves others, and how to serve others the best way you can. Where are you at now, and what’s next for you?

Yesterday’s email about ”What if we paid for Bugs” sparked a lot of questions, comments, and feedback. I’ll post some of it in a future email, but for now I want to hone in on the assumptions and questions behind the question.

If I could sum it up, it would be: ”What do we value in the software we build or use?”

If we value ease-of-use, or stability we tended to have a different reaction to that post than if we were on the build side, where stereotypically there’s an undercurrent of “our software would be perfect if not for those pesky users.”

So for today, i want to ask you: what do you value most out of software you build? software you use? If that causes a difference to what you value, why does it?

Hit reply and share your answers with me, this is a fascinating aspect of our work that I’d love to have your perspective on.

Our customers pay to use the software we make.

But what if we had to pay each customer every time they encountered a frustration or bug? It doesn’t have to be much, let’s say $1 each time, but go with me here. What if you had to pay your customer when your software failed them? What would change about how you build and deploy your software and handle customer service issues?

This idea is fascinating to me because immediately our incentives would change from feature-itis (enticing people to buy our software because LOOK HOW MUCH IT CAN DO, IT CAN EVEN BURP THE BABY) to making software as solid as possible, and it exposes the rift that focusing on more features necessarily means less focus on stability (unless you have unlimited money, people, and time, which no one does, as evidenced by the number of software projects killed by google).

Take this a bit further, and imagine that in our world that that state of affairs has always existed and exists now. What software would be better in this brave new world? What software would be worse?

Let me share with you the audacity… the audacity of programmers. You would assume that being programmers we would have a preference for programming solutions, but — and I’m not so sure this is a good thing — there are times we just… do it manually.

Need to set up a new server? Just copy some files over from the old server.

Need to make a new build process? Just use the UI.

Need to configure an environment? Just remote in and run the commands.

Hopefully at this moment you are recoiling as if to say, “what? We would never do that!” and to you I say… never? Would you never do something related to building or deploying your software manually?

And that answer is a bit more complicated. Because, you see, it’s really flipping easy to just drag a folder from one share to another. It’s easy to right click and say “make new folder”. It’s easy to log into a server and rsync files across with some sort of daemon.

It’s easy to do all these things, and more importantly, it’s even easier to forget that you’ve done them, until one day far in the future, no one knows how the software is configured, only that it works and you shouldn’t change anything because it’s risky.

We choose to ignore that risk in the moment because it’s more expensive to do the thing that reduces the risk than it is to just ignore the risk. But eventually — eventually, we all get bit by avoiding the risk.

You can either hope to outrun that eventuality or do the work now to make sure it never comes to pass.

Build happened, virtually. Again. I did not Livetweet it this year due to reasons like “self care” and “omg how can anyone do a 3 day virtual conference”, but lucky for all of us lots of different people watched parts of it, allowing me to bring you what happened Last Week in .NET.

Did you miss #MSBuild? Jeremy Sinclair live tweeted MSBuild 2022 just for you. Three day virtual conferences are a lot to take in — and infinitely more exhausting than in person conferences. Tweet Storms are the best way to experience them. 🧵

---

David Fowler posts a reddit thread that asks “Why are tools such as Docker and Kubernetes written in Go and not C#”? Because you don’t get cool points for C#. 😎

---

.NET 7 will be launched at .NET Conf, and .NET Conf is November 8-10th, 2022. .NET 7. If this trend keeps up, by 2032 we’ll have .NET 14. I’m getting too old for this. 🎂

---

Unexpectedly HTTPS? A look at where we are on the modern web with HTTPS.

---

@GabbyBilka livestreams writing a Simple Windows App with WinUI for MSBuild.

---

Github releases its final npm report on the stolen OAuth user token problem This security breach still has some unanswered questions for me; but I’m glad for the follow up. Now if Microsoft would ever explain ChaosDB I could sleep again. (I have to assume they’re just hoping it goes away on its own?). OAuth Tokens get stolen, multiple analysis and reports done by Github and NPM (both Microsoft companies). A breach that literally affects all Azure Cosmos DB Clients… Although, thinking about it more, maybe there weren’t any actual Cosmos DB customers and that’s why Microsoft doesn’t feel the need to explain its security process there? 🤓

---

Visual Studio at Microsoft Build 2022. The four biggies are .NET MAUI (Cross platform Desktop Apps — except WASM, if you want WASM go with UnoPlatform), Microsoft Dev Box (which is a cloud service that has ready-to-roll development environments should a Windows Update bork your dev environment — which *never* happens). “That’s a nice windows environment, it would be a shame if anything happened to it… You know for $1.00 an hour we can give you an environment guaranteed to be available if something should happen…” And the third was Azure Deployment Environments which seems like a lower friction Azure Devops aka Team Foundation Server? I’m not really sure. If this is your thing send me a note, and lastly is Visual Studio 2022 will run natively on Arm64 and allow you to build and debug Arm64 applications on Arm based devices. 🙋‍♂️

---

With the explosion of .NET releases, there’s also a lot of .NET SDKs just hanging around. If you want to get rid of them, there’s a .NET Uninstall Tool that will assist. Why this is not just a standard part of the install for .NET, I will never understand. (S/O to everyone that works in an environment where they can’t just randomly install dotnet-tools without the approval of the SysAdmins.💻

---

Khalid Abuhakmeh shares the macOS Envrionment Setup for MAUI Development Use macOS? Want MAUI? This is for you.🏝

---

Chad Fowler & Matthew Shipp release a Jazz album called “Old Stories” I gotta buy this. I learned about Chad Fowler from his book My Job went to India (52 ways to save your job!), and have been following his work ever since. 🎷

---

Have a ghost window? Process Explorer can help and Nick Craver explains how You’ve heard me say it before and I’ll say it again, I’ve learned more random useful tidbits on twitter than I have from google. 👻

---

Mads Torgerson explains C# 11 raw string literals, static virtual members, list patterns, and more at MSBuild 2022. 📹

---

Introducing .NET MAUI – One Codebase, Many Platforms Except WASM.❌

---

Welcome to the new Azure SQL Database local development experience Azure Data Studio is to VS Code what SSMS is to Visual Studio. 👋

---

Microsoft Store grows with the developer community by allowing you to sell ads. Welp.➕

---

Uno Platform 4.3 is out Figma Integration, new Uno Extensions, and Material design 3 and more. 🍾

---

Anthony Mastrean liveteweets his readthrough of the “General Principles of Softare Validation” which is how software for medical devices is regulated. It’s a fascinating read and tweet stream. ⛑

---

Windows Server 2022 now supports WSL2 Linux Distributions Linux on Windows; for enterprises that want server grade servers but have a stakeholder that requires Windows. 🐧

---

A blast from the past; Scott Hanselman reviews the Microsoft Wrist.NET Watch from Fossil (2004). This is the world .NETrs want. ⌚

---

Microsoft’s toxic culture persists despite pledge by CEO Satya Nadella and since it’s on BusinessInsider that’s the sum total of what I know about this article. 🤷‍♀️

---

And that’s it for what happened Last Week in .NET.