Author: geostock

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.

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.

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.

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.

I encountered this tweet this morning, and I think it’s best to share without comment (for today):

IBM slide, 1979 .. pic.twitter.com/OFF9M3IZ7i

— mr.w0bb1t 🌐 (@_w0bb1t_) January 20, 2022

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.

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

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.

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?

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?