BEFORE YOU START: Please note that although I currently volunteer for both the Stroke Association and Age UK, the views expressed in this blog are strictly my own. I am not a spokesperson for either (or, indeed, for any) organisation. I am based in the UK and the blog therefore has a UK bias - I've tried to use the Glossary to explain any terms which might be ambiguous, but if you think there is anything I've missed, please message me.

Thursday, 28 February 2019


I wanted to say a little bit about the application I've been writing. I finally finished it yesterday, after about 6 months. For one person, quite a tall order.

I finished writing it yesterday, but there is still more to do. The first thing I did, once I'd finished, was to allow Microsoft's Code Analysis tool to inspect the code. This came up with about 350 warnings and messages. Some of these, it wasn't practical to change, others of which, it was in a snippet of code I'd pulled off the web, so I was reluctant to change it. But there were some bits and bobs where I'd fallen foul of some convention or other. There were also parts that I guess I'd written in quite an old-fashioned style, and the tool suggested I rewrite these using some simpler construct, of which I was previously unaware. I mean, in that respect the tool was brilliant - I'm aware that we write in the flavour with which we're comfortable, so when new advances come along, we don't necessarily adopt them. Especially when these advances are just shortcuts in any case - you can still achieve what you want the original way, but the new way is cleaner or quicker or less code.

There's an old industry adage that the less code you write, the fewer bugs you write, and it is still every bit as true today. Where Microsoft have included a feature, it's a good idea to use it, if possible, just because they'll have had teams of people developing and testing that feature, far more reliable than little old me. It doesn't always work out that way, but that's the general rule.

So I had these 350 warnings. It sounds a lot but it's not, in my experience. I went through them one-by-one, and changed my code accordingly. I gave the app a cursory test this morning, just to make sure it all still hung together, and there were a few areas where changing the code had actually introduced bugs.

The next step is to give it a thorough test, and that meant writing scripts for all the tiny things on each screen to go wrong. Ideally, somebody else should do this, because a developer will tread a certain path through an application, and will be less likely to spot problems. A tester will also tread a path, but it will be a different path and, in any case, a good tester will vary the path they take. But alas, there is only me. So I've just finished test scripts and will start on those tomorrow, just to give myself a break. Unfortunately, when you use "community" editions of software, the amount of help you get with testing is minimal - I'm not sure it is a great deal better with more enterprise versions. In any case, you need to start with scripts, just because they tell you what to test. But I'll probably steer clear of anything automated. Previously, I've found it brilliant to be able to click a button and watch everything be tested automatically, but it takes a lot of effort to get to that point. And, people still employ testers, so my experience is obviously consistent with industry - if you could do it at the push of a button, they wouldn't have jobs.

I like to think that my attention to things like project plans and testing is what sets me apart from other one-man-bands. Of course, you can cut corners when you're on your own (and I do!) but things like this are just natural to me because of the environments in which I've worked.

No comments:

Post a Comment