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.

ENAMEL: More than a DSL for writing XAML

A few weeks ago, I first shared my idea for an alternative to writing XAML. However, I just realised I haven't posted about it here. So, I've included the TLDR below. 

It might be tempting to think about it as simply a way to write XAML, but I think of it as more.
I think it's a way of documenting what you want from the UI in a way that encourages you to think about the markup as any other code file.

The idea came from ideas about how to address some of the common criticisms of XAML. There are ways to write XAML that address many of those issues, but the restrictions of the language mean that it's only possible to go so far. ENAMEL is an idea about what could be done without the historical baggage of XAML and without needing to change any of the tooling or existing code bases for languages that use XAML.

I'm still exploring ideas about what ENAMEL could be.

I'm also working on formalising my ideas and guidance for writing better XAML. Stay tuned for more details.

In the meantime:

ENAMEL - An RFC for possible future XAML-based development

A new, simplified markup language to define application UI. The new files automatically generate comparable XAML files for your WPF, .NET MAUI, or WinUI app, which are then compiled as normal. Fully configurable, totally optional (use it for some or all XAML files) and low risk as the XAML (and C#) files are still available.

It addresses the common complaints about having to work with XAML and adds new functionality without the need to change any of the existing tooling.

How much less verbose is it?

Well, this is the XAML for an Empty page in a .NET MAUI app.

<?xml version="1.0" encoding="utf-8" ?>

<ContentPage

    x:Class="NewMauiApp.MainPage"

    xmlns="http://schemas.microsoft.com/dotnet/2021/maui"

    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">

</ContentPage>

And this is the exact same thing in ENAMEL.

ContentPage

Yes, just a single word is needed!

There are more examples comparing XAML and ENAMEL.

ENAMEL: Simple, human-readable, and easily maintainable UI markup.

Learn more at https://github.com/mrlacey/enamel 

I also have a few amendments and extensions to the original process that are coming soon.

Sales, Marketing, and Advertising

I'm writing this for my own benefit and to think it through.

I'm trying to get some ideas clearer in my head by reducing them to something specific and simple. Obviously, the real world is more complicated and nuanced. I can't reduce whole industries down to a few paragraphs.

Let's start with some definitions:

Sales: Exchanging money for a good or service. Or activities relating to this.

Marketing: Saying 'here is a thing.'

Advertising: Saying 'buy this thing.'

Of course, people rarely buy something before being aware of it. Advertising and/or marketing create awareness that leads to sales.

When advertising creates enough sales to keep going, a business can be successful.
Put money into advertising. Create sales to more than cover the advertising. Make more money. Repeat.

Marketing is intended to eventually lead to someone buying a thing, but it may do so indirectly. By simply showing a thing, it may lead to people wanting to buy it. But it might "just" be increasing awareness so that someone will consider them (the company or a product) favourably (or at all) when looking to make a purchase in future.

Marketing may also be able to produce something that can "spread" / be shared / "go viral", so that it reaches more people than paying for direct advertising.

A "thing" can also be a concept. People still need to "buy" into an idea!

The marketing of ideas can be a powerful thing.

The boundary between advertising and marketing can be blurry. At least one is needed. A thing won't sell (or spread) if people don't hear about it.

Sorry, no conclusions or summaries here, just a desire to learn and grow.

Developers using "AI" is like learning JavaScript or jQuery

Excuse the data reference, but it's one I occasionally come back to. Back when jQuery was in its prime, there were two schools of thought about what front-end web developers should do.

1. Do you learn JavaScript so you can do "anything"? or

2. Do you "just" learn JQuery?

If you take the second option, and need to do something jQuery can't, you can probably find a blog post somewhere where someone else has figured out a solution. Or if you find a bug in jQuery itself, you can wait for someone else to fix it.

However, if you take the first option, you gain deeper and broader knowledge that can help see things in different ways and to know when jQuery may not be suitable, or will help when the next tool of choice comes along. Hey, you may even be someone who helps build the next great framework or write the blog posts that the other jQuery developers find when they get stuck.

At a high level, it's the same as asking:

• Do you learn a language or an API?
• Do you learn all about how to do a task, or how to use a single tool that can do most of the things related to the task?

Short term, the "smart" answer is to do the simple thing.
Long term, the broader knowledge is, theoretically at least, more useful.

However, when it comes to recruitment, suitability is often measured in terms of the length of time spent using a specific tool.

"Do you have X years of experience using Y product? - If not, you're not suitable."

But then I might have 5X years of experience with multiple products, including Y and competitors/alternatives, plus I'm considered by some to be an expert in the field.
However, recruiters (and their automated CV parsing tools) don't see me as suitably experienced. 

Maybe it's better to only work with quantifiable tools in measurable ways.

But what about AI, as I promised in the title?

I think there's a comparison with the use of AI/LLMs/Copilots/Agents/etc. when helping with coding.

I wanted to do something with a technology I wasn't very familiar with. 
I started by working through the documentation and was learning some things. But, it quickly became apparent that I'd need to spend many hours to get a full understanding of the technology and gain the knowledge to create the best version of the solution I needed.

So, I wondered if GitHub Copilot could do it for me.
I opened the relevant file, selected some relevant lines and asked it how to do it the different/better/shorter/generic way that I wanted. 

It quickly produced an example, and I was able to adjust this to get exactly what I needed. At least to the point where it appears to work.

But here's the catch. I don't know enough to know if this is the "best" way to do what I want. 

• Is "appears to work" good enough?
• Are there alternate solutions?
• What's the difference between the different approaches?
• And the pros and cons of each?
• Are there any edge cases I need to account for that the current code doesn't cover?
• How can I create automated tests for this?
• Can Copilot answer these questions?

Is it acceptable to go with what Copilot gave me? And, if there are issues in the future, to ask Copilot (or future replacement/alternative) how to fix them?

Maybe.

Maybe I'll have to learn more to address any future issues. That's okay, as I know how to learn and have enough wider knowledge and experience to do that.
If all I could do was ask a Copilot how to solve a problem, I might get stuck when the problems get harder.
But, at least I can say I have 2+ years using Copilot to assist my coding...

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?