Tesmond's Useful Design

So it's MWC time in Barcelona, the rumours about what could be released had me eagerly looking to see what might be my next mobile. Obviously the expected big gun Samsung S5 was going to be announced. Well that has to be the biggest tech disappointment for me. For some reason Samsung released a phone which for the most part is worse than their 6 month old Galaxy Note 3. Each year the S range has spec wise been the best phone at least for a few months, but now Sony have out done them with the Z2 and are even planning to release it before the S5. It seems strange that Sony are suddenly looking to win the spec race. Not only that but they are even talking about a new flagship every 6 months ! Meanwhile HTC have already mocked the S5 and alleged that their follow up to the HTC One, which is to be unveiled March 25th, will be superior . I was certainly considering the S5 prior to the announcement, but now it is off my list. Essentially I would be surprised if their minor camera

As I alluded to in my previous post there are many reasons to pick a database, performance is only one of them, but as it is the easiest to objectively assess that it where I am starting. So here is a quick look at query performance. So we have our 1,010,000 strong pair of databases. So how about a count of the number of editions which have a 1 in them (about 47000). MongoDB - 0.906 seconds Intersystems Cache - 2.247 seconds Well MongoDB takes a healthy lead in this respect. It should be said that by default MongoDB has its own query language, where as Intersystems Cache can be accessed through iteration or via SQL queries. Now I could have biased the query strategy, for example Intersystems Cache is significantly faster at selecting whole phrases, e.g. searching a specific property which appears multiple times can be returned faster that MongoDB, but in both cases I was looking at 0.010 seconds VS 0.007 seconds. It was consistently faster although it was in the magnitude of

While looking through stackoverflow I noticed an interesting question about the differences between Intersystems Cache and MongoDB. Now these databases are substantially different in many respects, but both do allow for a more direct object mapping approach than you will normally experience in a standard SQL environment. Having read that MongoDB had recently secured $150M in financing I was curious as to what the platform was like. Picking a database is never just about raw performance, but it is one of the most important aspects so I thought I would start with this aspect. What I thought would be interesting would be to compare the insert performance of objects in Intersystems Cache VS the insert performance in MongoDB. I took a very simple example, inserting 10,000 objects each with 3 properties, performed both tests 3 times on my laptop and averaged the results. There were no indexes defined. This is not exactly a great test but as Cache was significantly faster at doing

Problems of Implementing Change As a software developer you are always an agent of change. There is a problem with this role however, many of your customers will share your joy of change with quite the same light. When Office 2007 came out I personally thought it was a substantially better interface. However, there was plenty of online criticism, features had been renamed and moved, Office experts suddenly didn't know where their obscure several level deep options were, and even though most options were easier to find, because some were harder it was not undeniably better. People even went so far as to develop software to alter the new ribbon interface back to the 2003 design. Windows 8 suffers some of the same issues, Microsoft improved the boot up time, the hibernate functionality, they built in lots of new features, however, the tile interface change and the separation of desktop and tile based apps has lead to the entire product being criticised.  It can be dishea

Joel Spolsky wrote many years ago that a re-write from scratch was the single worst strategic mistake a company could make. He pointed to a number of notable failures that were re-writes from scratch. I believe his most salient points are You will have devoted a very large amount of development time to a product which will essentially have the same value as the product you are currently selling.  You will not have resource to improve the features of your existing product and your competitors will overtake you. Even if you develop using all the best practices available such as TDD or BDD, have a wonderful QA team a live field tested product is actually likely to be more robust. In essence he implies that refactoring legacy code is always the best path to adopt. The evidence he provides albeit from pre-2000 is somewhat compelling, and in fact some very successful companies have stuck to his mantra of refactoring sometimes in unique ways. By refactoring I mean the process of