Tesmond's Useful Design

Is saving a few seconds really important? Image by  FracFx While practically any change, no matter how sure you are that it is a positive improvement, can be met with anger from the user base performance improvements are not one of them. In an ideal world all webpages would appear the instant we demanded them, however achieving good performance has costs, and those costs need to be offset against the benefits. Features and complexity sells and performance is just one of those features which can be easily ignored and tough to sell, especially if it is say the difference between 10 seconds and 5 seconds. The benefits of speed are often underrated and can be difficult to appreciate. For example a fast application is easier to use, not just because of the reduced frustration of waiting, but because it is easier to explore. If you click in the wrong place as the next piece of information appears instantly you can easily explore the options on the page. If every option takes ages

I always consider the primary constraint in software development to be time. While technically this constraint could be considered a function of money, it is difficult for a developer to assert direct influence over budget. Most organisations require developers to go quite high up the chain of influence in order to try affect the proportion of budget development have access to. Supply and demand factors for the product that development are supplying is difficult for them to directly influence, in most corporate structures sales and marketing are the real influencers of this factor. Yes they rely on the quality of product that development provide, but it is unlikely that and improvement in the product quality will have an equivalent impact on sales. The ability of sales and marketing to reach new customers and alter demand is a much more influential factor. It is one of the great features of software development that you can essentially do anything the customer asks for, but only if y

In previous blog posts I have mentioned that Cache has good write performance, in fact in certain circumstances it is faster than many other databases. However, it is rarely the case that optimising performance is not desirable. Every one loves a performance boost, it is the most universally loved product change. The closest I have ever experienced to a complaint about a performance boost is "its so fast I didn't believe it had worked". Any way I was working on improving query performance on a server when I noticed some intermittent slow down. I traced the performance issue to a task which performs a huge burst of write operations. The write operations were so heavy that the rest of the server was experiencing slow down. Obviously the code is under review to see if the amount of data being written is necessary, but I was curious about optimising the write operation itself. With read operations I have noticed that dynamic SQL is slower than compiled SQL which is i

As of today (17th July) CyanogenMod 11 is only available in a semi-functional version. With both GPS and the camera not working it could not be considered a daily driver, and of course there are plenty of other minor niggles. Samsung has introduced lots of great features in its latest version of TouchWiz, and I have always liked the swipe left and right on contacts to send a message or initiate a phone call since it was on the original Galaxy S, but this single likeable feature is does not compare to stock Android. The cleaner look, the instant responsiveness and now with Android L the promise of better battery life we all know that TouchWiz cannot compete. So far I have turned off most of Samsung's proprietary functionality, and found the finger print scanner and heart rate monitor to be next to useless. The Galaxy S5 is still the best phone I have ever owned, but a Google Play edition or CyanogenMod would be a massive step up in usability, speed and enjoyment.

When I first started my current job I was told that the database was an Intersystems database, I had not heard of this before on researching it I found out a number of things. 1. It was ranked number 63 on DB-Engines most popular databases 2. Cache is not a good name for a piece of software if you want to find information in Google 3. There was a distinct lack of examples and people discussing real code This 3rd issue is perhaps the most important. In programming most of what you want to do has been done by thousands of people before you. Want to parse a CSV file, well if your language does not have a built in function someone will have posted a solution on the internet. Not only will you have a working solution it will probably have been commented on by a number of programmers and improved to a level which would have probably taken you several live iterations to achieve. The code examples in the documentation are basic, out of context and ignore even simple advise on field fil

Photo credit: Flickr user FORMALFALLACY via Creative Commons Paul Lewis wrote an article attempting to reduce friction on password fields . He even referenced the wonderful xkcd cartoon on the subject, but I feel concentrating on ways of helping users to see how they can enter a valid password misses the main point of the friction. The friction is primarily caused by the requirements, be they minimum requirements symbols numbers etc. or maximum requirements like no more than 16 characters, or even worse the password must be between 8-12 characters! Being forced to modify a password to add extra features is likely to cause you to forget it, in the same way that preventing a user from certain length passwords or use of specific symbols will also annoy and lead to forgotten passwords. These restrictions add friction to the password entry screen and anything that can be done to remove these restrictions will reduce friction more than attempting to improve the clarity of the restri

It is interesting to see Intersystem's struggle to have a working system too...