What if We Paid for Bugs?

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?

Manual? … MANUAL??

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.

[Last Week in .NET #91] – Ctrl+Shift+B

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.

Development Methodologies that Don’t Exist But Could

We have Scrum, Kanban, Waterfall, Scrumfall, and so many more, but there are lots of methodologies we haven’t intentionally created that could (or do) exist.

  • Single Threaded Programming: We Work on One Thing At a Time
  • Deadline Driven Programming: I need X by This Deadline. Do it.
  • Budget Driven Programming: We have $100,000. What can we get for that?
  • User Driven Programming: I think our Users want X. What will it take?
  • Command and Control Driven Programming: I as the main stakeholder want to feel in control. Don’t surprise me. Ever.
  • Politics Driven Programming: I want our internal organization to feel good about what we do all the time. Make them happy.
  • Resume Driven Programming: We want increase recruiting by making a name for ourselves on Hacker News, Pick the technology choices that will do that.
  • Multi-Threaded Programming: We work on whatever any stakeholder wants, whenever they want it (Pairs nicely with 100% capacity programming)
  • 100% Capacity Programming: Our Developers should be working on stories 100% of the time.
  • Firefighting Driven Programming: We work on the issue that’s on fire.
  • Perfection Driven Programming: We rewrite anything that’s older than six months.
  • Tech-Stack Driven Programming: we rewrite things into new tech stacks when they come out (pairs nicely with Resume Driven Programming)
  • Esoteric Driven Programming: Only Esoteric programming stacks can possibly handle our problem.
  • Reverse Conway’s Law Driven Programming: we want to change the structure of our organization by changing how our software is architected
  • Time and Materials Driven Programming also known as “Agency Project work”: you got the money, we have the time and materials. The project is finished when you’re done spending money or we convince you to support another project, whichever comes first.

Is this what Building Software is *supposed* to look like?

There’s a discussion going on The Orange Site about a developer’s Computer Scientist friend who recently tried to use a programming module they found on Github . Ostensibly they were trying to do something anyone might do today, they found a package that fit their needs and tried to figure out what they’d need to do to run it.

I’ve read the comments so you don’t have to, and the discussion centers around the idea that “oh well this is just how things are and if you’re a programmer you should just shut up and deal with it”.

I can’t begin to describe how bad that outlook is for us and our profession, and even more importantly, how that outlook hurts building better software — software that people love to use. Software they find joy in. Software that has a soul.

The empathy needed to understand why your users are using your software, and what they’re trying to do with it is the empathy that makes building good software possible. Without that empathy — without that sense of “putting ourselves in the user’s shoes”, we’re never going to be able to make software that truly changes our user’s lives for the better.

But the preachy stuff aside; what can we take from this? What can we do?

Look at every bit of development tooling you use. What is a joy to use, and what is a pain? If it’s a pain to use, what would it take to make it a better experience for you? As an example, I’ve gone back to powershell, and was trying to get information about a command, and so I tried:

<command-name> help
<command-name> /?
<command-name> --help

And none worked.

Why not? /? and –help have both been methods for getting help for decades — why wouldn’t powershell adopt them? Instead, I have to do:

 Get-Help <command-Name>

Further, why not tell me when I load a Powershell Shell how to get help for commands? Right now all I see is this:

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6 

PS C:\Users\George> 

Microsoft is advertising something new to me — but not telling me how to use the software that I’m looking at!

Wouldn’t a better experience for me (and a reason for me to look at PSCore6) be to give me a good experience for what I’m already using?

What would it take for this experience to be better? How about this?

Windows PowerShell 
Copyright (C) Microsoft Corporation. All rights reserved. 

To get a list of commands available, type Get-Command.
To get help for commands, type Get-Help <command-name>.

Something not working how you expect? 
Visit https://aka.ms/ps-help in your web browser to get help.

PS C:\Users\George> 

It doesn’t take much to improve your users’s experience with your software, and it starts with empathy.

Priorities is a bad word.

If you believe in the theory of constraints, then you know that you can only get as much done as you can have flow through your system at once.

What is your system? It’s the entire development process from idea to in your customer’s hands. It’s the people, processes, and tools that are part of this process. It’s influenced by the contexts present in your system. It’s the physical, emotional, and mental aspects of the work you do and the people who are a part of the software development process.

Now, back to this idea of flow. It’s not perfect, but for teams that struggle with getting valuable software into the hands of their users, flow can get you a long way. Basically the idea is that the faster you can get value into the hands of your users, the better (I’m assuming you’ve already determined that what you’re making is valuable to your users).

If you imagine a running faucet in a tub (the input), the water filling in the tub, and the drain (output), you know that you can’t just turn on the faucet and expect water to leave the tub at the same rate it’s going in. That difference is excess waste. Since you can’t just turn the faucet on all the way and expect water to flow out of the tub as fast as it flows in, you may as well turn the faucet down to what can make it out of the tub as fast as it goes in (Special Thanks to Donella Meadows work “Systems Thinking” for this analogy).

Guess, what, your development process has the same constraint, and the chief way you turn that faucet too high is by having priorities. Not priority singular, but priorities, plural. When you have more than one priority, you’re trying to fill your bathtub too full and expecting water to still flow out at the maximum rate it flows in. That doesn’t work.

Instead, by lowering your rate of flow to what can go through your system without backing up, by focusing on a single priority, you can get value to your users without delay, and without gumming up the works.

Two Questions

I’m a big fan of questions that are context-revealing. Context, as you’ve probably heard me say before, is probably the most important non-matter matter in software development. It’s sort of like air in that way. You can’t point to ‘air’; it’s just all around us. Context is the same way. Sure we have requirements, deadlines, and budgets, and those are all substantive, but we also have the context behind the requirements, the deadlines, and the budgets, and that context shaped those things without really being contained in those things.

I’ll probably talk more about that in future writings, but currently I just want to focus on two context revealing questions I use — and these aren’t original to me, I learned about them from Seth Godin’s work, and it’s something I understand Carl Richards uses as well.

  1. Who is this for?
  2. What does it do?

This is a question that can be used with people, process, or tools; and it can be used in the large sense and the small sense.

For instance, “Who is the process of sending a weekly report of our velocity for?” and “What does this report of our velocity do for them?” are both context-revealing questions about something that’s a microcosm of software development.

Likewise, asking “Who is this staging environment for?” and “What do they do with it?” reveals context about a bigger question.

It’s almost like asking why, without the amygdala hijacking that asking “why?” can have.

[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.