Is second-order enshittification a thing?

 
Enshittifcation, as a term popularized by Cory Doctrow, has for many become a catch-all term for things generally getting worse. I've found it useful (unsurprising if you know me) to think about it in two categories.
There's the popular definition of how very large, dominant platforms change [to get worse] over time as business/organizational priorities change.

I think there's a second-order version of this that follows as a response.

I'd sum it up like this:

"If [big company] doesn't have to focus on quality, we can cut corners there too."

What happens when "everyone" takes this approach is that things get continually worse. Not all at once and not always in the immediately obvious ways. More in the million paper cuts way.

From a software perspective, it's the increasing number of small bugs that no one seems to care about fixing. This teaches people to not bother reporting them. After all, "what's the point? They're not going to fix it even if I [you] do report it."

With fewer known or reported bugs, the company thinks everything is fine, or worse still, thinks skipping on quality is an approach that works.

And a self-reinforcing cycle continues.

I prefer to think of it another way.

Software exists to help people and to make their lives "better". This could be in one or in many ways.

When people are constantly being interrupted, frustrated, and disappointed by the software they use, it's very hard to argue that it is making them better, happier, or more productive.

This is part of the reason I think that QA, customer service, and fixing bugs are among the most important things that those in software development can focus on.

With AI making copying software easier, it's focusing on how it relates to people that can be the real differentiator. 

Yes, AI may mean you can vibe code a copy of something that exists, but does it include support for all the non-obvious edge cases? Do you even know all the features that exist in what's being copied? How (and?) will you handle any bug reports?

Yes, building software can be fun for you, but high-quality software that works reliably benefits many more people and, in a small way at least, makes the world a better place.

And this can also lead to mediocrity

A small company tries to compete with a large one. They try to do everything because that's what the large company (or their software) does. They try hard, but as they're stretching themselves so thin, everything suffers. "Never mind", they say, "at least we're trying our best." But, for what? Who benefits? The company's staff exhaust themselves producing a mediocre product, and it's no better than the alternatives.
Trying to compete with a large company and basing goals on the perceived [low] standards of another company doesn't produce a great product, happy customers, or happy staff.

_This was written many months before posting--to avoid anyone thinking I'm responding to a single person, company or incident_

It's probably not an MVP

It's common for people to refer to early versions of software as MVPs (Minimum Viable Products).

Only, that's not what an MVP is meant to be.

People say: 

"ship it early"
"try something out"
"get feedback"
"don't worry about polish"
and "you should be embarrassed about these versions"

But these aren't descriptions of an MVP; they're descriptions of a prototype, and the two are not the same.

A prototype is an early, experimental version intended for getting feedback.

You'll probably use multiple prototypes (or versions of them) until you find an MVP, or confirm that the prototype isn't going to make an MVP.

People tend to focus on the "Minimal" part of the MVP and forget about the rest. If it's not a "Viable Product", then it's not an MVP.

It's not an MVP if there aren't enough people willing to pay for and use it as it is for it to be a sustainable product/business.

Then, once you've proven you've done enough to make it a viable product, then you can add polish, more features, focus on performance or scalability, promote widely, etc.

It's not an MVP if:

• It's a free beta version
• It's only being tested internally
• It includes more features/functionality than are absolutely necessary
• You only demonstrate it privately
• Your only feedback is from influencers seeing a private preview
• People aren't paying for it (or you're not monetising it in other ways)

Of course, there will be some who read this (and probably don't get this far) who will claim that they use the term MVP to mean a prototype. If everyone using the term understands it the same way, then this may not be an issue. But if you start using terms beyond how they were originally defined or intended and you haven't verified that everyone you're communicating with understands this the same way, then there can be confusion, which can lead to wasted time/effort and broken assumptions.

Miscellaneous AI-related questions

No answers. "Just", questions I'm aware of and considering:

• If working with AI means communicating with machines more like we do with other humans, how do we avoid things also going back the other way and treating people more like machines?
• Are "agents the future of [all] work"? And, if not all, how to identify the work that can change or be replaced?
• If "AI is only as good as your data", why isn't there as much effort being put into ensuring the quality and accuracy of the data as there is hype about AI?
• At what point does AI not need human oversight? All the education highlights human oversight, but the futurists don't include it...
• What is in the middle-ground between traditional GUIs and "just" a text box?
• As feedback is highlighted as being essential when developing tools with AI, is there a way for feedback from a tool to be passed back to those creating the underlying models?
• If there's a GUI for something, does it automatically need (and benefit?) from having an equivalent interface that's accessible via command line, API, and Agent/MCP?
• As speed/rate of change is a common complaint among all types of people and people doing disparate tasks, how do you factor this in when introducing AI-powered tools?
• If people are generally reluctant to read instructions, why will they happily read the text-based response from an AI tool telling them how to do something?
• Asking good questions is hard. How people ask questions of AI-powered tools greatly impacts the quality of results. In training people to use AI, are they also being taught to ask good questions?

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.

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.

Maybe don't think of MCP servers as an alternative to your API

Yesterday, I posted on LinkedIn about how I created an MCP server to return details from an experimental XAML analysis tool.

I've since been experimenting with it a bit more.

Without my tool, initially, Copilot told me that the file I was using for testing was great. (Sadly, I didn't get a screenshot of that.) But after running my tool a few times and then asking Copilot the same question without my MCP server, it started to suggest the possibility of improvements.

With a bit more pushing, it even started to be able to suggest things comparable to what my tool was providing:

The formatting it applied was even better than my simple string output.

But then I started asking about other files and it went back to giving generic feedback.

This whole experience has made me think about MCP servers in a new way.

If I have a tool or API that performs some specific task then I'll call that directly. Why further complicate things by getting an agent/AI/LLM involved?

If I have an API or tool that provides some data or information that it might be appropriate for the agent to use, then that might be appropriate as an MCP server (or other tool that an agent/AI) can use.

If I'm using an agent it might be appropriate to say "run this tool and make changes based on what it returns." In doing this the actions of the agent may not always be the same. Such is the nature of a non-deterministic system like an LLM based AI. Adjusting to the change from highly-deterministic systems to those that include a level of random variation may just be the hardest part of understanding "AI-based" computing.

If I know I want consistent results that are always presented/formatted the same way and don't have any random variations then I'll use a specific tool directly. If I want to make additional information available to the agent, or allow it to trigger external tasks, then an MCP server is highly appropriate.

I suspect this has some parallels with some businesses that are threatened by an Agent with an MCP wrapper to an API making them redundant. If all you're doing is providing data then where's the business? If you're creating/collating/gathering the data then that could be useful. If you're value comes from analysing or formatting data then AI could become a threat when it can do that analysis or formatting itself....

When a one second saving was worth £10K each day

While looking for a new job, I've been thinking about how I quantify the work I've done previously. It reminds me of the time we worked out how a small performance improvement was worth approximately ten thousand pounds (Sterling/GBP) to the company on each day of operation. Six days a week times 52 weeks a year, that's over £3 million per year!

I was working for a courier/delivery company and was responsible (among other things) for the software used to scan parcels in the depots and by drivers when making deliveries. First thing in the morning was a very busy time, and lots of parcels needed to be scanned and loaded onto many vehicles, which often required delivery far-away or on tight deadlines. Time was definitely an essential factor. Saving time taken during this process would:

• Allow more time for time-sensitive deliveries
• Reduce the number of late deliveries
• Allow for increased capacity
• Reduce stress among people loading vehicles and drivers with tight deadlines

We (obviously) wanted to save any time we could.
Through a combination of changes to multiple pieces of software involved in the process (preparing the list of deliveries for each route, the scanning software, and the software used by controllers to organise and dispatch routes/drivers), it resulted in time savings equivalent to one second per parcel. 

One second per parcel might not sound like a lot, but there were a lot of deliveries being made each day. In addition to potentially saving time, that one second per parcel was, on average, enough to enable the addition of one extra delivery to each route each day.
Based on the number of routes and the average price of a delivery, that amounted to approximately ten thousand pounds. Per day. Definitely a successful project.

The monetary value is a notable figure, but no, I didn't see any of that or even get a bonus. My reward was knowing I'd done my job well and improved things for the people using the software I was responsible for.
I enjoyed the satisfaction of solving a complex technical problem (how to make the process take less time) that also contributed to a positive benefit for the people using the software.
More than simply being able to put a financial figure on the result of a change, I was able to use my broader knowledge of the company and its processes and also learn more about it during the project.

19 Questions to ask before migrating a Xamarin app to .NET MAUI

I got asked about helping rewrite a "legacy Xamarin-based mobile app to .NET MAUI". They'd already determined how long it would take, but had very few details about the app or the rewrite/migration.

To help anyone else in a similar situation, here are a few questions to ask (and get answered) to determine how much time/effort will be required in such a project.

1. What's driving the rewrite?
2. What's driving the time scale for the rewrite?
3. When was the code written initially?
4. Who has been maintaining and updating the app since it was originally written?
5. What does the existing app do?
6. How is the existing app built?
7. How is the existing app distributed?
8. How is the existing app tested?
9. Does the initial code base use Xamarin.Forms or Xamarin Native?
10. Which platforms (operating systems) does the existing app run on?
11. Does the application have any specific customisation or variation in functionality when running on different devices or operating systems?
12. What programming languages does the existing app use?
13. How large is the existing app?
14. What 3rd party controls or tools does the existing app use?
15. How are 3rd party tools licensed?
16. Do the 3rd party tools have equivalent support for .NET MAUI?
17. What external systems (including back-ends, analytics, etc.) does the existing app connect to?
18. Beyond getting the app to build and run with .NET MAUI, what other changes are planned and/or needed?
19. What are the long-term plans for the app? (Who's going to maintain and update it after this rewrite?)

Obviously, the answers to many of these questions will prompt follow-ups to identify relevant specifics.

What did I miss?

Three types of technical debt

Let's compare technical debt and real-world financial debt. (Aren't I "fun"?)

TL;DR:  Many developers are creating future problems for themselves because they're not thinking about the consequences of their actions. For some languages and technologies, the examples aren't great and don't teach everything that's needed to avoid future problems.

I'm going to consider three broad categories.

1. Credit card - make a deliberate choice to put something off (paying for an item/service) knowing that will have to come back to it (& pay) later, possibly with some interest.

Having a little of this is normally not a problem.

2. Loan shark - No other options when you have to do something now. It's solving a short-term problem but likely creating a bigger and more expensive one for the future.

Avoid as far as possible. (If you're in real financial debt, please talk to someone--don't struggle alone.)

3. Financially illiterate - No one ever taught you about money or saving. You spend money without thought, have multiple store and credit cards, have little or no savings, and live "pay-check to pay-check".

"This must be fine", or so you think. "Doesn't everyone live like this?" "I'm sure it will all work out in the end--somehow."

Hopefully, the comparisons are clear.

What the term "illiterate" might hide is that this isn't always the developer's fault. 

Some languages/technologies/frameworks are taught in only the most basic ways. The student is shown how to get started or do the basics, but the instructions never go beyond that.
Even examples and so-called "best practices" don't help. "Expert" code looks like beginner code, and not in a good way.

Everyone makes the same mistakes, builds up a code base with the same issues, and talks about the code/language/framework with the same complaints.
Eventually, the problem becomes clear, and someone suggests a rewrite with a different technology.

It sounds like declaring financial bankruptcy, and that future financial problems will be avoided by only trading in cash/gold/crypto. 

Is it the technology/medium that's the problem? Or is it how it's used?

If you're learning, are you learning how to do something without creating future problems for yourself?

If you're teaching, are you setting up your students for long-term success?

If you're creating a language/technology/framework, are you doing so in a way that encourages doing things in ways that avoid long-term problems?

Choosing a framework to build a native app on Windows with .NET

By "Native," I mean not using web technologies, either as a remotely hosted website or bundled into a package that is installed and runs locally.

Let's get this out of the way first. 

There is no "best". 

There is only best for your current circumstances and requirements at the current time.

That said, how do you decide what might be best for your circumstance?

Each option has slightly different capabilities. It's essential that you know what capabilities you'll need before you start building. If you don't know what you need to build, it's impossible to say which is best for you. This may make the decision for you. 
Doing the work in advance to fully understand the requirements can save a lot of frustration and wasted time and effort if you discover you need something the framework can't do. 

So, second disclaimer out of the way, how do you decide which .NET framework to evaluate first? 

If the first thing you evaluate does all you need, it's probably fine to go with that. If not, try another.

Q1. Do you think you might ever need to run on more than just Windows?

If Yes - go to Q2.

If No, go to Q4.

Q2. Do you want the software to also run on the web?

If Yes - Evaluate UNO Platform first.

If No - go to Q3.

Q3. Are you primarily interested in building an app that runs on desktop, or on mobile devices?

If Desktop - Evaluate Avalonia first.

If Mobile - Evaluate .NET MAUI first.

Q4. Do you already have any existing apps built with WinForms, WPF, UWP, or WinUI?

If Yes - continue using that. (Unless it's UWP, then go to Q7.)

If No - go to Q5. 

Q5. Are you building a "traditional line-of-business" app or something that could be described as "forms over data"?

If Yes - go to Q6.

If No - go to Q7.

Q6. Are you happy to use/learn XAML?

If Yes - evaluate WPF first.

In No - evaluate WinForms first.

Q7. Do you need to support XBox devices, game pad controls, or ink-based input?

If Yes - evaluate UWP first.

If No - evaluate WinUI first.

Happy evaluating!

Yes:

• The above is probably an oversimplification.
• There may be many situations where you don't go with the first suggested option above.
• It doesn't consider personal preference. But if you already have a preference, you should probably use that. (Assuming it can do all you need).
• I haven't considered support for different programming languages. (But you're almost certainly using C#).

This isn't intended to be a definitive guide. Without knowing your exact requirements, existing skills, and preferences, I can't say for sure. 

I just wanted to share some simple questions that others have found helpful when overwhelmed by the options available.

Also: Joe made the above into a flow chart.

I am not a futurist

10+ years ago, I thought the future of app complexity could be solved by having text- and therefore also speech-based interfaces. I built a concept of an app that used this as a way of interacting with multiple social networks and news sites.

5 years ago, I thought the vast array of partially overlapping functionality in the multitude of apps could be addressed by having apps that offered extensibility points to allow different apps to provide specific functionality that was all consumed from one (or a few) place(s).

I couldn't persuade people that a text-based interface as the primary way of interacting with complex apps was the future. Nor were they convinced that my prototype could scale to more complex and varied input.

Rather than offer extensibility, app developers wanted to "own it all" and do everything themselves. The dream of controlling (& therefore monetising) everything was too appealing.

Now we're told that "Agentic AI is the future." Apps will all become agents, and we'll do everything through a chat interface.

Obviously, I see the parallels with my examples above.
But I don't see that as the one scenario to rule them all.

The use of "Agents" in AI/LLMs (probably connected via MCP) definitely has a place in the future and addresses some of the scenarios that AI (and even possible future General AI) could never do.

However, just because something new comes along doesn't mean everything that went before becomes obsolete and redundant.
Some of the things that can now be done with agentic AI may provide a better alternative than what was available previously. Some things will still be better, easier, or even faster with a dedicated solution and a non-text-based interface.

It's great to be excited by the new and the shiny, but that doesn't always mean the replacement of everything that went before.

---

I wonder what other abandoned side-projects I have that will turn out to be relevant in the future?

I hope that not all of my predictions about what's coming soon are as far out as the two I mentioned above.

Of course documentation shouldn't be like this!

Publishing this several months after I wrote it - the issues were eventually addressed and I managed to unblock myself.

Why do I care about XAML if I have such seemingly lofty software development goals?

Wanting to improve things for many people using software by providing better tools for developers may seem at odds with my focus on XAML. Afterall, XAML is a relatively small language only used for making native (mobile and desktop) apps by people building with .NET.
If I wanted to really make a big impact, why not look to do something online? or with AI?

Yes, more people use web-based technologies than use XAML.

Yes, AI has the potential to make a massive change.

However, many people are focused on these areas, and I don't want to get distracted by something new and uncertain.

I know XAML and its related technologies very well.
Very few other people are working to make working with it any better/easier.
It may not be a big niche, but it's overlooked by most, so I can (hopefully) make a big (relatively) difference with my efforts.

The people who use desktop and mobile apps deserve the best software, just as much as those using the web. 
The developers who build and maintain that software also deserve the best tools.

There's also a lot of such software already in existence. 

Software becomes old because it continues to be valuable to a business. If it wasn't, it would be scraped or replaced. That so much of this software is around highlights its value and importance.

Rewriting old software isn't always practical, but it still needs to be updated and maintained. Making that easier (faster and with fewer risks of unexpected consequences to changes) can be a big win.

For companies with a lot of existing software, being able to use the existing skills and knowledge in new software is very appealing. Building new apps faster and in ways to avoid future maintenance fears is another big win.

Secretly (I'll tell you because I like you), focusing on this area is fairly low risk.
I'm demonstrating an understanding of businesses and how programming languages are used within them. I also hope I'm showing an understanding of developer wants and needs and my ability to create sophisticated solutions to meet those challenges.

Even if all XAML development went away or I had an opportunity to work on something very different, I'm confident I'm building (and demonstrating) useful skills for the future.

Why did you need to change 8 files to add one checkbox?

Recently, I heard someone complaining that "this language is so stupid. Why do I need to touch eight different files to add one checkbox?"

Well, I don't know for sure, but I think it's probably not the language that caused it, it's probably a combination of the architecture of the solution and a misunderstanding of what they were trying to do.

In reverse order, you're almost certainly not "just" adding a checkbox. The checkbox probably represents a value that needs persisting and that has an impact on behavior elsewhere in the code base.

Therefore, it's to be expected that changes in multiple files will probably be required.

Needing to change 8 files may be a lot but I can easily imagine scenarios where that's the case. In fact, 8 may be on the low side for many applications.

I don't think it's unreasonable to assume changes in:

1. The file where the UI is defined.
2. The file where the new setting is persisted.
3. The interface (or header) file for the service/class that handles setting persistence.
4. The file with the test abstraction for the settings interface.
5. The place(s) where the new setting has an impact on code logic.
6. Any modifications to existing tests that are impacted by the new setting/behavior.
7. New tests for the new behavior.
8. All files with localized resources for the label shown next to the new checkbox.
9. Any screenshots of the UI that are now different (because of the added checkbox)
10. [User] Documentation that explains the new setting/checkbox.

I think it's how you frame the change being made that makes the number of files that might be affected as part of a single change more understandable. Knowing how many files may be changed as part of a fix/alteration can also avoid any surprises or disappointment when making the change. Especially if unfamiliar with the codebase.

Of course, not every codebase will need modifications in as many files, and it may be unlikely to change all the files at once (especially documentation and all localized files).

There's also the possibility to automate away some of the above through the auto-persistence of settings, or the use of mocks or source generators to not need to manually make simple changes.

Bonus, knowing how many files might need to be impacted as part of any singular change can also be useful before reviewing the work done as part of the change.

Ooh, just imagine recording the expected number of files to be changed as part of the initial scoping work. This would potentially also provide an extra way of measuring if expectations about the work matched up to what was actually done/required..

"As an architect, part of my job is to improve the way we do things"

I was recently listening to a podcast and was struck when the interviewee (a "senior software architect" at a large company) confidently stated that:

"As an architect, part of my job is to improve the way we do things."

Two things jumped out at me about this statement and the way it was made:

1. It implied that other people at the company don't look for ways to improve things.
2. It implied that other people at the company aren't allowed to suggest improvements.

I find this concerning.

I consider it everybody's job to always be on the lookout for ways to improve things.

Not that people should be spending a lot of dedicated time focusing on looking at and evaluating alternatives, but that everyone should have an awareness of challenges and opportunities for improvement and should share these when appropriate.

Many years ago, after the weekly developer team meeting at a company I was about to leave, someone else on the team asked why I had suggested a change to a process in that I'd be leaving in a few days.

I made the suggestion because it would be better for everyone working there. Even if that only included me for a few more days.

That other person was happy to be told what to do and then do it. No questions asked.

I don't want to work like that (and probably wouldn't last that long in such an environment.)

Naming is important, but consistency possibly moreso

Over on the MAUI repo, I've just started a discussion relating to the naming of code, particularly in relation to what is provided by default and the impact it can have.

Yes, I know that naming is difficult and subjective.

I started the discussion less to debate the names used but more to focus on the consequences of inventing new terms or using terms other than those that the population of likely users is most likely to already be familiar with.

There may be times when new or different terminology is required or preferred, but when that's the case:

• It is essential to explain why the change has been made, or the alternative is being used.
• Need to use the new convention consistently. This includes updating existing documentation, samples, and instructions.
• There needs to be a clear reason/justification for the extra work (& short-term confusion) a change in terminology will create.
• Filtering for personal preferences and justifications based on "how we've always done it" and the potential to "try something new" must also be factored in.

This is probably also a good reminder to me that "those who show up make the difference."

I also need to remember to motivate myself over the things I care about so that the enthusiastic but under-informed squeaky wheels don't cause avoidable issues for others.

Superstition, placebos, belief, and "playing with code"

Another brief post to help me think by writing.

I recently heard that "there's no merit to length in writing." They were talking about reducing the length of their book from 220K words to 180K, but the idea stands. The value isn't in the number of words, the value is in what it makes you think or do as a response to what you've read.

I've also recently recognized that when I'm thinking about a new idea, I spend a lot of time focusing on how to first express that idea and make little progress in progressing the idea. Once I first start writing and articulating that idea then I make progress in thinking about the consequences and application of that idea.

So, ...

I've recently been struck by the idea that "superstition is a placebo for belief." There's lots to unpick there and maybe that will come in time.

Beliefs are also strong and hard to change. Ironically, this is especially when people think they are very logical and intelligent.

I've recently encountered as lot of developers who are reluctant to embrace significantly new ways of doing things. 

Side note for the irony of developers being responsible for creating change (by producing or altering software) but reluctant to embrace change themselves.

They will quickly try something new (or "play with a new technology") and then quickly decide that it's not as good as what they currently use (or do).

Maybe "doing things the way I've become accustomed to doing them" ("always done them"?) is a superstition about being productive and a believe that it's the best way to do something.

Briefly "playing with something" (Yes, I dislike this term) is unlikely to provide the time or chance to learn the nuances of something dramatically different to what they've used before. It's also likely that it won't enable the opportunity to fully appreciate all the potential benefits.

Or, maybe the time to "ramp-up" on using something new means that it's never adopted because "there isn't the time" now to slow down while learning something new, even if it means being able to save time and move faster in the future. 

Or, maybe it comes down to not appreciating the possibilities of a new technology that requires thinking about usage in a fundamentally (an conceptually?) different way.

I've seen the above happen over and over again as new technologies come along. i.e. Asserting that "the new technology is slow" when using it in a way that an existing technology would be used but that is far from optimal for the new technology.

It's not the technology, it's what you do with it. Unfortunately this isn't always easy to identify without spending a lot of time using it.

And the placebo? - That there can be a perceived performance (or other) benefit by not changing when compared with the short-term impact/cost of slowing down to learn to do something new.

Yes, this applies to AI/LLMs, but to many other things too...

Developers like us pledge to support open-source

I was recently previously contributing to a project when something broke on the CI builds due to an issue with how a referenced library was misconfigured.

I didn't realize the library was being used. It was configured in a way that meant it didn't show up inside Visual Studio when working with the solution.

I also knew this library had a special (moral) license. This "required" those using it to support the project financially, but the business wasn't.

I wasn't using the functionality of the library, but when I discovered this, I did two things:

1. I made a personal financial contribution to the project.

2. I highlighted this to the business and indicated that they should be financially supporting the project if they wished to keep using the library. (The person who originally added the library pleaded ignorance--"But, it's open source, so we don't need to pay.")

People like us (developers like us):

• Support the people writing open-source software. Financially if possible (and requested).
• Respect the spirit of open-source licenses. Not just the minimum, enforceable legal requirements.

This incident raises other, bigger questions, but I'll discuss them at another time—maybe.

However, I mention this because I recently heard about the Open Source Pledge. An initiative to help encourage companies to "Do the right thing, support Open Source".

No, it's not going to solve the problem of funding and support for open source maintainers, but it will help.

"I'm not smart enough to use this"

 I quite often use the phrase "I'm not smart enough to use this" when working with software tools.

This is actually a code for one or more of the following:

• This doesn't work the way I expect/want/need.
• I'm not sure how to do/use this correctly.
• I'm disappointed that this didn't stop me from doing the wrong thing.
• I don't understand the error message (if any) that was displayed. 
• Or the error message didn't help me understand what I should do.

Do your users/customers ever say similar things?

Would they tell you?

Are you set up to hear them?

And ready to hear this?

Or will you tell me that I'm "holding it wrong"?