Category: Uncategorized

[Last Week in .NET #90] – Optimizing Cryware

Let’s see, ref optimizations, stories about migrating to C#, and… cryware. Let’s get into what happened last week in .NET.

The journey of moving from C++/WinRT to C# in the Microsoft Store The Windows Store is written in C#, and there’s a bit of an interesting story behind the move from C++ and WinRT to C#. The fact that it uses C# is probably the most popular thing about the Windows Store. 🏔

Satya Nadella announces a plan to increase employee pay through merit increases and stock grants, starting September 1st Microsoft wants to pay its employees more so it doesn’t lose them. Good. Now the stock grants at the moment aren’t worth as much as they otherwise might be (but that perception may be affected by the recency bias), but every little bit helps. 💸

Miguel de Icaza tweets a bit of color when referring to a blog post about Flutter, and it’s rather good:

Flutter early on paid a heavy price to render every widget, which both React, Forms/Maui avoided; but in the long term this paid off very nicely.

For a large class of apps, consistency across platforms and ease of development is more important than native controls 🚄

@JaredPar (Jared Parsons, member of the Roslyn compiler team) explains why utf8 string literals require the u8 postfix. I’m grateful this work is being done in the open, I just wish there was a better way annotate that it was UTF-8. A postfix (suffix) keyword seems… un-C#-ish. 🪕

Microsoft has dubbed software that thieves use to target cryptocurrency wallets as cryware and this is the best thing I’ve read all day. 😭

@ThreddyRex shares job openings in a thread about his team at Microsoft, and the thread itself is also worth a read. 🧵

All-In-One Search is Getting Slicker Visual Studio is getting closer to reaching parity with ReSharper with its latest updates. You can use this new search with Visual Studio 2022 Preview 17.2. 🛢

More Jobs open at Microsoft, this time a “Cloud Advocate” position for people with AI, ML, and Data Science backgrounds 🌬

More code samples for #WinUI in the #WindowsStore on #Github are available I’m gonna go out on a limb and say that they’re overdoing the hashtags for ‘engagement’ on the @WindowsDocs twitter account. #ffs #️⃣

Visual Studio 2022 also supports an IEnumerable Visualizer which is pretty amazing. 👓

Microsoft wants your feedback on .NET release labels. Presently, they want to get rid of the Current label. 🗣

Marc Gravell blogs about optimizing ref foreach and ref returns I learn a lot whenever I read Marc’s work and I’m glad to share it with you. 🎁

Microsoft Build is tomorrow, register now! 🏢

Azure SDK Release for May 2022 is out There’s a lot here. 📝

Khalid Abuhakmeh shares tips about setting the right SDK for .NET Important safety tip, Thanks Khalid. 🦺

Accessing AWS Secrets Manager from .NET Lambda Functions, Part 2 – Using Async Code Good stuff from Bryan Hogan. 🥩

Azure Data Studio releases a hotfix to their May 2022 release… Get it while it’s hot? ☕

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

The least believable part of the future depicted in sci-fi…

… is frustration free software.

Ive been enjoying catching up in Star Trek: Picard, and everything is infinitely more believable when the software goes wrong.

I think that’s part of why I like DS9 so much: the computer is seemingly malevolent.

I bring this up because while we all want the cool parts of Star Trek to come true, the one thing we can all do now is to make the software we build frustration free. Transporter technology may be too far advanced, but focusing on how the user uses the software and eliminating frustration is something we can do today.

If you think your software is frustration free, look deeper.

Buy Vs. Build – The Political Aspect

I’ve been involved in quite a few “Buy vs. Build” decisions over the years. Too many, in fact — but I’ll get to that in a second. The decisions have a familiar tenor to them; we more or less make the decision we wanted to make when we raise the question, and we find evidence to support our decision.

I’m joking. But only slightly.

As much as I hate to say it, even if we were to apply the most rigorous objective standard to the Buy vs. Build problem, there’s still the human aspect, dare I say it, the political aspect to the problem.

That political aspect to the decision is probably the most important, because people don’t make decisions based on data, they make decisions based on feelings.

To solve for this wrinkle, it helps to understand people’s backgrounds. If your team doesn’t have a lot of experience with Document DBs, you may find either they are overly apprehensive towards persuing a DocumentDB solution, or they are a little too eager to implement a DocumentDB solution because it would be good for their learning experience. It may even release dopamine for them to learn this new technology.

With all that in mind, here’s what I look at when leading a team that’s making a buy vs. build decision from a political perspective:

  1. Does the team have experience in the domain they want to ‘build’ in?
  2. What are the background of the people on the team? Do they specialize in a particular technology or does their resume have lots of different stacks and technologies in it?
  3. What is the political will for building? For buying?
  4. Do your organization’s OKRs/KPIs optimize for very short term results? Do they even have the understanding of ‘long’ projects? What about organizational impact? Growth? Learning?
  5. How hard is it to procure technology licenses in your organization? How hard is it to start a new project?
  6. What’s the reputational impact on the team in 6 months if we build and it goes south? If we buy and it goes south? 1 year? 3 years?
  7. Is the team that is making the build/buy decision part of the profit center of the company or a cost center?
  8. Are the people making the decision close to the business or far away from it?
  9. Is there an executive sponsor that is pre-disposed to build? to buy? Is that executive sponsor’s position in the organization solid? tenuous?
  10. Is the project that the build/buy decision supports reputationally risky? Is there broad organizational buy-in for the project?
  11. How are costs charged in your organization? Are they charged to the team when you purchase licenses? are they charged to the team when you build an organizational platform?

There are lots more political questions you can ask, and I’d love if you shared yours. Hit reply and let me know.

What goes into a Buy vs. Build vs. Opensource Decision?

When making a build vs. buy decision, there are lots of axes to the decision. I’ll save the political aspect for another time, but here are some of the questions I look to answer when making a build vs. buy decision vs using opensource decision.

  • (Opensource) In 5 years, if the project is abandoned, how will I feel?
  • How will I feel if we spent $500,000 on building this feature vs. $20,000 in licensing costs?
  • How would I Feel if we spent 2000 hours building this feature instead of $20,000 in licensing costs per year?
  • If it’s open source; is there an active community? Who runs it? Is it a “search for a business model” team who will likely change the license?
  • Is it politically easier to buy or build? 
  • Can I justify supporting this piece of software for the next 10 years?
  • Is this piece of software critical to our business domain or ancillary to it?
  • If I build this, what am I not building?  What do we have to give up to build this?

What sort of criteria do you use?

The Bugs We didn’t Know we Needed

For me, the magic of building software is putting it in front of the people it will serve. We don’t always think that way, however. Sometimes there’s a sense of “the users are messing up what I created!” But Software isn’t painted art. Software isn’t something that you complete, give it to the users, and then say, “use it the way I designed it.”


Software is a beautiful act of collaboration on both the programmer’s part and the users’ part. There are lots of examples of this, but here’s just one.

When STARSIEGE: Tribes was under development, there was this massive outdoor world but the only way to get around was vehicles. If the game had gone to market that way, we never would have heard of it. But instead, during development, a wonderful bug came up that forever changed the tenor of the game:

Dave Moore, who was working on collisions and character movement, walked into Youngblood’s office. “[He] said, ‘Hey, I’ve been working on this stuff and I have a bug, but I’m not sure if I want to fix it or not,’” Youngblood recalls.

Moore wouldn’t divulge what the bug was. Instead, he brought Youngblood back to his office and told him how to trigger it. “It was, ‘OK, you’re on top of this hill. Run toward the next hill, and when you get to the top, jump and then just keep jumping as you go all the way down,’” Youngblood says. “And I played with it and was like, ‘Holy crap.’” Pressing the jump button canceled the collision with the landscape, allowing the player to accelerate down slopes and frictionlessly launch into the air, attaining much higher speeds than were possible with the jet pack alone. “[It] was ‘wrong,’ but it actually made the game more fun to play,” Youngblood says. “I looked at him and was like, ‘Nope, don’t fix it. This is now a feature.’”

(source: TheRinger.com)

No one had forseen skiing as a feature; but it became a critical feature of the series, and it started its life as an unintentional consequence of design decisions. A bug.

I’ll leave you with just one thought for today: How would software development change for you if you were to treat it like a beautiful act of collaboration between your team and your users? More like Jazz, less like building a building?

Winning Marathons Before Getting New Shoes

I am a big fan of the Rands Leadership Slack, and I learn something multiple times per day. Today, of course, is no different. Because of the Chatham house Rules, I can’t link to exactly what was said, but I’ll share it with you here.

The conversation itself was around “building trust”. If you build software, you’ve inevitably heard this phrase uttered:

“We need to build trust with <stakeholders> that we <can deliver valuable software> in <timeframe stakeholders wanted it>”.

I’ve heard that (or a variation on the theme) more often than I can count.

Inevitably that comes up when the team wants to focus on ‘Paying down technical debt’, as it did in this conversation today. As developers, we know that technical debt is basically never going to get addressed, and if it does it won’t get addressed in the timeframe to actually be useful to us, and so incurring technical debt may as well be like incurring national debt: We’re never gonna pay it off, so we may as well ignore it.

Anyways, the whole reason I brought this up was a singular quote from this conversation that cleverly encapsulates the problem with the dynamic between ‘building trust by delivering what we want when we want it’ and ‘paying down technical debt’:

“We need you to start winning marathons before we buy you new shoes.”

💋👌

[Last Week in .NET #89] – CVE Inflation

A few CVEs patched, a book written on Regex. It’s an eventful week, let’s dive in.

.NET 7.0.0 Preview 4 is out. Looks like bug fixes here, nothing major. 🐛

.NET 6.0.5 has been released which fixes three CVEs (all denial of service) and quite a few bugfixes. 🚨

.NET 5.0.17 has been released and it fixes those same three CVEs. 🚨

.NET Core 3.1.25 has been released and you guessed it, it fixes those same three CVEs. 🚨

That’s it on the release side, here’s what else happened Last Week in .NET:

Khalid Abuhakmeh shares a tip on how to use the Convert class to convert a number into its binary representation. After working in embedded C this is one of those things that I’ll never take for granted again. 🏗

Microsoft launches [paid] cybersecurity services to help clients fight off ransomware and other attacks.

  1. Build an insecure OS.
  2. Charge people to make it more secure.
  3. Profit.

Even if this is all above board, it sure looks twisted. 🟡

Speaking of security vulnerabilities, CVE-2022-1388 is an F5 (network equipment) vulnerability, particularly against their REST APIs. Yes, some network devices support REST API access to the control plane. It’s a wild world that I used to work in, and not without its share of problems. 🚨

WSL now supports USB devices. Ouch. Microsoft makes a better linux than linux makes. 👉👈

Microsoft has a knowledgebase of styles of architecture for Azure. This is nice. More, please. 😊

Shiny.NET 2.5.1 is out. What’s Shiny.NET you ask? I really have no idea. The twitter account description says,

“Make all your apps shiny with http://Shiny.NET -github.com/shinyorg/ – please don’t @ for support – go to github!”,

and the Github description says,

“We make shiny nuget packages for Xamarin, Windows, & All Things .NET”. Again, no idea.

If I go into the ‘shiny’ repository, it says,

“Shiny is a cross platform framework designed for Xamarin & UWP to make working with device services and background processes easy, testable, and consistent while bringing things like dependency injection & logging in a structured way to your code!”

…and that took long enough that I need a nap. 🤷‍♀️

I’ve touted Polly quite a few times here and elsewhere, and the .NET on AWS folks release a blog post series about it. With modern software, polly is a requirement. 🍾

Visual Studio 2022 17.2 is available and it includes support for C# 11’s “raw string literals”, and they’re making the Razor editor better (thank heavens!). There are a lot more goodies in the release, so give it a look-see.

And the team that works on Visual Studio 2022 version 17.3 Preview 1 also released their latest update last week. Lots of little fixes here, and if you like Preview bits, have at it. 🍾

Using the new .NET threading API sped up a benchmark by 4x. That’s… a lot. I always thought .NET [Framework] was pretty fast, but to learn how much faster .NET [Core] is astonishes me. 🚄

Redefining the term 10x Developer The real 10x developers are the compilers we met along the way. 👋

A shockingly deep dive on Regex Improvements in .NET 7 It’s a 30 minute read from this point, and worth every minute. 📚

And that’s it for what happened Last Week in .NET. If you find something you think I’ll like, email me at george at georgestocker dot com or send me a tweet @ gortok on twitter.

If your software is for everyone, it’s for no one

The first thing you can do when building software is defining who the software is for and why they’re using the software.

And please don’t say “My software is for everyone.” It’s not. I mean, you can make that an explicit goal, and suffer the consequences of that approach, but for the sake of your livelihood, please don’t. I actually can’t think of a single piece of software I’ve ever used that it’s for everyone. Don’t believe me? Even as broad as Operating Systems can’t be for everyone. As a case-in-point; iOS 13+ requires some sort of passcode to access the device. It’s important to note that even 5 years ago, passcodes weren’t ‘required’. There are entire generations of people who have never had a passcode, and at their age these days, are probably too advanced to remember what their passcode is. This happened to a friend of mine just last week. Their mother had been given an iPhone and had to set a passcode, and subsequently forgot that passcode. Their only option was to have the phone reset, losing everything on it.

It’s very clear that even for something as ubiquitous as a smartphone, it’s not for everyone, and we do a disservice to our users when we think it is.

Choosing who you are serving with your software allows you to set the appropriate expectations for what it will and won’t do, and allows you and your team to focus on making it the best possible experience for the people you’re trying to serve. Making software that tries to serve everyone makes software that is just frustrating enough for anyone, and is truly exceptional for no one.

Context-Sensitive Practices

I think quite a bit about “Best Practices”. Partly it’s me reacting to the aversion I have for that phrase, best practices, and partly it’s me trying to figure out a better way to say what we mean when we say “Best practices”.

What are we trying to convey when we say “Best Practices” anyway?

At least part of the time (though I suspect more of the time than we care to admit) we use that phrase as a way to shut down dissension or as an ‘appeal to authority’. I don’t think it’s done maliciously; but there is an element of ourselves that gets tied to a course of action, and even if it may objectively be wrong for our context, the ego is the ego, and the appeal to authority, well… feels good. It almost feels righteous.

Another part of the time it’s as a protection in case something goes wrong. If we’re doing it, and other people do it, it can’t be wrong, right? We can’t be held responsible for doing what is considered a ‘best practice’.

And for some situations, a context free ‘best practice’, may actually be a best practice and we use the term because the stars happen to line up and it’s an actual best practice.

I think this is far less common in practice than we judge it to be.

Too much of what we do when we build software is context-sensitive, that is, the particular circumstances and facts surrounding the why and the what are as important (if not more so) than the “typical” means we employ to build software.

Or put another way, we have far fewer immutable laws when building software than when engineers are designing and building roads or bridges. Gravity or inertia will not suddenly change on the bridge engineers, but our circumstances — our context can change on a dime.

I don’t know how far this thought extends, but I like to think that when I’m designing software, the context I’m designing on is front and center. It is the most important part, because it’ll define the rules by which we operate. So instead of using best practices, I use context-sensitive practices. Maybe that’ll keep my hubris at bay?