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 https://gist.github.com/mrlacey/1b3eef0a9945b67883486bb9540b533d

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.


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

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


Wednesday, October 04, 2017

Comparing a variable with multiple options in C#

In a code review recently there was some debate about how to compare a variable with multiple values.
I'm writing this to put all my thoughts on the subject into one place and in a coherent (hopefully) manner.

As an example, consider this `if` statement.

if (new[] { MyEnum.Value1, MyEnum.Value2 }.Contains(someVariable))

It's the equivalent of "if (X or Y) = Z".

Also, consider this variation

if (someVariable == MyEnum.Value1 || someVariable == MyEnum.Value2)

The repetition of the variable typically makes it longer than the version using the array and reads, IMO, less naturally. It's the equivalent of "if (X = Y) or (X = Z)".

People tend to prefer the second option.

The argument against the first option basically comes down to:
I know an array of 2 doesn't add too much memory but it's just good practice.
I'm not convinced about the "good practice" argument.

  • Yes, an array is created, but it's tiny and there's nothing keeping it around and so can be collected as soon as is necessary.
  • It's not "common practice" I'll admit, but I've never seen code guidelines that explicitly say anything about how to do multiple comparisons. Is the first option considered wrong as it's not seen as frequently as the second?
  • It feels like a premature optimization. The argument of don't create anything that uses memory unless you need to puts preserving memory consumption above all else. I don't think that's right or something that anyone making the above argument sticks too rigidly.
If someone was really concerned about performance, I'd expect them to point out that the array method can cause boxing and this is likely to have more impact on performance than array creation. For a one-off check though the impact is still so small as to not be noticeable. This makes me think the above argument comes from a convention and perception that "creating arrays is bad" and should be avoided.


I also prefer the first option as it makes it easier to add another option. The adding of an item to a list is simpler than another comparison. As the variable needs to be compared with more options lines get very long if using direct comparisons.  Both options get longer but this gets much longer faster.
This isn't great.

if (someVariable == MyEnum.Value1 || someVariable == MyEnum.Value2 || someVariable == MyEnum.Value3 || someVariable == MyEnum.Value4 || someVariable == MyEnum.Value5)

I prefer a solution that uses an array rather than multiple explicit comparisons because I follow this maxim in my code:

Readability of code is more important than performance unless performance is an issue.

IMO, reading multiple comparison statements is harder.

In my own code, I don't actually do the above. I wrap it in a call to an extension method so it's even shorter and, IMO, reads even more naturally,

if (someVariable.IsOneOf(MyEnum.Value1MyEnum.Value2))

This reads like "if X = (Y or Z)" which is closest to spoken English.
It's also easy to add options to.


The extension method, if you're interested, is really simple.

public static bool IsOneOf(this object item, params object[] options)
{
    return options.Contains(item);
}


Some potential questions.

What if calling this type of code enough times that there is a performance impact?
- Then do what's necessary to improve performance. That's what the clause in my maxim is for.

What about not using an if statement?
- It might be more appropriate to use a `select` statement. However, if the `if` statement doesn't have an `else` clause then this leads to a `select` statement with only a single match which feels odd to me. (As above though, this may be just because I'm not used to seeing code like that.)

What about starting with direct comparisons if there are only two options and then switch to the "IsOneOf" methods when multiple comparisons are made?
- You could go that way but I'm not a fan as it becomes hard to enforce a consistent style across a codebase. It also means that the change to add functionality unnecessarily requires changing the structure of code which can make it harder to identify the meaningful differences in the change.


Thoughts?


follow up post on optimizations for the above.


Tuesday, May 30, 2017

What is a "bug bash"?

Disclaimer: I'm thinking this through as much as anything. Don't expect any amazing conclusions but I'd be interested to hear your thoughts and opinions on this.
Microsoft uses the term "bug bash" (example - but I first heard them use this a few years ago) to mean to hunt for bugs. Everyone stops what they're doing to try and find bugs for a period of time. The aim is to find as many bugs as possible.
At every company I've known use the term previously, the term meant something different. I'd always heard it used to describe a period of time set aside to try and fix bugs. Any bugs. The aim was to reduce the number of known bugs.

Bash the product until the bugs fall out. - vs - Bash the actual bugs.

As I start to write this I realize I haven't asked the internet about this. It seems Wikipedia sides with Microsoft in the definition.

I prefer the other meaning more.

I get it. Hunting for bugs is good. It's also really hard to fix bugs that haven't been found.
But there are problems with how I've seen the Microsoft approach used in practice.

  • It can only really happen late in the development process. When it happens earlier there are issues with separating actual bugs from things that are missing or known to not be finished yet.
  • It doesn't guarantee coverage of the app/software. Just because you have lots of different people using/testing the app at once doesn't mean they'll use all of it. In bug-bashes I've seen before they tend to generate a disproportionately large number of bugs in a small number of areas.
  • It can be seen as an excuse for no, or minimal, beta testing. Also, note that beta testing should be monitored with usage analytics to ensure appropriate coverage.
  • They can easily value quantity over quality. When the aim is on finding bugs in a restricted period of time the amount of effort put into writing a good bug report is often reduced.
  • The quality of bug reports often isn't as high from a random person on the team when compared with a professional tester. Poor quality bugs cost more to verify, investigate, and fix, so it's worth the time and effort to get a good bug report.
  • Even professional testers slip into bad habits and raise low-quality bugs.
  • It ignores automated testing.
  • The details of what's tested aren't correlated with any test plans. This means that in addition to the uncertainty of code coverage (as above) no details of things that are tested as part of the "bash" are recorded. This means that gaps in test plans aren't identified or filled unless a bug happens to be reported for that area.

Why bashing actual bugs is better.

  • Getting overall bug counts down is good. It enables you to "see the wood for the trees". With fewer known bugs you can prioritize better and work on new features. You also avoid duplicate bugs.
  • Bugs get fixed sooner. And fixing bugs sooner is cheaper.
  • It is an easy way to give the impression and feeling of progress. While trivial bugs may be fixed, having the number of outstanding bugs go down can be good for morale.
  • They encourage actually fixing bugs. It can be tempting for many teams to consider known bugs to be of lower priority than new work. Fixing known bugs before adding or changing features stops this and avoids a system full of known bugs.
  • Gives autonomy to developers to chose what they work on and can even allow them to fix bugs in their favorite parts of the code or pet feature. A culture where the fixing of bugs is encouraged leads to better software and happier developer teams.

I still like my approach better.

Is "bug bash" a term you use in your development/test process? How do you use it? What's good or bad about it?


Wednesday, April 26, 2017

3 reasons to use the MVVM pattern

MVVM (Model - View - ViewModel) is a separation pattern that was based on the MVP (Model - View - Presenter) pattern. It's very popular in XAML and some web development camps but is frequently abused.


As a separation pattern MVVM aims to provide 3 specific benefits:

#1 Collaborative working

By separating the visual part of the app (the user interface, or UI) from the related code it becomes possible to have specialists in each area work on related items at the same time. The theory is designers can work on the UI at the same time as developers are working on the code without needing to have them both work on the same files at the same time.
Unfortunately, very few people see this benefit as they don't work in teams or on projects where the are enough people with specific skills on the design and development sides that they can work on both simultaneously.

#2 Code reuse

Doing the same thing multiple times gets boring quickly.
Having the same code in more than one place creates a duplication of effort when the code if first created and adds extra effort to maintain the different copies of the same (or very similar) code.
As a separation pattern, one of the intentions is that it allows the different layers to be reused. The model layer is the most obvious candidate for use in multiple apps or versions of an app (i.e. for different platforms) but ViewModel should be able to be reused as well. If you're only building a single app for one platform you have an excuse for ignoring this but if your ViewModels could be being used on multiple platforms then they should be. The biggest barrier to being able to do this is having ViewModels that reference or are strongly tied to something in the View layer or the UI of a particular platform. The associated downside to this is that it also makes testing hard.

#3 Ease of testing

One of the long-time criticism of apps with graphical UIs is that they are hard to test. A separation pattern, like MVVM, should break the coupling between the application logic and the UI and so make testing more accessible. It shouldn't be necessary to do all testing via the UI and so tests become quicker and easier to set up and run. Sadly, many developers using the MVVM pattern still aren't getting the benefits that come from automated testing. Or, they're still creating links between the layers of the app that make automated testing much harder than it need be.



It is disappointingly common that I see apps and developers who are not getting any of the benefits mentioned above. Such developers are still enthusiastic about the pattern and encourage others to use it because of secret bonus reasons numbers four and five.

bonus #4 Bindings make UI updates easier to handle

Bindings simplify many of the challenges of manipulating data, capturing entered data, and monitoring changes. While definitely useful, this shouldn't be the only benefit you get from the MVVM pattern.

bonus #5 Ease of maintainability

By having a separation between the different parts of an app's code it brings a level of structure and uniformity to the code. It's easy to see where things should go or where they're likely to be. It also encourages the use of other patterns (dependency inversion, services, messaging, etc.) and so brings the benefits of good development practices. These aren't unique to the MVVM pattern. The benefits come with almost any architectural pattern that is followed and applied to a codebase.


Just because your code has some classes with the suffix ViewModel that you bind to your views doesn't mean that you are getting the full benefit the MVVM pattern could be providing.
This may or may not be an issue but I can almost guarantee that your codebase would be better served by having more tests. ;)

Do you use the MVVM pattern? What benefits do you get from it?

Tuesday, April 25, 2017

Book Update: New Title and 50% off *TODAY ONLY*

My book has a new title:
Usability Matters: Practical UX for Mobile Developers and other Accidental Designers.
Feedback tells us that this better fits the content and better communicates this is a book for mobile developers. Not a book for people who currently consider themselves designers or UX experts.

The updated cover

For today (April 25th) only it's part of Manning's Deal of the Day. Pre-order for half price with code dotd042517au at https://www.manning.com/dotd

Sunday, April 02, 2017

Windows Phone support ends in 100 days



Yes, on July 11th, 2017 support for Windows Phone 8.1 will finally end.

Ok, so not many of you are still using Windows Phone devices anymore, but this may matter for those of you who are. Like, say, if you've got several hundred in your organization.

What does support ending mean?
The end of support means that no new updates, including security updates, will be made available. The release of Windows 10 means that I doubt you were expecting any more updates anyway but if you're using these devices as part of running your business then a lack of security updates might be important. See the official support notes for more.

What if you are affected?
Update any impacted devices to Windows 10 Mobile if supported by the hardware. (See this guide from AAWP for how.) If not then you should start thinking about replacing that hardware. It's several years old now anyway.


Sunday, March 12, 2017

Playable ads - a cynical response

This week, Microsoft announced support for playable ads for Windows apps.

I totally believe this is a good thing, but I have some cynical observations to the announcement. Some of you who read this will be aware of my cynical take on things and have even reported to liking my alternative points of view.

Let's look at some of the announcement:
"The information contained in the product description page is not always complete and the experience a user can get from the actual app usage can potentially differ a lot. This sometimes leads to a quick uninstall if the promise of the product description pages is not met."
Yes, some Product Detail Pages (PDPs) are not great. If they're "not complete" and not representative of the actual app, then something should be done about them as they are. Just adding playable versions of the app/game isn't necessarily the best solution.

"Playable Ads are a completely new way for end users to interact with ads and apps."
They're only "completely new" on Windows. They've been on other platforms for ages. (See a few iOS screenshots below.) It's good to see Windows/Microsoft catching up.

 

 

 



"the user can interact with the app as if it’s already installed on his/her device"
With some (almost guaranteed) exceptions and limitations which aren't mentioned here.

"Why are these ads better? - Users will not leave the current app context after ad click since these are inline expandable ads."
This doesn't make it better than another ad. This makes it better than leaving the app to try something. There's a debatable argument about who this is better for.

"Users who install the game after three minutes of engagement are more inclined to use the game/app than those who just installed the app based on the product description page."
I'm not 100% on this. It seems a strange argument. It appears to be that people who have tried an app will use it again once they've installed it. I can see that point, but it's arguing against people who have installed it but not tried it.
More interesting and compelling would be a comparison between people who install after seeing a static ad VS a playable ad. I'd totally expect someone who completes the playable ad to be more likely to install the app. How this compares to people who install after just seeing the PDP is interesting. I would have thought the aim was to get people interested enough to install. It seems to imply there's a significant drop-off after people install. Do lots of people really install the app but never launch it? It would be interesting to see some stats on this. If it really is an issue then yes, I'd believe that people are more likely to remember something they've installed if they've tried it before than something they just liked the look of from a PDP.
There's also the issue of what led a person to the PDP in the first place, but that's too big a tangent to explore now.

"we believe that users acquired via playable ads will have a higher life time value compared with users acquired through the regular channels."
App development and promotion are a business. We want facts and statistics, not untested beliefs.

"As an end developer, you don’t have to do anything! No new packages, nothing. Microsoft does all the background work to give a seamless experience to the end users without you, the developer, having to change anything."
It might be that for some apps you don't have to do anything to make this work, but that won't be the case with all apps. Even if you could implement this without having to do anything you probably don't want to. Remember back at the beginning when these were seen as a solution to incomplete PDPs? A successful, high-performing PDP takes lots of work and effort. If you're not prepared to put in any work to creating the best trial experience, then you can't expect them to be super successful for you.

Also, don't ignore that for some apps playable ads may not be appropriate or possible. If they are something that could work for your app, then give them a go. Just remember that there are no magic bullets. ;)


Monday, March 06, 2017

Quickly add some text for testing

Sometimes I need a lot of text in a control to test something. For something very short I'll just mash the keyboard a few times but when I need something longer a bit more effort is required.
I thought there needs to be something that can generate some text (say, some Lorem Ipsum) when it's needed.
My initial reaction was 'how hard can it be to make such a thing'? But then I caught myself and realized someone must have done this already.
It turns out there are a few.

I chose to use NLipsum.

It's really easy to get it to return some text. Just the following is enough.

NLipsum.Core.LipsumGenerator.Generate(2)


In case it wasn't obvious, this was a quick post to remind me about this and I thought it was cool and useful enough to tell others about.

Tuesday, February 28, 2017

What is 5G?

An innocent question from a "normob" recently and I thought it was worth answering publicly.


5G is the fifth generation (the 'G' stands for Generation) of mobile data network. This is the way that data (rather than voice) is transmitted between mobile devices.
It will allow for even faster data transfer (think of really fast downloads and high-quality video streaming) and better support more devices in a small area (Useful for very crowded areas and IoT devices.)

For reference, previous generations are:

4G - The highest version currently in widespread use. Also known as 'LTE' which stood for Long Term Evolution. (You may see this represented as an '4'.)
3.5G - Slightly faster than 3G. Also known as High-Speed Data packet Access or HSDPA. (You may see this represented as an 'H'.)
3G - The third generation brought speeds fast enough to support video calls and streaming to a wide audience. (You may see this represented as an '3'.)
2.5G - Slightly faster than 2G. Also known as Edge. (You may see this represented as an 'E'.)
2G - The first popular technology for data transfer. (You may see this represented as a 'G'.)


Monday, January 16, 2017

Launch a store installed app from the command line

How to launch an app from the store

Use the name of the install folder: ">start shell:AppsFolder\{folder}!App". e.g '>start shell:AppsFolder\Microsoft.WindowsStore_8wekyb3d8bbwe!App'

Or, if it has one, use the app's one own URI scheme: ">start {scheme}:". e.g '>start ms-settings:'

Applies To : Windows 10



Starting a normal app from the command line (or a script, or a scheduled task) is easy. Just start the executable.
But apps that are installed from the Windows Store don't have executables. So how do you start them?

The simplest way is if the app has a custom URI scheme. If it does then it's just a case of calling 'start' and then the scheme. So, you could do something like this:

>start ms-settings:

If you want to add a custom protocol to your app see https://docs.microsoft.com/en-gb/windows/uwp/launch-resume/handle-uri-activation

If the app doesn't have its own custom URI Scheme then you'll have to launch it via the shell. Actually, the shell has its own scheme (helpfully called 'shell') so you can do this:

>start shell:AppsFolder\Microsoft.WindowsStore_8wekyb3d8bbwe!App

Here "Microsoft.WindowsStore_8wekyb3d8bbwe" is the PFN (Product Family Name) of the app to launch. Fortunately, these names are easy to find as there are folders with these names for each of the installed apps at "C:\Users\[username]\AppData\Local\Packages"

That folder also includes some things you can't call directly plus some folders that are actually part of other experiences so you can't use everything there.

Enjoy.

Wednesday, January 04, 2017

Tuesday, January 03, 2017