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.

Four views of XAML development

Having spoken with hundreds of developers about XAML development, they almost all fall into one of three groups:

1. They've been using it for a long time (many years) and have grown happy with how it is. They can be productive and aren't interested in change.
2. People who don't like it and have decided to use something else instead.
3. People who begrudgingly use it, moan about some of its "quirks", and don't feel as productive as they would like to be.

If you're in either of the first two groups, that's great. Use what works for you. Be productive, build great software, and enjoy your life. The rest of this post is not for you. 

Group three is by far the biggest group. At a[n educated] guess, I'd say it's easily more than 90%.

I count myself in a 4th group. (Not just because I'm "special".)
I use XAML, but what I write doesn't look like the XAML that I see online, in demos, samples, and other people's codebases. The code I write is a lot shorter, clearer, and easier to maintain.

Part of what makes this possible are the tools I've created to help me. (Considering the challenges they face, that so few others do this, surprises me.)

But tooling has only gotten me so far.
Another language may be more beneficial.
But not one that requires a rewrite. Something that works with my existing code and also helps with new files.
Something that can enable experimentation without the risk of being stuck with code in an unsupported language and so can't be tried/used in "real" projects.

It sounds almost too good to be true.

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.

Software development as "creative problem solving" - and me.

The following is inspired by multiple interviews with actors and comedians. - Yes, I find software development inspiration in unusual places.

A motivated person who wants to make it in the 'arts' will typically have to do many things by and for themselves.

This means being a creative problem solver.

Want to put on a show but don't have a stage, set, or costumes? - Work something out!

Want to make a film but only have a tiny budget? - Get creative!

Want to try something entirely new and different that no one has thought about before and that everyone says is impossible? - Find a solution! Help others see your vision!

These are also the aspects of software development that I love best.

While software can do "anything", such a broad set of options is rarely helpful. Constraints are real, and they drive innovation and creativity. The constraints often lead to discovering that something isn't as impossible as originally thought.

There may be a need for people to build software that is the same as (or a tiny deviation from) what already exists, but I don't want to do that.
Not because it's beneath me but because it doesn't excite me.

I've previously particularly enjoyed projects along the lines of:

"We need it to do X but can't use [the only way anyone has ever done X before]."

or

"We only have 5 weeks to build [seemingly large and complex series of connected software], or we miss out on a massive opportunity for the business."

or

"We want it to do Y, but as no one has ever done that, we don't know if it's possible and can't (yet) see how to do it."

There are two ways such projects can be even more satisfying (to me):

1. When I get to see and hear how the created solution helps people and improves their lives. Even if only in a small way. 
2. When I'm creating something that helps improve things for other software developers. This is because improvements for them are multiplied into more, higher quality software that is beneficial (or even "just" less frustrating) to many more people.

This is, possibly, why I've recently refound an enthusiasm for the possibilities that come from creating software.

2024 wasn't a great year for me. I left what was initially a very exciting project as a team was formed around the work I'd started. As I felt the project moving backwards, it became frustrating and unproductive, and so I stepped away, wondering if this was even an industry I wanted to stay in.

Side note. Many months later, a simpler version of the project was launched, which received much acclaim and positive reactions. Hopefully it will go on to be very helpful to a lot of developers, but I can't talk about it in any detail.

I planned to take some time off and reassess my career plans.

That's not how it played out, as I sustained a physical injury that meant I had six months where all I could do was sit (literally) and watch the world (and work) go by.

It was like a miniature version of the COVID-19 lockdowns, but just for me.

Upcoming plans were cancelled. These included career goals, planned jobs, and events I'd been looking forward to for months (and even years in one case.) It was not a happy time.

At the start of 2025, when once again mobile and recovering well, I determined to forget the past year and try and find not only paid work (because bills don't stop when people do) but something that would excite me again. A way to use my creative problem-solving skills that could help other developers improve the overall quality levels of the software in the world.

As my experience is with native (rather than web) technologies and because I've spent a lot of time over the last few years thinking about how it can be easier and more productive to work with XAML, I've been thinking about that once again. As I refine what I would have previously thought was "too big an idea for me", I also look forward to sharing more about that soon.

Job titles in tech compared with other collaborative work in creative industries

Ok, that sounds like a boring and almost academic title, but this is about how filmmaking, food, and events can help me think about creating software.

Look at all the names that are displayed in the credits at the end of a movie.
So many names, each with a specific title, and each title implying a specific set of tasks. Those tasks may each require a specific set of skills, talents, and abilities.
It's not just a random assortment of names under a general title such as "team" (or "organized by").

Those titles aren't just labels or descriptions; they are also signals to others working in the production.
They also serve as a way to clearly communicate with people outside the group. This includes customers, partners, contractors, people they are doing business with, and the wider industry (including potential future employers and collaborators).

The roles/titles all have defined meanings, even if they're unclear to people outside the industry. (Do you know what a "key grip", "best boy", or "2nd Assistant Director" is or does?) Despite the different titles in the credits, these people may also call themselves 'filmmakers'. Even if they're not the director or doing everything themselves, they are still contributing a vital part to the process.

Or consider a large professional kitchen. Again, everyone has very specific roles that may also require particular skills or knowledge.
But during service, everyone in the kitchen is a 'chef' and is called that. Sometimes, this also includes front-of-house staff while in the kitchen.

The shared title is a mark of respect and acknowledges the need to collaborate and the values that different people bring. This is especially true when only one person is the public face of the work that took many.

Then there's the software industry.

Every company seems to have their own job titles with their own meanings. These may or may not bear any resemblance to the use of the same title by another organization.

Software "teams" are notorious for being highly separate and communicating poorly with the broader organization. There's also rarely a shared, collective responsibility that cuts across teams. 

Many people working in software creation are also dismissive of people in other roles. "Oh, they're just in the [department or team name]." Or, "They're just a [job title]."

These are the thoughts and impressions I have gained throughout my career.

I'm sure it's not everyone, but I hope it improves.

I enjoy working on solo projects, but I also like the idea of once again working on a large, cross-discipline team to help create great software.
Here's to hoping I find that soon.

The state (& future?) of XAML - A summary of a summary

Last week I gave a talk to a room full of .NET MAUI developers about "Rethinking UI Code".

The talks at the conference weren't recorded so I wrote up some of the key details for anyone not there but interested. 

That write-up became quite long, so here's the very short version (because I know you're busy):

• Everyone agrees that XAML has issues but loads of people still use it anyway.
• There are ways to make XAML much nicer to work with, but few realize this.
• Many of these improvements can be made by treating XAML like you would any other programming language.
• C# probably isn't the solution you want unless you want to rewrite everything you already have.
• I have lots of tools that can generate code and make XAML easier to work with.
• I've created a prototype of a language (I'm currently calling ENAMEL) that produces XAML and so sits on top of existing tools and toolchains. This language helps address many criticisms of working with XAML.
• I've done this as a way to encourage further discussion about what's possible and what the future might hold. (Not because I have answers. But because I have lots and lots of questions.) 

Now that you're intrigued, you can go and read the full version here or as a series on LinkedIn.

My talk at MAUI Day in London

For most developers working with MAUI (or WPF, or WinUI, or UWP?), creating the UI means using XAML. I've probably spent more time thinking about how this could be better than anyone--not a boast, and I wish this wasn't the case--so it was a privilege to share my thoughts with an audience who uses this technology every day.

Yes, I included multiple Taylor Swift references in my slides. What of it?

This was originally posted on LinkedIn as a 1, 2, 3, 4, 5 part series. The actual talk was only 3 sections, but writing it up in 5 parts felt more appropriate.

The following is a brief summary of the talk (and without music, memes, most of the 116 slides, some of the demos, lots of energy, and only a few things being thrown.) That's the thing about in-person events. They're not the same as blog posts or recordings.

Part 1 - If XAML is bad, why is no one doing more than "just" complaining?

XAML is the default option for defining UIs in MAUI (and WinUI, WPF, & UWP) yet everyone seems to agree that XAML is far from great. It can be verbose, hard to read, hard to understand, and hard to maintain.

Lots of people complain about it, but no one does anything about it.*

If it's so bad as to be worth repeatedly complaining about:

• Maybe the solutions are so obvious to everyone else that it doesn't even need saying. But, if that's the case, why does everyone: complain, write objectively bad (I said "poopy" in my talk) code, and write code that looks like it could have been written 18+ years ago?
• Maybe the complaints aren't real; people just like complaining, and XAML got the short straw when it came to choosing what everyone should moan about. But that can't be the case, as it is objectively bad.
• Maybe what I see as bad is "good enough" for everyone else. But if that's the case, why all the complaints?

Surely I can't be the only one who sees the issues and has thought about doing things differently?

If that's the case, it's a very scary thought.

XAML has been used by hundreds of thousands of people since it came out in 2006 (for building WPF apps) and little has changed since then:

• The books from that time are still mostly relevant.
• The examples from that time are still mostly relevant.
• The way it is taught has not changed since that time.

Are there other languages that are actively encouraged to be used and have seen so little development in almost 20 years?

Imagine trying to use a 19-year-old book on C# today!

It's not just that there are no new versions, it's that the way we think about it hasn't changed. When every other aspect of technology is evolving and being updated at a great pace, why has something that we all know to be bad not been given any consideration to how it could even be used in better ways?

How do people justify choosing to use this technology today?

If an employee or co-worker told me, "We're going to use X technology, we know it's not great, and we make fun of how bad it is, but we're going to use it anyway." it would raise some serious red flags:

• Why are you using it?
• What are the alternatives?
• Are there ways it can be used that address some of the problems?
• What other decisions have you made with the same justification?
• Why is this acceptable?

Developers are supposed to be smart people. Does this seem smart?

*Some people (probably between 6 and 12% of MAUI developers) have decided to abandon XAML and use C# instead. 

The argument goes something along the lines of "XAML is bad, but I like C#; why don't I [or we] just use C# for everything."

It's a reasonable argument and certainly possible, but I don't think it's the silver bullet that some claim:

• Most UIs defined in C# (all examples I've seen) adopt the same structures, patterns, and mistakes seen in XAML files. The code is basically the same as the equivalent XAML. Just because it's a different syntax, doesn't make it better.
• Claims of a "fluent interface" are exaggerated due to the use of method chaining for some functionality. In reality, the need to combine setting some properties directly, setting some properties via chained methods with the property name, setting some properties via a chained method with a different name, and having to rely on massively overloaded fallbacks for some functionality means you can only really be fluent if you're very familiar with all the options and which to use when.
• That C# is "easier" and has "helpers" available ignores the fact that XAML can be written to be "easier" to read and helpers can be created to work with it too.
• Claims that the use of C# creates a faster application than using XAML, ignores the benefits, of using compiled XAML. More importantly, the performance of code is often down to the way it's written and used, rather than an underlying benefit. I've not seen these performance claims backed up with real data to show the benefit, and people arguing this position don't seem as concerned with optimizing every aspect of their code for performance. If performance is a problem or is critical to an application, then, of course, you should do what's necessary to produce software that performs adequately. If you claim to make a decision for performance reasons but don't measure performance or optimize for performance consistently, I don't consider it a good argument.
• That C# needs to use fewer "magic strings" ignores that there are ways to remove the need to use any kind of "magic value" in most XAML scenarios and that most C# code (including demos and reference examples) is littered with "magic numbers".
• One argument for using XAML is that it encourages the separation of logic from presentation code. Though it's possible to maintain this separation when using C# for everything, it can lead to more complex code, and the effort required to separate things means it is rarely done.
• Even if everyone did decide to switch to using C#, does that mean they need to rewrite all their existing XAML? Would that be the best use of people's time? Would everyone be able to do this confidently because they have good UI test coverage and so could avoid introducing any unintended changes while doing the rewrite? - No!
• And if using a single language for everything is so great and such a wonderful solution, why don't we see this elsewhere on other platforms and with other technologies? For the people switching to Blazor because they don't like XAML, they still use HTML and C#. Why is almost all web development done with at least three languages (HTML, JS, & CSS)?

I'm not going to stop anyone from using C# for their UIs. In fact, I use it for some things myself. When there is logic required in determining what the UI should look like or be comprised of, using C# can be much more productive and performant than trying to do everything in XAML.

There was never meant to be a decision between using XAML or C#. It has always been the case that you get the best results when you use both. XAML and C# work together.

Of course, if the tools and languages you're using to create your app UIs are as good as you need and can imagine, and you're super productive, and couldn't possibly get any better, keep doing what you're doing.

I've yet to meet anyone where this is the case, and there was no one at the conference who admitted to this situation either.

I was worried I was "bringing sand to the beach" to present these ideas to a room full of experts and highly experienced individuals who work with XAML on a regular basis.

Sadly, I'm still to find others who are not writing the same bad XAML as everyone else.

Part 2 - How XAML can be written in more maintainable and developer friendly way.

Aside: What does good XAML look like? - If you've never thought about it before, take a minute to consider this. Barely anyone has a good idea.

It's not "just XAML" or "only a markup language".

What we put (type) in files that become part of an application and which we later need to read and possibly edit all have a lot in common. Yes, C# and XAML look very different and are typically used for different tasks and in different ways, but there are some truths that hold for both (or all) programming languages.

For any "code" that we'll have to maintain, we want it to be:

• Easy to write
• Easy to read (and understand)
• Consistent
• Well formatted
• Unambiguous
• As concise as possible without inhibiting understanding
• Without unnecessary duplication or redundancy

There's nothing controversial in that list. Is there?

Nothing you'd disagree with? - If there is, please leave a comment.

But, does that sound like most XAML you've ever seen?

I doubt it. And I think that's a problem.

If you think about it for a moment you'll start to question this too.

Above I got you to think about 'what good XAML looks like'. Almost everyone I've ever asked this question doesn't have an answer. The couple that did, said "it should be well formatted."

If formatting is the standard for quality, I think we have a big problem.

And, as people do want more maintainable XAML, we have a big problem.

So, what can we do?

I think consistent formatting is just the start.

Here are some other things to do:

• [Only] include useful, relevant comments.
• Order content within the file so that it matches the order of items being output.
• Structure the use of files within directories in a consistent manner.
• Avoid miscellaneous files that become a "dumping ground" for assorted functionality.
• Follow the Single Responsibility Principle. Give elements in the XAML a single task and, therefore, a single reason to need changing.
• Simplify layout structures within files.
• Avoid using unnecessary elements.
• Avoid setting redundant or duplicate property values. 
• Avoid specifying properties with their default values (unless there's a good reason and you add an appropriate comment to explain it to people looking at the code in the future .)
• Don't repeatedly define the same values/items.
• Make use of language features.
• Use inheritance where appropriate.
• Don't use "magic strings"
• Don't use "magic numbers"
• Encapsulated repeated logic.
• Use language features (such as a custom MarkupExtension) to show relationships between values and make those relationships clearer.
• Avoid repetition of text. (So you only need to change it once, in one place.)
• Use semantically meaningful names that show where and when to use something. (Not what it does or looks like.)
• Don't use variations of "Hungarian Notation" when naming UI elements or resources.
• Use inheritance to simplify code. (There are tools that can help with this.)
• Create new types that combine existing ones that are repeatedly used together.
• Create new controls to isolate stand-alone pieces of logic.

There is more detail on the above can be found in the MAUI - Focus on XAML workshop. (Sorry that this means giving you homework, but I'm not sure it's in anyone's benefit to repeat that here.)

Applying the above means that it's easy to go from code like this:

This code produces the screen in the screenshot.

To something much shorter, clearer, and easier to maintain, while still producing the same output (the image in the top right):

Yes, this produces the same as the above, shown in the inset screenshot.

 

Additionally, as there are often multiple ways of achieving the same results, why not use some of those things to reduce the nesting, verbosity, and complexity of XAML with something much shorter and clearer.

For example, why not use an Attached Property to add a gesture recognizer? Like this:

3 ways of triggering an event or command when a button is tapped.

Or something similar for adding behaviours to a control:

2 ways of triggering a command when the button is "Clicked"

Or maybe you want an easier way to specify the values to pick from:

Again, both code snippets produce the same UI.

Have a look through the above examples. Take a moment to get past the shock of seeing XAML that isn't as unnecessarily verbose as you're used to.

Which is easier to read and understand?

Which is quicker to type?

Which would you rather maintain?

Why doesn't everyone write code like the above? Each attached property is only a few lines of C#, and yet it makes working with the XAML massively more pleasant.

We're not limited to attached properties.

Creating custom Markup Extensions can greatly reduce the amount of text needed to apply a conversion to a binding and also make the text clearer. 

For example, the following shows four versions of a string being displayed. The first is without any conversion, the following examples show different ways of using a converter.

Isn't it nice when there are fewer words needed and those words are all necessary and helpful!

Plus, creating the extension only required adding an attribute to an existing converter. How simple is that?

Using XML namespaces and carefully choosing names can make code embarrassingly easy to read and understand. Even if you're not familiar with XAML or the code base, is there any confusion about what the following would do?

Some people complain about the inclusion of XML namespace aliases, I prefer to use them in ways that provide clarity.

Or, maybe we use a markup extension to reduce the creation of a complex item with properties (StartPoint, EndPoint, and Offset) that I can't and don't want to have to remember:

Two ways of creating a horizontal gradient. One with 7 lines of code, the other with only 1.

Yes, both code snippets produce the same output (as seen in the top right)

XAML doesn't have to be verbose and complex, it comes with ways to use it that are significantly easier to maintain and (relatively) a pleasure to work with.

What is stopping everyone (anyone?) from writing XAML like the simpler versions above? I'm not aware of anything. - If you have an answer, please share it.

Part 3 - Creating XAML doesn't need as much typing as you might think

The tools we get "out of the box" for working with XAML in MAUI basically come down to creating a sparsely populated application and the need to type everything by hand (with a bit of intellisense).

I've created some tools (and experiments) that make getting from nothing to a basic project architecture much easier, and from an empty file to useful appropriate XAML content much faster.

The MAUI App Accelerator is a Visual Studio extension that enables the creation of MAUI apps through a wizard-style interface. (Remember I said I like GUIs.)

It allows you to specify :

1. Which version of .NET to use (You should be using .NET 9 for your MAUI apps!)
2. Whether you want to use XAML+MVVM, XAML+CodeBehind, or C# to create your UI
3. If you want to use the Shell, and what sort of navigation style (tabs or flyouts) to use
4. How many pages you want in the app, what they should be called, and what (if any) default content they should include
5. What features, functionality, libraries, and dependencies should also be included in the app

It then produces an application with all these options, all correctly configured and with dependencies and initialization already done. 

It doesn't sound like the most revolutionary thing in the world, but it can definitely save minutes and maybe even hours to go from nothing to a complex working application full of correctly configured and useful dependencies.

That's great for new apps, but what about extending existing apps?

Well, version 2.0 is "coming very soon", and among numerous other improvements is the ability to use the same wizard to add new pages and features. Of course, it does this with the same level of integration into the existing app, so it automatically registers dependencies, adds resources, and correctly configures and initializes all it adds.

These new options can be a massive time saver

So, that's great, we can now build the basic structure of our application much faster, but what about getting the XAML we want inside the pages of the app?

I have two ideas to show on that subject.

First is the Pro XAML Toolbox. 

This is a variation on the default Toolbox, but it adds more useful and appropriate content to the page. Many options are configurable, and items can be dragged where desired or double-clicked to be added where the cursor is.

See how quickly a page can be filled with useful, appropriate XAML

While that allows the creation of XAML much faster than typing by hand, I still think there is a faster way.

For most data types in a ViewModel, it's possible to make a reasonable assumption about the UI controls that can be used to display and allow interaction with them.

When those assumptions are codified (in a configurable way--of course), then it's possible to generate the XAML corresponding to a particular ViewModel file.

My preferred way of implementing this is to simply drag the ViewModel file onto the View and have the XAML code be automagically added.

When doing this, the file is analysed, and appropriate elements are created depending on the types, their names and if they can be changed.

See below that:

• A bool called IsRefreshing becomes bound to an ActivityIndicator.
• An ObservableCollection<T> produces a CollectionView and the DataTemplate includes entries for each of the properties for the Type.
• Commands cause buttons to be added to the XAML to trigger the invocation of the command.
• etc...

No steps were removed. It really is this fast

It's also possible to open the ViewModel, select some properties and choose "Copy as XAML" which you can paste wherever you want.

As with the Pro XAML Toolbox, this isn't going to always give you exactly what you need, but it is much quicker and easier to make small modifications to something that is almost right than it is to type the entire thing from scratch.

This isn't all just me showing off. I'd much rather that someone else had created the above (and shown how XAML can be made more maintainable.)

The above is to show that other things are possible.

Given that this is possible, why has no one else done anything like this before? (There are a few command-line-based template options available, but nothing else with a GUI or as much flexibility. And nothing beyond that.)

Ok, we've seen that while everyone agrees that most XAML is bad, it doesn't have to be that way.  I've also shown that there are ways of writing XAML to make it much easier and more pleasurable to work with, and that it's possible to create tools to make working with XAML files easier.

Is this as far as we can go?

Is this as good as it can get?

Microsoft doesn't seem interested or motivated to consider any big changes. 

No one else is doing anything in this area.

That's not going to stop me.

Not that I want to be comparable to Thanos in other ways

Part 4 - What if we didn't write XAML?

If XAML has so many problems and it's taken this many years to identify and try and address them, maybe we should look for something new to replace it.

However, introducing a new language to replace XAML would have a number of challenges:

• It would need to be able to work with existing XAML (& C#?) to avoid the need to rewrite all that already exists.
• Many people would still assume the need to rewrite in the new option as the other option(s) would (eventually) go away.
• Assuming that the new language also came from Microsoft, the number of things they need to support and maintain would be increased (they'd need to ensure all pre-existing things continue to work) and this extra requirement would slow down development/advancement in other areas.
• What about all (sigh) the tools that already exist? Would they need replacing or updating?
• It would require thorough documentation (which takes time and effort).
• All the SEO goodness of existing docs, blogs, etc. would make it hard to find appropriate, up-to-date information about whatever is new.
• Developing a new language is hard to get right.
• Developing all the required integrations with developer pipelines and other tooling (there's more to MAUI than just XAML) is complex and would be a lot of effort.

That's a lot of reasons not to do it, or to not expect something anytime soon.

It's especially tricky as my expectation (based on 25+ years in the Microsoft/.NET developer ecosystem) is that developers are highly unlikely to pay for a solution that doesn't come from Redmond. Nor would there be a lot of participation in creating an open-source solution.

But, I'm channelling my inner Thanos right now, and I think I have a possible solution.

Is this too much Marvel?

Rather than replace what already exists (both code bases and toolchains), why not sit on top of that? 

I've created a rough specification and prototype of a new language that produces XAML.
The output XAML (& C#) can then be used just like the files you have and write today.

The intention is to define the UI in the new language which then produces XAML and everything continues to work as before. 

Tooling and IDE integrations quickly make this feel natural.

This way, everything that currently works will continue to work. New things are extras and on top.

• By having a new language that can produce XAML (& C#) files that are used as the project system and developer tools currently expect, there isn't the time and effort needed to change what already exists. We can experiment and iterate faster on possible alternative solutions.
• By producing files that are valid even if the experimental language goes away or you decide not to use it, there is little risk. You still have working code, and you're not stuck with something that needs to be rewritten in a way you can support and maintain going forward.
• As it works on top of existing files, it can be used in whole or part within a project or a team. Just start using it for the files (pages/controls/dictionaries) that you want. It's entirely optional.
• By treating XAML as acceptable input, it's also really easy to try it out. Just copy the existing XAML into the new file and start modifying it there. You can progressively switch to the new, simplified syntax and make use of new functionality a bit at a time. If there's anything that can't be done with the new language (or you don't know how) simply fall back to doing it with XAML.
• By generating code at design time, it's possible to do things that hand-written XAML can't.

Added bonus: this could also work with WPF and WinUI. There is nothing here that is specific to MAUI.

So:

• Low effort
• Low risk
• Big improvement

I think this is worth exploring further.

Because it's helpful to have a name to refer to things, I call it ENAMEL. (Experimental Native Application Markup Extension Language)

Here's a very basic teaser of it in action:

An ENAMEL (.enml) file in use inside Visual Studio

The above animation shows 3 windows inside Visual Studio. 

• On the left is an .enml file in an editor window. 
• In the middle is the .xaml file produced from the ENAMEL. 
• On the right is a design-time "pre-visualization" of what the page will [approximately] look like.

Yes, this is the default new page with some additional buttons at the bottom.

In the animation:

1. A property (highlighted in pink) is uncommented in the ENAMEL and the file saved.
2. This causes the XAML to be updated (yellow highlight) and that property added.
3. This change is also reflected in the "pre-visualization" of the XAML. 

Aside 1: The highlighting of parts of the code was done with this extension. 

Aside 2: The "pre-visualizer" is a tool I previously built for myself to give me an approximation of what the rendered app will look like. It doesn't remove the need for running and testing the app on real devices but it increases my confidence that the XAML I have will produce the output I expect. While tools like Hot Reload and Live Preview are useful, the "pre-viz" helps me avoid the frustration and disappointment of compiling and launching the app to discover I've left something out or made a silly mistake. This isn't specific to ENAMEL.

I'm not going to show here the details of the ENAMEL language that I showed on the day.

I'm not doing this to be a tease. I will share more details soon.

I'm trying to avoid making the discussion about my specific implementation when I want it to be about the concept.

The point I'm trying to make is that once I identified that there was a way to create a simple experiment with alternatives, it was easy to produce something that let me try it out.

I admit that I was well-placed to produce such a seemingly polished proof-of-concept. I've built DSLs (Domain Specific Languages) before and have experience integrating with Visual Studio.

To get as far as I did took a total of less than two days effort to implement. (Not including time spent in advance thinking about rules/syntax for the language.) Most of the Visual Studio integration was cut and pasted from previous projects, and I spent less than an hour doing the simplest possible thing I could to get basic colorization (classification) of the code.

In reality, all it's doing is taking a multi-line string as input, parsing it and returning another string containing XAML. It's basic stuff that anyone with at least some basic C# experience could do. If it was a separate app or had a command line interface to turn one file into another it wouldn't seem so remarkable.

Forget my implementation. Is this a good idea?

How would you feel about using a new, powerful, yet simple language to define your UI?
And, that then gets turned into XAML and used when compiling your app?

I know there are much smarter people than me out there who may have much better ideas.

I'm not trying to say I have the solution.

I am trying to say that we need a solution; how about this as a starting point?

What do you think:

• How can we make existing and future XAML easier to work with?
• If it's another language, what should it be like?
• If not another language, then what?

Part 5 - Now what? The future of writing XAML and me

So, now what?

On the day, I stated what thought the best and worst possible outcomes of my talk would be.

The best possible outcome would have been if multiple attendees could point out why I was wrong and explain why what we had at the moment was actually much better than I realized.

This would be the best option as only my time would have been wasted. 

The worst possible outcome would be if I'm right.

It's bad because it means everyone has been wrong. "Forever". And no one has pointed this out before. It's also bad because it probably means most people will want to wait for a solution from Microsoft and that's unlikely to come any time soon.

Ok, so this isn't life or death stuff, but it's what tens (hundreds?) of thousands of developers spend time on every day. If that time is being wasted and people are working more slowly because it's hard and frustrating to do what they want, I still think this is worth improving. How could that time better be used? What are we missing out on because of all the time lost to fighting "poopy" XAML?

Maybe there's a middle ground between my best and worst scenarios.

I'd love to continue to develop these tools and ideas. However, I'm currently in need of paid work, and what I get will determine how much time and energy I can spend to continue this.

• In an ideal world, there's someone in need of my development skills and an interest in these tools so that I can continue to develop them in ways that become beneficial to that company/project(s) and the wider community.
• Or maybe there's a company I can help build some software and this will leave me to continue developing these things in my own time.
• Or, maybe there's a company somewhere that has seen my creativity, skills, and way of thinking, and has an opportunity for me to discover entirely new things to work on. (And I find that so exciting I forget all about XAML and someone else can lead the charge to make things better.)

I'm also torn because despite having worked with these technologies for so long, I'm wondering: if this is an ecosystem where no one else is even thinking that things could be better while admitting that they're bad, do I want to keep working with these technologies?

I have the tools (and now the language) I've always wanted to work with these technologies and build native (mobile & desktop) apps. Part of me would be happy to keep them around while I have side projects that benefit from them. If I get work in a different industry and no one is interested in taking them forward, it won't have been a complete waste of my time.

I ended with the "DON'T CLAP" slide I have included above.

It's easy to treat clapping as the recognition of the end of something and then mentally switch to something else. I didn't (and don't) want me talking about this topic to be a temporary distraction or a momentary diversion only for everyone to go back to things as they were. I wanted (and still want) this to be the start of a discussion about how things can improve.

I don't have and can't provide all the answers. You're probably much smarter than me. I want to know your thoughts on this subject. Ok, you may still be taking in some of these ideas, but once you have thoughts, please share.

Yes, this is your prompt to leave a comment with your thoughts before you leave. 😃

If you don't want to (or can't) comment here, you can reach me via most social networks.

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

Why build a native app?

Today, more code runs on the web, and more developers write code that runs on the web than in traditional or native apps. This still isn't all software, and there are many reasons not to build for the web or use web technologies.

The most obvious reason to not build an application with web-focused technologies is because the devices the software will run on are not, or are rarely, connected to the internet. If you feel as though you are always connected and often by multiple devices, it can be hard to remember that this isn't always the case for everyone. This can also be due to circumstances (like location) or done deliberately for security reasons.

Even when internet connectivity is not an issue, some features are unavailable outside of native apps. This includes access to specific APIs or integration directly with the OS and other applications.

Some accessibility-related features of the OS are only accessible (ironically) to native apps and so are unavailable if using web technologies or must be recreated within the app.

Matching the native look and feel of the OS can more easily be achieved through the use of tools, frameworks, and languages that were created to integrate with the native UX of an OS.

Higher levels of code performance can also be achieved when not using the abstractions added by using multiple technologies. This is a debateable argument as it more comes down to how you use individual technologies rather than the technology themselves. It's possible to build apps that perform well or badly with most technologies. Being able to get closer to the silicon (with fewer layers of abstraction/framework/conversion) usually makes the possibility of better performance easier.

When there's seemingly an app available for everything on mobile devices, it may seem unnecessary to build an application specifically targeting more traditional computing devices. Even when apps can be built to run on varying devices and adjust accordingly, there's still a need to consider each device type differently. The creation and consumption of content required or provided by different apps can be better suited to the different capabilities and form factors of a PC, laptop, tablet, phone, or other device. 

Beyond the device and required capabilities of an application, you may also need to consider your existing skill set and any other apps you already have. If an organization already has multiple existing native apps that they support and maintain, adding a new app built with a different technology and requiring a different set of skills and knowledge can be a considerable risk to the organization. Training staff and maintaining a suite of apps built with a mixture of technologies can require a lot more work and, therefore, cost. This isn't to say that these reasons should be the deciding factor in what you build.

Many developers can't imagine building anything other than a web based solution. That lack of imagination and inability to consider scenarios other than what they do every day, probably isn't a great trait to have though.

Once you've decided to build a native app (or accepted that some people need to), there's the question of how to build that app...

Everybody "needs" to be capturing emails

It's a sentiment I hear a lot. Maybe due to the people I talk to and the podcasts I listen to.

I get why it can be important to capture emails for promotion but as I don't yet have anything to sell you (other than myself--BTW, I'm currently available for work) do I really need this? Maybe I should as it may come in useful one day.

I recently got locked out of the service I previously used to capture emails and that has made me rethink this topic.

It doesn't feel like it's in anyone's best interest for this site to have a pop-up asking for your email but I probably should have a simple way of letting people provide this if interested. SO, now there's a page linked in the header and no pop up. You're welcome.

While I've nothing to sell you today, hopefully I'll have another book finished later this year and my mailing list will be first to hear about that.

If you might be interested, click here or on the link above to join.

Variations on "the boy scout rule" in coding

Many developers talk about versions of the boy scout rule of:

"Try and leave this world a little better than you found it."

Not everyone interprets this the same way and I'm aware of 3 basic variations:

1. Make improvements as part of every change.
2. Leave it (the code) as you'd like to find it.
3. Leave the code a little better than you found it.

Some developers use variation one as an excuse to include their preferences or desires as part of other changes.

Some developers use variation two as an excuse to rewrite the pieces of code they're working on in the way they'd have written it originally.

Some developers think that variation three means that they have to make other changes to a codebase in addition to whatever new feature or bug fix they're working on.

I'm not sure it's any of these interpretations.

This "rule" or "principle" is generally good. Understanding how some people might be manipulating or mis-understanding it can be more helpful.

I like to understand the rule to mean:

"While I'm in this area of the code, are there any important things that also need working on? Or are there any simple fixes I can also address while I'm here?" 

I'll then make those changes as separate commits and/or PRs either immediately before or after whatever task caused me to look at that code.*

I've previously heard this as "code-gardening". It's like the day-to-day removing of "weeds" you notice while doing other things in the garden.

Hmm, there's probably a gender neutral version of this rule we should also consider using instead.

* Side note: I massively improved the work rate at one company when I suggested they switch from randomly assigning changes as part of each release to having all changes related to one area of the code be done by one person and at the same time. This was a very large and very old codebase with a medium-sized team working on it. The change in allocating work removed the majority of merge conflicts and issues from multiple people wanting to work on the same files at the same time. It allowed people to gain a deeper knowledge of some areas of the code, rather than everyone having a superficial knowledge of a lot of it. In turn this meant that solving trickier problems became easier as someone already knew the code well. The change in working allowed developers to take "ownership" of the code they were working on as they'd spent so much time on it and so cared about the quality. And it increased collaboration between developers when they were assigned a new area to work on with the next release. "You, worked on this area for the last release, what do I need to know before I take it over?" Overall, they started shipping faster and with fewer bugs being introduced.

I'm reminded of that change when I hear someone mention the BS rule.

Maintainable software requires these three things

For software to be considered maintainable, it requires 3 things:

1. For there to be (documented) knowledge of everything the software does (and doesn't/shouldn't) do.
2. For there to be a simple way of verifying the software behaves as intended.
3. For it to be written in a way that makes it clear to a person looking at the code what it does, so it avoids any unintentional side effects when changed.

Point 1 doesn't require a specific format or way of recording this information. Use what works best for you, the team, the company, and the project.

Point 2 can involve a combination of tools and may require some manual effort.

Point 3 is dependent upon the skills and existing knowledge of the person making a change. It's okay to require a minimum level of knowledge of the language, framework, codebase, etc. The goal, as far as possible and in combination with other requirements, is to have unambiguous code that is clear about what it does. (With documentation--and possibly comments--explaining why, where necessary.)

"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.)

Why UI code matters

As a simplification, there are three types of software:

1. Client/frontend
2. Headless/backend
3. Embedded

(Sure, there is some overlap and some things straddle these loose definitions.)

What separates client/frontend software from the others is that it has a graphical user interface (GUI).

I'm a big fan of GUIs.
I like that they make software easier to use because I can see things and don't have to remember as many options, commands, or a set of seemingly magic words to get the software to do what I want.

For many, many people, GUIs make software possible, usable, and desirable.

However, for many developers, creating GUIs can be a source of frustration.

Regardless of whether using markup to describe the structure of the code or an imperative language that describes how to create it, GUI code can easily become verbose and hard to maintain.

If code is hard to maintain it becomes slower and therefore more expensive to modify without unintended consequences and negative side effects.

If spending extra time modifying hard to change code that means less time for doing other work. Such as fixing bugs or adding new features.

There are also the negative emotions and blows to motivation developers feel about having to work with hard to maintain code.

The GUI is also important as it's the part of the application that people (users) see and interact with. It's what many people will know as the face of the application that they may spend hours looking at each day. They may spend more time looking at it than other people or the faces of their loved ones. For something that gets that much time and attention from the people using the software, doesn't it deserve adequate consideration from a development perspective too?

It can be easy to dismiss the GUI as less important than other parts of a code base, but doing so is a mistake.