Tools to lesson the WPF pain

I’m back writing GUI code at the moment. I don’t think it would be an exaggeration to say that I hate writing GUIs. But, there’s nobody else to do it, so it has to be me.

It’s not just that I am doing GUI code though that makes my current project tough, it is that I am learning WPF at the same time. The last time I had to write a reasonable sized GUI I was using MFC and C++, circa 2002.

Why do I hate GUI programming?

It was probably incubated many years ago in the early 1990s when GUI programming was really quite painful. And fiddly, god it was fiddly. Make a change in the resource editor or C++ file, jump over to a dos box, recompile (could take anything up to 20-30 minutes), start the program, find that your change wasn’t quite right, rinse and repeat for days or weeks on end. Things haven’t changed that much, GUI programming is and always will be fiddly, but the tools have improved.

Tools will set you free

Fortunately, there are a number of tools that can help reduce feedback time.

  1. Kaxaml – a WYSIWYG tool for XAML. Has a number of limitations, which are pretty easy to get around. A very useful tool for building XAML based user interfaces outside of Visual Studio and the change, compile, debug cycle. Enter your XAML and see it rendered in real time. Changes can then be made very quickly. When you’re happy, copy the code over to your Visual Studio project; Free
  2. XAML Spy – a XAML version of the old Windows Spy program. Available as two version: standalone application and Visual Studio add-on; Paid app + Free
  3. Microsoft Blend – would be the perfect tool if it wasn’t restricted to creating Windows 8.1 / Windows 10 app store applications. Not much use in my case, but if you are creating app store applications then you are in luck; Free, bundled with Visual Studio Community
  4. LINQPad – won’t help you with XAML, but will help if you prefer writing your WPF code in C#. Type your C# code into LINQPad and execute it straight away. Even shows you the Roslyn parse tree; Paid app
  5. Snoop – similar tool to XAML Spy, except that this is completely free and open source; Free
  6. Visual Studio 2015 – one of the nicer new features of the new Visual Studio covers similar ground to XAML Spy, but all nicely integrated into the IDE itself. Nice. Free


A lot of programming is by its very nature an iterative activity, GUI programming is just an extreme form. The shorter you can make the change, compile, debug cycle the better. The above tools will help you reduce the cycle, but they don’t eliminate it. GUI programming has always been, is and will always be profoundly fiddly.


Posted in General | Comments Off on Tools to lesson the WPF pain

A reminder of the power of the internet

It is very easy to become jaded about technology, I had a reminder this week of just how wonderful it can be.

Last Thursday I started a beginners astronomy class at the local secondary school. I was more than a little surprised to learn that you can subscribe for a mere £3 per month and have access to three telescopes situated on top of a mountain in Tenerife through the Bradford Robotic Telescope.

You submit your astronomical target(s) via the telescope website and the telescope, without human intervention, schedules your job and, when it can, takes an observation and sends you the result(s) via email.

I know very little about astronomy and even I was able to schedule a job. It really is not difficult. There are no complex instructions to give, simply use one of the well known astronomical catalogs like the Messier object catalog, tell it how long an exposure you want and you’re pretty well done.

I chose M80 for my first target for no particular reason. My second target is Saturn. When I get the results I will be sure to share the results here.

Posted in General | Comments Off on A reminder of the power of the internet

A retrospective on Dyna Project version 0.1

Whilst version 0.1 of the Dyna Project isn’t quite finished, I thought it would make sense to take stock before work starts on version 0.2.

But first some introductions would probably be helpful.

What is the Dyna Project?

For a lot of years I’ve been interested in constraint satisfaction problems and how to solve them.

The Dyna Project is my latest attempt to create a tool for solving constraint type problems in an accessible way. I want constraint type problems to be as solvable as financial modelling is with a spreadsheet.

A retrospective on version 0.1

I’ve been working part time on the Dyna Project since 7th April this year. The project has received 122 commits so far, with approximately 5K lines of C# code. My plan was to build the simplest graphical modeller of constraint type problems possible. I think I have achieved that, it could not be much simpler.

Whilst the solution is very simple, there is the kernel of the design already. There is a place to model your problem, a mechanism for solving it and another mechanism to display the solution. The only element missing is the ability to design how the solution will be displayed.

I can’t say I like anything about the model building interface or design. It does work, but it is very painful to use. The idea of using different shapes for the variables, domains and constraints doesn’t work at all. The connectors add a lot of ceremony but don’t add much in the way of clarity. Most work in the 0.2 release will need to be used resolving the model building interface. Without a workable model interface, there’s not much point to the rest of the program.

The project name will be changing before the 0.2 release. The name clashes with another project on GitHub so I think it only polite to find another one. No idea what the new name will be yet. I am open to suggestions. :)

Please don’t use the project yet, it is some distance away from being usable. I know it’s buggy, and have no intention of fixing the bugs because much of the code is going to change for version 0.2.


The design of version 0.1 was only ever intended as a place marker. In that and that alone I think it has succeeded. The outline of the program is in there, all of those elements need considerable improvement in the next few releases.

Posted in General | Comments Off on A retrospective on Dyna Project version 0.1

Your business model is not a software feature

I created a product a few years ago and whilst it is doing fine on new sales it is really bad at monetising the existing customer base. The reason it is doing so badly at monetising our existing customers is because I assumed that the business model could be plugged in later, like any other software feature.

I was 100% wrong.

Why didn’t I build the business model in from the start? Patience. Or rather my lack of patience.

The software took quite a while to write and I was very keen to get it out of the door as quickly as possible. I got to the stage that I was sick of the sight of the software and just wanted it finished. There is nothing wrong with wanting your project finished. But your project cannot be done if the business model isn’t baked in.

When I originally created the product, I tried to create the simplest product possible that nevertheless delivered value to the customer.

I put two things off from the first version of the software. One was the ability to notify customers when a new version of the software is available. The second was the ability to renew the software subscription after the free period had elapsed.

I thought that I could plug-in the business model at a later stage. Just like a new feature. Turns out I was wrong. Whilst I could retrofit now, an awful lot of the value has been lost. Perhaps most of the value. The vast majority of existing customers will never know about the new software and so will never upgrade.

One of the nice things about developing for the various app stores is that you don’t need to build the business model. Somebody else has done that for you.

Posted in General | Comments Off on Your business model is not a software feature

Scam of the week

Last week we had to fend off a scam attempt. The scam worked like this:

  1. Order a product from a company and arrange to pay by bank transfer;
  2. Manually pay a counterfeit cheque into the company account. The cheque has no chance of clearing. Rather cleverly, the amount of the payment was 10x higher than the amount due. So it looks like a simple transcription error;
  3. Ask for a refund for the difference to be sent by bank transfer to another account;
  4. Profit!
  5. Disappear without trace.

The only thing that saved us from falling for the scam was the fact that we know that cheques show up in our account before the money is actually cleared. So, the money is sort of in your account but you can’t spend it.

Be careful out there folks, there are some odd sorts out there.

Update 2015/07/13: The scammer sent us an email over the weekend asking where his money is :)

Posted in General | Comments Off on Scam of the week

Why lone software projects fail

I have an awful lot of failed software projects. Most programmers do. It comes with the territory.

Most of the failures have been the result of running out of steam one way or another. Your early enthusiasm slowly wanes until the mere thought of carrying on makes you feel a little sick.

It is easy to forget that programming is an intensely psychological activity. Your attitude is central to the success or otherwise of your project.

Feature Creep

In my experience, I fail most often when I don’t maintain feature discipline. At the beginning of a project, you define the requirements for the project. The minimal set of features that are useful. You then start implementing those requirements. If those requirements stay basically the same whilst the project is being developed, you’ve greatly improved your chances of delivering the project successfully. If however during the development stage new requirements are being added to the project, then your chances of success greatly diminish.

Requirements are likely to change, in the beginning of a project you’ll be coming up with loads of new ideas. How can you control this process so it doesn’t knock the project off course?

Gather Requirements

You may think that requirements are only for large projects. You’d be wrong. Requirements are important whatever the size of project.

One of the things that can kill a project is the feeling that it is never going to end. You’re working away hour after hour, day after day and don’t feel like you’re getting any closer to the finish line.

That is why requirements are so important. If you nail the requirement down early on, ideally before you’ve written any code, you will have a much better understanding of what you need to deliver.

You will also avoid the feeling of being lost.

If you have any ideas for enhancements during the project, document the requirement and schedule it into a future version of the project. Then return to implementing the first set of requirements.

Your requirements need to be quite specific. Vague requirements like “Implement X” is really of no use. Be very specific. Outline precisely what is to be implemented, what data is required with examples. The examples can then form the basis for your tests. The requirements should specify the very minimum you need.

Your first version does not have to be released, you can iterate over a number of releases before you release your project.

Tools Can Help

There are loads of web apps out there to help you organise a software project. Many implement a variant of the agile board.

If you have a team of people, then using some kind of agile board is a great idea. For one person teams I think they add a little too much ceremony. If you find yourself spending more time fiddling with your agile board than actually working, then you’re over complicating matters.

I’ve found the very minimal GitHub Issue tracker to be ideal. You can’t spend a long time configuring it because there’s very little to configure. You can create issues, label them and add your requirements in the issue text. You can organise your requirements into milestones. When you’ve completed all of the issues attached to a milestone, you’re done. Move on to the next milestone.

Dyna Issue Tracker

Dyna project issue tracker.

Make issues that take a small amount of time to complete. A single issue that takes many months to implement will prove hard to gauge progress. But, taking a large task and breaking it down into lots of smaller issues begins to give you some momentum. You’ll feel like you’re achieving something when you are continually marking issues as closed. If you feel like you’re making progress, then you’ll have momentum and are more likely to finish.

Realistic Expectations

Related to requirements. You need to be sure that what you are building can be built in a time scale you are comfortable with. You are one programmer, the project you take on needs to be doable in a reasonable amount of time. I’d say that one year is the very outside of what I could cope with as a lone project. If I can’t program the project at the very outside in one year, then I don’t take it on.

In addition, if the project requires resources you don’t have, then either you need to have a plan to get hold of those resources or don’t start the project. A vague “I’ll sort that out sometime near the end of the project” will likely just mean the project is never finished. Resources like graphic designers or UX people don’t just pop out of thin air. Wishful thinking won’t help.


The temptation to create something perfect runs pretty deep in a lot of programmers. Perfectionism is very destructive because you can spend an inordinate amount of time ceaselessly tweaking something that, in the end, really isn’t very important. Worse, on lone projects, there is nobody to stop you disappearing down the perfectionism rabbit hole.

Every time you change something that already works you need to be questioning whether anybody will care about the change. Does the user really care about your obsessively edited product icon? The answer is almost always no. That is not to say that you need to put up with mediocrity. But, there is a big difference between excellence and perfection. Not understanding the difference between those two things causes an awful lot of projects to fail.

Getting Stuck

There aren’t many projects that you know how to implement every feature at the very beginning. At some point during the project you are going to be coding something that you don’t know how to implement.

Everybody gets stuck at some point. There are extra difficulties from getting stuck as a lone developer, not least that you don’t have any colleagues to bounce ideas off or to provide technical help.

How can you ensure that getting stuck does not kill your project?

You can ask questions on Q&A sites like Stack Overflow, but some questions don’t lend themselves to Q&A sites.

Let’s say you’ve exhausted the usual Q&A sites and you’re still stuck. What do you do now?

The simplest strategy is to isolate the problem. You need to focus solely on your problem, not worry about how you can integrate it into your project. You need to be able to try new ideas as quickly as possible without going to the trouble of fitting it into your existing code.

Most programmers end up with a disk full of small projects used to solve technical problems. A useful side effect is that they make asking good questions on Q&A sites a lot easier too.

If you have doubts about a particular technical area at the beginning of a project, it can help to tackle that right at the start. Then if you do get stuck you will at least be brimming full of enthusiam and therefore be less likely to give up.

No Version Control

Version control systems give you a lot of benefits whether working on your own or not. The main benefit they give is the ability to experiment, and more importantly, go back to a state before the experiment started.

I remember a lot of projects when I first started programming, when source control was not commonly used by PC programmers, a lot of projects were destroyed by experiments gone bad. I’d have an idea for a change and then hours or days into the change I’d want to abandon the changes but couldn’t. Either I somehow got the project back to a position I wanted it to be, or I’d abandon it. There is nothing worse than getting into a change and knowing you can’t go back.

There are no excuses for not using source control now. There are loads of providers, most with free plans, and the tooling is great too. You don’t even have to learn the command line anymore, Visual Studio and lots of other IDEs have source control tools baked right in.


It is easy to forget how much psychology comes into play whilst programming on your own. Momentum or the feeling that you are making progress is absolutely key. If you lose momentum, you are much more likely to give up.

Developing software is an intensely psychological activity. Developing software on your own doubly so.

Update 1015/07/13: Adds the “No Version Control” section.

Posted in General | 1 Comment

Tech Support would be a lot easier if…

…customers didn’t start the conversation with their own fault diagnosis.

Quite often the hardest part of the conversation is trying to coax the customer back a step to the original problem. And then working forward from the problem to a diagnosis.

Providing good remote tech support is one of the hardest jobs in the tech industry. You are at the end of a phone or email, cannot see the users set up and only have the highly edited highlights of what the customer is willing to tell you.

A lot of people are not very good at diagnosing problems. One of the challenges with technical support is that the customer has already, in their own head, figured out what the problem is. Sometimes the customer misdiagnoses the problem. So the interaction with tech support is then coloured by that misdiagnosis even to the point selectively missing out crucial information that may not fit the customer’s narrative.

A recent tech support call went something like this:

Customer: Hello support, I need you to send me a new X mine has stopped working.

Tech support: Oh, I’m sorry to hear that. Can I ask have you made any changes to X?

Customer: No, it just stopped working.

Turns out that the customer had made a change. The customer may not have been overtly dishonest. There may have been some time between making the change and discovering the fault.

We don’t have a problem with replacing faulty equipment. Quite the contrary. But, there is no point in going to the considerable expense of replacing equipment if that wasn’t the root cause of the fault. All that happens then is that customer now has two pieces of equipment that don’t work and are still no closer to knowing what the original problem was.

Whilst the customer won’t appreciate at the time being dragged back through a thorough diagnosis, they probably will appreciate in the end getting to a solution a little bit faster.

Posted in General | Comments Off on Tech Support would be a lot easier if…

A recovering “wunderkind”

If there is anything the IT industry loves above anything else it is youth.

I used to work in a company with an engineer who’d been programming since the early 1970s, who’d implemented operating systems on mainframes in assembly language, wrote OSI (up to session layer) and TCP/IP comms stacks from scratch on DOS based machines and made them all work together in the background. He wasn’t the only one either. There were a number of very talented, mature engineers at the company at the time. And yet, the guys the company held up on a pedestal were the snot nosed kids just out of college who hadn’t done anything even slightly comparable.

I was one of the snot nosed kids.

My “wunderkind” years hid a great deal of insecurity. Deep down most wunderkinds understand that it’s all just a charade. Genius in the computer industry is a much debased term, meaning you are moderately competent at your job but are young.

The fear is always there, the fear that somebody is going to find you out. Maybe, just maybe, your next project is going to show that you don’t know all of the answers. You may even be tempted to turn down projects that are challenging because of your fear.

The biggest danger is that you might start believing the bullshit. The worst thing you can do in this business is stop learning. If you start thinking you have some kind of innate ability, then sooner or later, you may think you can just rely on it. Stopping your learning in the wunderkind years is just going to mean you miss out on the early to mid career development you need to punch through into being a genuinely good engineer.

My advice if you are a current wunderkind? Ignore it like the bullshit it is. Keep developing your skills and take on challenging projects. Fail if you must. But above all, keep learning…

Posted in General | Comments Off on A recovering “wunderkind”

If you haven’t made it by the time you reach age X, you never will

I forget where I read that, but for a while it made me very unhappy. I was approaching X at the time and I most certainly had not “made it“.

Still haven’t.

Probably never will by my definition when aged X. And you know, it doesn’t bother me one bit now.

One of the nicer things about getting older is that your definition of “making it” changes. In my twenties it was about money for the most part. But, it is hard not to be sucked into thinking about your position at work.

There’s a lot of status tied up with managing people.

It does show the dangers of reading all of those articles on the web pontificating about success. It is your success, you get to define precisely what it is. Don’t let anybody else define it for you.

Posted in General | 4 Comments

Observations on 8 Issues of C# Weekly

At the end of 2013 I thought it would be interesting to create a C# focused weekly newsletter. I registered the domain and created a website and hooked it up to the excellent MailChimp email service. The site went live (or at least Google Analytics was added to the site) on the 18th December 2013.

And then I kind of forgot about it for a year or so.

In the mean time the website was getting subscribers. Not many but enough to suggest that there’s an appetite for a weekly C# focused newsletter.

The original website was a simple affair, just a standard landing page written using Bootstrap. Simple it may have been, but rather effective.

I figured that I might as well give the newsletter a go. Whilst the audience wasn’t very big (it still isn’t), it was big enough to give some idea whether the newsletter was working or not.

I’ve now curated eight issues, I thought it about time to take stock. The first issue was sent on Friday 27th February 2015 and has been sent every Friday since.

C# Weekly Subscriber Chart

C# Weekly Subscribers

The number of subscribers has grown over the last eight weeks, starting from a base of 194 subscribers there are now 231. A net increase of 37 in eight weeks. Of course there have been unsubscribes, but the new subscribers each week have always outnumbered them.

C# Weekly Website Visitors Chart

C# Weekly Website Visitors

The website traffic has also trended upwards over the last year, especially since the first issue was curated. Now there are a number of pages on the website, the site is receiving more traffic from the search engines. The number of visitors is not high, but at least progress is being made.

I started a Google Adwords campaign for the newsletter fairly early on. The campaign was reasonably successful while it lasted. Unfortunately, the website must have tripped up some kind of filter because the campaign was stopped. Pitty because the campaign did convert quite well. I did appeal the decision and I was informed that Google didn’t like the fact that the site doesn’t have a business model and that it links out to other websites a lot. Curiously, both charges could have been levelled at Google in the early days.

The weekly newsletter itself is a lot of fun to produce. During the week I look out for interesting and educational C# related content and tweet it via the @C# Weekly twitter account. I then condense all of the twitter content into a single email once a week on a Friday. Not all of the tweeted content makes it into the weekly issue. There is often overlap between content produced during the week so I get to choose what’s best.

The job of curating does take longer than I originally anticipated. I suspect that each issue takes the better part of a day to produce, which is probably twice the time I anticipated. Perhaps, when I’m more experienced, I will be able to reduce the time taken to produce the issue without reducing the quality.

Time will tell.

I can certainly recommend curating a newsletter from the perspective of learning about the topic. Even after only eight weeks I feel like I have learned quite a lot about C# that I wouldn’t otherwise have known, especially about the upcoming C# version 6.

If you want to learn about a topic, I can certainly recommend curating a newsletter as a good learning tool.

One of my better ideas over the last year was to move over to Curated, a newsletter service provider founded by the folks who run the very successful iOS Dev Weekly newsletter. The tools provided by Curated have helped a lot.

C# Weekly Content Interaction Stats Chart

C# Weekly Content Interaction Statistics

One of the best features of Curated is the statistics it provides for each issue. You can learn a lot from discovering which content subscribers are most interested in. You won’t be surprised to find that the low level C# content is the most popular.

The only minor problem I’ve found is that my dog eared old site actually converted subscribers at a higher rate than my current site. The version 1 site was converting at around 18% whereas the current site is converting at around 13%.

I have a few ideas around why the conversion rate has dropped. The current site is a bit drab and needs to be spruced up. In addition, the current site displays previous issues, including the most recent issue on the home page. I wonder if having content on the home page actually distracts people from subscribing.

All told curating a newsletter is fun. I can thoroughly recommend it. :)

Posted in General | Comments Off on Observations on 8 Issues of C# Weekly