Friday, March 16, 2018

Did someone really design this ATM experience?

As I put my card in the ATM machine today I noticed a message on the screen that said
Receipts currently unavailable
I've seen it many times before. It means the roll of paper the receipts are printed on has run out. Not a problem, I just want cash.

After inserting my card and entering my PIN number, among the many options were two related to what I wanted:

- Cash with receipt
- Cash with no receipt

Yes, that first option makes no sense based on the message shown at the start. But wait.
I selected the second option and was then asked:
Do you want a receipt for your transaction?
- Yes
- No

I selected "No". I didn't want one and, based on what the machine had said moments ago, I knew it couldn't provide one even if I did want it.

I then selected the amount I wanted to withdraw.

All should have been good but then I was asked, again:
Do you want a receipt for your transaction?
- Yes
- No

Again I selected "No" and finally my money was dispensed.

Part of me was glad to finally get my money.
Part of me was tempted to try that again and see if what would happen if I chose some of the impossible options.
And another part of me was saddened by the process.

Here are my issues with what happened:

  • The software repeatedly provided options for things it had said were unavailable.
  • The software asked the same question multiple times, seemingly disregarding my past answers.
  • The software made the process longer and more complicated than was necessary.

Someone was paid to make this software.
Someone tested and approved this software.
Someone thinks this is a good experience to give to their customers.
Someone thinks that we should trust them with our money inside complex financial systems when they make what should be a simple piece of software unnecessarily complex.

You wouldn't build software that provided an experience like this.
Would you?

Tuesday, February 06, 2018

Create UWP apps with VB.Net and Windows Template Studio

The majority of my open source software contributions over the last few months have focused on adding VB.Net support to Windows Template Studio (WTS).

WTS is a Visual Studio extension that provides a better File>New experience when creating UWP apps.

The aim is to help new developers start in a structured, conventional way that will help in the future but they may not even know to consider.
It also aims to help all developers by removing some of the plumbing and code that is needed by every app.

Using the wizard is a simple, three-step process.

File>New Project dialog

Start by selecting the project type and the framework you want to use.

Then, add any of the predefined pages

Finally, add code to handle any extra features.

It can't do everything for you and there will be some things you need to do with the generated code before everything will work as you need. To address this, the code includes comments that explain what you need to do. You'll find them in the TaskList window.

Its usefulness doesn't just end once the project is first generated. It will also help you add to a project you've already created. Just right-click on the project in solution explorer and you can add a page or a feature.

That's still not the end. WTS already supports five frameworks when working with C# and there's much more planned for the future, including: Xamarin.Forms support; more pages; more features; and other exciting new functionality too.

To get started using Windows Template Studio, download and install the VSIX from

Or, learn more about the project on GitHub at

Friday, December 22, 2017

Cherry picking work is slow and unproductive

The IT Director would work with the sales team and choose a set of new features, functionality, and prioritized bug fixes to include in the next release of the software the company made.
Individual developers would then choose an individual item to work on from the list. When they'd done that one they'd pick another. When they were all done the release was ready.

Then I came along.

"Rather than picking individual work items one at a time (cherry-picking), why not group items that are in related parts of the system and have a single developer do all the work in that area at the same time?"

And they did.

The result:

  • Faster delivery
  • Less rework
  • Fewer integration issues

All because an individual developer could get a better understanding of the area of the codebase they were working in. This allowed them to see the wider implications of an individual change more clearly so there were fewer unintended consequences of changes (bugs). Working in one area of the code base for longer meant fewer context switches so developers were more productive. And because only one person would be working in the same area at one time, issues (bugs) of merging multiple changes by different developers to the same files were avoided.
This also avoided all the hard changes being left to the end. Hard changes are more likely to take longer than anticipated and so leaving them until the end increased the likelihood of delays towards the end of a release cycle when delays had more serious consequences. Getting them done early as was necessary as part of a group of changes avoided surprises near the end.

Monday, October 09, 2017

The end of Windows Mobile/Phone just leaves more questions

With posts like this, it seems that Microsoft is starting to publicly acknowledge the end for Windows Phone/Mobile.

So should we just shut up and move on?
It's not that clear-cut. There are still some things to consider.

If you've built Phone/Win10Mobile apps that doesn't mean you should abandon them. If you still have users keep serving them while it makes sense to do so.

Windows isn't dead.
It's part of three areas that cover the broad spectrum of computing that Microsoft support.

There's Azure for Web/Cloud
There's Xamarin for X-Platform Mobile development
There's UWP for everything else (PC, Gaming, IOT, & more)

This still leaves lots of questions/thinking points.

Questions specific to the Windows app ecosystem

  • What, exactly, does "not the focus" mean?
  • Will anything be done to push the consumer focus of UWP apps?
  • Will the mobile version of Windows 10 ever go away?
  • What about small tablets? Will they ever be a thing? And, if so what version of Win10 would they run?
  • What about Windows on ARM?
  • Will we see greater investment and support for UWP and Xamarin? So there's a single solution for client apps on all platforms?

Broader questions

  • Is it good that there are only 2 mobile platforms (iOS & Android) out there?
  • Are there other mobile platforms that could make a challenge or drive innovation?
  • How important are devices other than the portable computers we carry in our pockets?
  • Will anything ever come of "continuum" style devices where a mobile can become a PC or it becomes your personal, portable storage, and identity?
  • Will people ever get over the silver bullet idea of "write once, run everywhere" (with no specialist knowledge or extra effort required)?
  • When will offline web support be good enough we can all just use the web all the time?
  • How will Microsoft's push for AR/VR/MR with dedicated devices sit with so many other platforms building solutions on top of mobile?
  • Does any of this really matter?

One of the joys of technology is that there are always more questions.....

Thursday, October 05, 2017

Optimizing the comparison of a variable with multiple options in C#

Yesterday, I wrote about my thoughts around optimising the comparison of a variable with multiple options and how I prefer to optimize for readability over theoretical or potential performance issues.
After some discussion on twitter about how my sample code might be optimized I thought it was worth doing some proper analysis.

The big potential optimizations are

  • The removal of LINQ
  • Not creating a new array for each check
  • Removing the need for boxing

Using BenchmarkDotNet I was able to quickly run some comparisons to see which method would be the quickest. I tried a number of variations with the type of object and array creation.

The results.

                               Method |        Mean |     Error |    StdDev |
------------------------------------- |------------:|----------:|----------:|
                       MultipleEquals |   0.0013 ns | 0.0041 ns | 0.0034 ns |
                        IsOneOfObject | 132.7228 ns | 2.2074 ns | 2.0648 ns |
       IsOneOfObjectWithExistingArray |  93.5959 ns | 1.7975 ns | 1.8459 ns |
                       IsOneOfGeneric |  63.4804 ns | 0.8762 ns | 0.7317 ns |
      IsOneOfGenericWithExistingArray |  58.5615 ns | 0.8739 ns | 0.7747 ns |
                        IsOneOfMyEnum |  64.2691 ns | 1.3435 ns | 1.3195 ns |
       IsOneOfMyEnumWithExistingArray |  58.2238 ns | 0.9457 ns | 0.8383 ns |
                  IsOneOfMyEnumNoLinq |  12.1887 ns | 0.2395 ns | 0.2123 ns |
 IsOneOfMyEnumNoLinqWithExistingArray |   6.2302 ns | 0.0519 ns | 0.0433 ns |

Full benchmark code is at

While using multiple equality checks was by far the fastest approach, by removing LINQ, not boxing, and not creating a new array for each test I was able to achieve the best performance.

While using multiple equality checks is by far the fastest, I still think writing
if (MyEnum.Value1 || someVariable == MyEnum.Value2 || someVariable == MyEnum.Value3 || someVariable == MyEnum.Value6)
    /// do something
is far less preferable to
if (someVariable.IsOneOf[MyEnumNoLinq](targetValues))
    /// do something

And the code can still be pretty darn fast.
You just might need a few overloads to get the best performance from all comparisons.

Yes, I am aware that:

  • I only ran the tests with enums and you might get different results with different types.
  • It might not be possible to have a fixed array to compare with each time.
  • There may be further optimizations available. This is good enough for me though.
  • Based on the speeds involved this does feel like a micro-optimization unless you really are making such calls many, many times in quick succession.
  • I haven't looked at memory usage. If you're interested, go ahead, but standard warnings about premature micro-optimizations exist.

*** UPDATE ***

Ok, I gave in and looked at the memory profiling too:

                               Method |  Gen 0 | Allocated |
------------------------------------- |-------:|----------:|
                       MultipleEquals |      - |       0 B |
                        IsOneOfObject | 0.0558 |      88 B |
       IsOneOfObjectWithExistingArray | 0.0178 |      28 B |
                       IsOneOfGeneric | 0.0178 |      28 B |
      IsOneOfGenericWithExistingArray |      - |       0 B |
                        IsOneOfMyEnum | 0.0178 |      28 B |
       IsOneOfMyEnumWithExistingArray |      - |       0 B |
                  IsOneOfMyEnumNoLinq | 0.0178 |      28 B |
 IsOneOfMyEnumNoLinqWithExistingArray |      - |       0 B |

Yeah, I think it's safe to say that it's not an issue. If you're really concerned over 28 (or even 88) bytes you're in a really constrained environment and nothing I have to say about optimization or readability will be relevant or new to you. In fact, if you're in such a constrained environment you're probably best not writing in a managed language.