"We don't write design docs, we write code"

If you "don't write design docs, [but you] write code", then:

How do you know what the code is supposed to do and if it does the right thing?

AI can't tell you why the code was written

I recently heard of a new "AI" based tool for developers that can explain both what a piece of code does and why.

The claim about "why" can easily sound appealing, but it is very open to misinterpretation.

It may be possible for the tool to explain why the code works, but it can't explain why the code exists.

It can't say why this code is the best way to solve the problem it exists to address or what the person using the software is trying to achieve.

It's necessary to know more than just the code to understand why software exists and what it does for the people who use it.

I know developers (and many companies) don't want to hear it, but it's necessary to record (document) more than just the code.

All software is change

The cliché says that there are only two certainties in life: death and taxes. 

There's a third: Change. 

It will happen. You can't stop it.

Change is anything new or different. This is core to what a software developer does. A new product, a new feature, and even a bug fix, will all involve changes for the person using the software.

Software developers are also well known for wanting to use the latest product, the newest framework, or the toolset currently being hyped on social media. All these new things will involve changes in what they do and how they do it.

Resistance to change is a natural response amongst most people. Or, to be more precise, unwanted change is resisted by most people. A positive change without the need for a lot of effort or disruption is normally welcomed.

When something changes, you may have to learn how to use the new version. There may be a negative consequence due to the time taken to learn the differences, but these will hopefully be outweighed by the benefits the change provides.

Very little software is written once, used, and then discarded. It's far more common for software to be developed over a period of time and for changes to be made to it once people start using it.

If you're involved in creating software, getting used to, and accepting, change is something that will benefit you in your career.

"There was no runtime pack for Microsoft.NETCore.App available for the specified RuntimeIdentifier 'iossimulator-x64'" - Keep your file and folder names alphanumeric

As part of the testing I do for the MAUI App Accelerator, I have checks that valid (but unexpected) file names won't break anything in the extension.

I probably (based on the things I find) do more testing in this area that the MAUI team.

For example, I just found that you can no longer include an  underscore, at sign, or brackets (opening or closing) in the file paths of any files in you .NET MAUI projects.

Previously these characters weren't an issue.

If you want to know more, there's now a bug about this on the MAUI repo.

However, I expect that none of that is very relevant to you.

So, why did I write this blog post?

Simple, to recommend and encourage you to avoid such issues by keeping you file and directory names simple and only using alpha-numeric characters. (and maybe a dot/period. 😉)

I do the testing that found the change in behavior, not for the sake of discovering weird, outlying bugs, but because I want to avoid anyone using my extension to encounter such a bug and then raise reports that I need to spend a lot of time investigating. Ok, so I may have just spent a lot of time investigating something that no one will encounter (to create the bug report), but at least it didn't mean that a bug was raised on my project when I had no time to investigate. Also, at least to my mind, I'm focusing the limited time I have to support my open source projects on making sure they're robust. If you appreciate such projects and want to help me develop them more, please consider joining the other people who have sponsored me previously.

Open Source Software and "the Church of England's problem"

No, this isn't a religious post.

I was listening to an interview regarding marketing challenges for big brands trying to reinvent themselves. The context was large, older brands that people don't want to go away but whose products they aren't going to buy (any more).

A comparison was made with the Church of England. (It was a very English discussion.) The speakers  said:

• They wanted it to keep existing.
• They weren't going to go.
• And, they certainly weren't going to pay for it.

I immediately saw a comparison with Open Source Software:

• People want it to exist (and be maintained/updated)
• (Most) people are unlikely to participate. (Beyond using it.)
• And, they certainly weren't going to pay for it.

The challenges facing the CofE and OSS have similarities, but I think the solutions each will seek are very different.

That's all, except to say that the impact on anything is highly likely to be the same when people want something but aren't willing to pay or participate.