Why developers should be excited about implementing migrations

I often hear that developers aren't keen on doing work to upgrade the frameworks/platforms/tools that they use (or the software they're building is using). It's not writing code, and so it's not considered "real development" work.

I think that doing the work to support upgrades or migrations is one of the most important and valuable things a developer can do:

• It's often a simple way to fix potential security vulnerabilities.
• It normally brings performance improvements.
• Updates bring new capabilities and options for things to add to the software.
• Keeping up with the latest versions makes future updates/migrations easier.
• It can help you learn and get hands-on experience with the latest technologies.
• It can allow you to see a large part of or various/obscure parts of the code base, helping you to learn more about the code you're working on.
• It can make it easier for other developers in the team.

So, a high-impact task that helps you learn while supporting the team by doing things they don't want to do? Sounds like a great thing to prioritise if you get the chance.

How quickly can a Windows application launch?

Following on from my recent post asking How much does start-up time matter when choosing a framework? I've now published some figures and the code I used.

With some minor tweaks, I now have an updated graph of the data:

This graph is based on the release builds of the simplest, most minimal apps I could reasonably come up with that were as close to identical in all frameworks.

The code and more details can be found at https://github.com/mrlacey/WinAppLaunchCompare

From that repo:

Miscellaneous observations:

• As expected, WinForms was super fast.
• WPF (both .NET and Framework versions) was surprisingly (disappointingly) slow.
• The difference between MAUI and WinUI is surprising given MAUI uses WinUI to create the Windows version of apps. I expected these to be closer.
• Of the cross-platform options (and WinUI) the difference is basically irrelevant. Having clicked the button to launch the apps many, many times, I didn't perceive any real difference, never feeling that one was slow or faster than the others.

My takeaways:

• For choosing a cross-platform framework, there's hardly anything in it in terms of the time it takes to launch the apps.
• I wouldn't base a decision to use a particular framework based on these (or similar) tests/results.
• I also looked at the time until the App class was loaded. This varied but didn't seem to be related to the overall time taken.
• Performing tests like these can easily become an infinite rabbit hole. There are always potential tweaks and optimizations that could be done. If you have such an interest, please go ahead.

Feel free to experiment with this code as you wish and suggest any ways it could be improved or anything artificially slowing down a version of an app can be addressed.

What makes a good teacher of technology?

I guess it comes down to different people wanting different things. Or, maybe, I'm looking for different things than the majority of people are looking for.

Being aware that I'm trying to learn a variety of new technologies at the moment, and also writing things to try and find a new way of teaching something I'm very familiar with.

Here's what I've seen a lot lately:

Teachers (either qualified educational professionals or people whose job it is to teach and are recognised as experts at teaching new technology) will explain that there are different options or ways of doing things, and then say, "I always use X, so you should too."

Is it that the people learning are just looking for a seemingly authoritative answer, and so are happy to use/do X because they've been told that's ok?

Or, is it that explaining the nuanced differences between options and where/why/how you'd use each and what each is intended/best for is much more difficult and so people don't (or can't) try?

Or a combination of the two?

I find it a bit like being told, "There are lots of potential tools in the toolbox, but I always use a hammer, so you should just use a hammer."

Simple answers are attractive, but don't provide the knowledge to know how to use something other than a hammer or even tell when using a hammer is not appropriate.

I want that deeper knowledge.

Maybe others are happy with a simple solution. When their hammer stops working or can't be used, they'll come back with questions about alternatives. 

I prefer to know in advance if I'm going to be using the wrong tool or what the potential negative consequences of what I'm planning will be.

I want all the learning up front. If you're selling education (or views), then holding back some of the knowledge until later has a benefit for you. But, who is the lesson for?

what "everyone" gets wrong about "write once run everywhere"

It was never meant to be about the ability to write a single app that runs on any/all devices.

It is about the ability to use the skills/tools/technologies to build software that can run on multiple operating systems, devices, hardware, etc.

There are a very small number of scenarios where you want the exact same code running on every imaginable device. Even when you do want this, there needs to be logic within the software to account for the differences:

• Different input devices (not just touch, mouse, & keyboards)
• Different output devices (not just size of screen, or none)
• Different sensors or physical capabilities
• Different usage scenarios
• Different connectivity or storage capabilities
• Different user permissions or account settings

There's the dream scenario where you build a piece of software for a specific OS and/or device type, but then decide it would be nice if it ran somewhere else too, and you hope that tooling can magically make it happen for you.

Sometimes this works. To a point. But you'll almost always want some customisation or need to handle different scenarios or capabilities the new device(s) present.

What's useful is: when you know you need to build software that needs to run in lots of different places/ways, you can benefit from not needing to learn/support/maintain different technologies to build all that software. 

It's not just about the reuse of code once written, it's also about the reuse of skills.

How much does start-up time matter when choosing a framework?

I got nerd-sniped.

I was asked about measuring and possibly benchmarking different .NET frameworks for making native apps in terms of performance.

Apparently, this is an important factor for some people when choosing a framework.

I think I know better. I know you can write very bad (hence slow) code in any language or with any framework. I also know there are almost infinite things you can do to make code faster.

A basic comparison didn't seem very useful. I knew that if I saw such a thing, I wouldn't care very much, as it all comes down to optimising appropriately in a real app, given the constraints and requirements of/for that particular app.

I tried to find a way to get excited about the prospect, but couldn't see what could be exciting.

However, two questions persisted:

1. Do other people care?
2. How much difference is there?

It's hard to know if other people care, but is there a significant difference?

Time for a quick experiment...

Doing the simplest and quickest thing I could, I did a quick test to see how long it takes to launch a trivially simple app and for it to report that it has finished loading.

Here are the initial results:

The Windows Forms perf was to be expected and was included as a reference for the others.

Why is there so much difference?

Is this interesting?

Do you care?

Should I go deeper in investigating more realistic scenarios and considering simple optimizations (like AOT)?

Let me know if you want to know more.