Software wears out

One of the things that non programmer friends often find hard to grasp is the concept that software can wear out and get old.

It should not happen - code is code - it does not change on its own, how can it wear out?

Well, over time, and I mean years of time typically, things happen.

1. For a start, any maintained system will undergo a number of small changes, more at first, but over the years there will be slight tweaks. In essence the requirements are changing subtly over time. This is not a surprise, requirements do change, and any business systems will have to move with changes in the business, and regulations and policies and so on.

Each change will be considered, and one of the decisions that has to be made is whether to start again, or modify the existing system. Each change is usually small enough that the right choice is a modification. This is normally from purely pragmatic grounds. Starting again takes time, costs money, and adds risks as all code comes with some bugs.

The problem is that over time the code becomes a complicated mess with sticking plaster on top of sticking plaster. It may have started with an elegant and easy to understand design, but over time that is lost.

In some cases the original requirements lead to a design that simply does not fit now, so the code is doing it the wrong way, but with work-arounds to make it work.

You also find that comments and documentation are not quite up to date with all the changes, so it makes it hard to follow.

2. As a programmer, you change. Even now, after over 35 years coding in almost every language you can think of, I still find myself learning better ways to code. I have also built up a load of my own libraries which are used extensively in the business, and these are themselves programming projects which get old.

This means you look at old code, even code that has had no patches or changes, and just think "what idiot wrote this - it is messy", and it was yourself, a year ago.

3. Bits of code become obsolete over time, as the code and the requirements changes, but you end up with code that nobody knows why it it is like that. You can see special cases added in a panic to fix something that was broken and serious, and you know it was special and important at the time, but is it still needed? Thankfully good commenting and source control help with this, but even so, you still find the one line change you committed years ago, and can't understand the explanation you logged now. You have no idea if it is safe to remove this special case or not.

With all of this in mind, some times, you just have to start again. Making a new specification of what is actually needed, and trying to incorporate any special cases that exist in the current code - or at least understand why they are not needed.

This month we did that with one of the most important parts of the business - the BACS payments and collections system. It all started because we had to change the last step - sending to BACS - as Lloydslink was closed down. We could have just bolted on an extra sticking plaster to convert the Lloyds files to a new format, and indeed, that is what was done for the initial testing. However, the more I looked, the more I pulled at this thread - and found "worn out code" in place.

The result is all new code, using current versions of all my libraries, and a style of coding that is much better than before. It has all of the features we need, and at least one that I had missed (ooops). It is faster, more efficient, and easier to maintain with more comments.

Even so - in a year's time it will look old again, and you can bet some requirement will have changed and some patch applied.

With all of that said, I have to say that it is very rewarding rewriting something like this, if you can find the time and motivation.

One of my real programming jobs, when I worked for a mobile phone manufacturer, meant re-writing other peoples old and worn out code, and I had great fun capturing the real requirements, making a new and elegant design, and coding it in half of the previous code space (we were short of RAM and EPROM for this project so it was needed). It was nice to make things "work better" and be cleaner code. This was not a slur on the previous programmers - if it was my own "old and worn out code" it would have been the same.

At the end of the project the team leader had to complete a report for management and so he got stats from the source control system - including how many lines of code each of us had done. Turned out I had not only coded many times more lines of code than anyone else on the project, something which does not surprise me at all, but I had deleted a hell of a lot more lines of code than I had added. The team leader refused to report this as a huge negative number, for some reason. Shame, I was hoping to break someone's brain with that in senior management. Those were real Dilbert days...

Internet on the train

Once again I find myself on a 2+ hour train journey to Leeds. It happens :-)

So, I try and get some work done. I did once try and play WoW, but that really did not work well. For a long time I have used a MiFi. They are excellent. Today I tried a few alternatives, largely because I totally forgot to bring the charger/USB lead for the MiFi...

The first thought was tether via wifi to the iPhone. That would work, but would, in this case, be some horrid Three NAT internet service. One reason for using the MiFi is it can take an A&A data SIM which really "just works" and has a fixed IP and full 1500 byte MTU and so on. Yes, it is also on Three, but a business grade service. It is also then using an IP that is on my LAN at home, which is handy.

I am at a loss as to why Apple do not include a mobile modem in the MacBook Pro - they really should.

So, not using MiFi, I tried the East Coast Trains in-train WiFi. That was a huge mistake! Pings at 3 to 5 seconds, and sometimes 15s. Loads of loss. Unusable for anything interactive (like ssh and vim).

I realised I could tether the iPad mini. It has an A&A data SIM too. That works (via WiFi). But as I want to keep it charged I plugged in the USB lead, and of course the Mac simply tethers by USB, so even better.

The data SIM in the iPad means I am now seeing much more sensible latency, usually under 100ms, and much more reliable connection. I suspect this will be my preferred way of working now rather than using a MiFi at all. It was good while it lasted, but this "just works" too.

But one thing for sure - don't use the in-train WiFi, it is dire.

The Big Broadband Survey 2012

Thinkbroadband have conducted a massive survey which asks a lot of important questions about the way people view their broadband. Well worth a read.

There are some impressive stats relating to AAISP, e.g. pages 28 (value), 29 (speed), 31 (reliability), 32 (customer service), even 34 (social media use), 38 (loyalty).

However, the survey covers much more than just rating ISPs, such as people's views on parental controls for Internet access, how long they spend accessing the Internet per day, and what things are most important to them...

Well done everyone at Thinkbroadband - it is an impressive survey.

Trying out our MP again.

So, I have sent the following - lets see what happens.

Dear Phillip Lee,

I wonder if you are in a position to propose an amendment to the The Privacy and Electronic Communications (EC Directive) Regulations 2003, or perhaps advise how one goes about suggesting this. Specifically an amendment to section 30 Proceedings for compensation for failure to comply with requirements of the Regulations

Here, we receive a significant number of unsolicited marketing calls and faxes even though on TPS and FPS, and undoubtably suffer damages by wasted time and resourses. However, the actual value of damages for any one call or fax will be unprovable and negligable.

What I would like to see is a financial value in the regulations as a default or minimum, much like the Late Payment of Commercial Debts (Interest) Act 1998 defines a £40 amount (or more if provably more).

If there was a value of, say, £50, whereby the claimant would not have to justify the value of damages, just that they were the victim of a breach of the regulations, then I can see the legislation being much more effective.

Yours sincerely,

Rev Adrian Kennard

Click for large image

Really?

And what is worse is, when you "Click for large image" it looks the same size blue square and not actually any larger :-)

Well done www.theonlinepencompany.com

Short email addresses

As some of you know I use a very short email address. It is only 6 characters long. I also use a specific email address per web site or contact, but that is @ and a short domain, only 4 characters. This allows me to see who has leaked my email to spammers.

Lets pretend my email is x@x.xx and daft web sites get daftwebsite@x.xx as an email address. I don't plan to put my email addressess on a web site for fear of more spam, obviously...

Both of these cause problems from time to time.

One is the social/real issue of people not understanding that you can have a short email address. You quote it as x@x.xx and they go "what, .com?" and do not understand. This is normally OK as they accept what you say and it leads to fun conversations.

What is worse is web sites not believing the email addresses. The issue is that web developers make their own rules for checking an email address syntax. Instead of actually using the rules in the RFCs, which are clear and well understood and have been around for many years, they make up rules themselves based on email addresses they have seen. Some will not allow email addresses less than a certain length, and some do not allow domains that are too short. The rules they make are arbitrary and wrong, which is stupid.

It is very frustrating for me and most of my family and several people I know. All of my familily have email addresses of the form x@x.xx. The domain we use is not cheap, but it works and saves a lot of typing :-)

What is classic is that most of these web sites then have a contact form, which asks your email address. Most of these do not have the same checks, and allow a complaint using the email address they do not like. Needless to say I have had people email me at x@x.xx saying x@x.xx is not valid and getting a reply from me...

Some notable sites that get it wrong are the tax disk renewal web site, and, until recently, www.bacs.co.uk. I was shocked today as I complained two days ago, and today I find they have fixed it and let me know they have fixed it. This is a first - actually listening to me and fixing the brokenness.

I do have special email addresses using @stupidwebsitethatdoesnotunderstandshortdomains.e.gg for this reason...

So, well done BACS.

HMRC RTI and privacy

HMRC have a new system in place for payroll that means payroll details are sent to them each time people are paid. That is not too bad, but there is this new system for BACS payments too that allows HMRC to check the actual payment is made to the employee as well. It is a convoluted system that involves an extra field in the BACS payment and has led to a whole new way of running payroll if you use BACS. The BACS system advises HMRC of hashes that allows the payment to be checked without giving HMRC all of the details.

Anyway, there is a side effect that has occurred to me here. The receiving bank will no doubt see the BACS fields including this previously unused field. The field is not meaningful in itself, it is 4 characters, and for HMRC us has to start with a "/" character and then has three random characters.

However, the receiving bank can, now, in effect, see if a customer gets "proper payroll payments" in to their account. There will, of course, be lots of legitimate paid employers that get paid without a payroll bureau or direct BACS or some such doing this, but the bulk of people being paid by large companies or via bureaus will have this extra field on their pay. Indeed, as using this is part of HMRCs risk management, that will encourage more and more employers to use this for paying people.

So banks get to see if you are a "proper" paid employee, with pay details "properly" reported to HMRC, or not. Or at least have a clue towards that. It is not in fact definitive - nothing stops me sending this field on all payments we every make to anyone - but in practice the BACS systems will do "paying suppliers" and doing "payroll" as separate systems. So the presence of this field is a clue.

Will banks use this to consider the credibility or creditworthiness of a customer?