Why you should Unit Test - an example by MS Office

I'll admit it, when I'm writing code just for myself to learn stuff I tend not to unit test.  When I'm in a team environment I insist on it as the person coding isn't going to be the person maintaining.  Unit Testing has lots of benefits in terms of project success, code quality and longevity.  If you think testing first then you tend to think about the solution to the problem a bit more and that is always a good thing.  I tend to think about design by contract over unit testing, but unit testing tends to be the only way to build such things.

So lets take an example... file compression.  The sort of thing that a single class can easily do.  We've got two functions

char *compress(char *bytes)
char *uncompress(char *bytes)

Right now what are our core unit tests?

Well the first one of course is that if we compress something then uncompress it then it must be the same as the original.  The second one is also pretty obvious namely that the compress method should result in something smaller than the input.  Pretty much the basic method for such things.

Over at Microsoft Office however the 'compress' function built into MS Office, at least on the Mac, which is a one time thing to 'reduce file size' has a slightly different approach.  When you do 'reduce file size' on a presentation it manages to sometimes increase the file size.

That sort of thing should really have been caught in Unit Test.

Dear Google you've patented my published idea...

Okay so a while ago I had an idea, that people should blog about ideas they had and tag them as 'prior art' as a way to defeat patents.  Well today I read an article about Google patenting a location specific ad service which takes in local information (the weather) to give people targeted adverts. Well back in 2008 I had an idea, where I talked about temporal information including the phrase:

The final piece in the puzzle is then time. "Here" Services would need to know not only where "here" is but they would also need to know when "here" is. I don't want to be told about a show that finished yesterday or about one that is six months away. If its 11pm tell me about the Kebab shop, if its 9am tell me where to get Asprin.

Now in this I also talk about ad-servers and some sort of federated deployment model so arguably Google's great big central implementation is 'sufficiently different' to mount as a patent but I don't think so. However you can find lots of elements out there about location specific campaign management so the only 'difference' is that Google are talking about taking into account some environmental information to direct the advert.  This is something that retailers already do... ever noticed how they have more adverts for BBQs if its going to be sunny and more adverts for brollys if its going to rain?

So what is Google's patent really?  Well its the combination of temporal based (time/location) advertising with environmental information.  Its incredible that this passes a threshold of being original and not being something that anyone with decent experience could do.

I've had other ideas at other times but not been arsed to implement them.  Feel free to be the person who actually takes on the challenge.  The real point of this post however is to make the point that yet another patent has been granted that shouldn't be.  Its not about privacy moaning its actually about business and economic growth.  

What Google are patenting is what a corner shop keeper has been doing for as long as there have been corner shops.  Looking at who is on the street, looking at the weather and then picking their window display.  Re-writing that and putting a 'e' infront of it shouldn't be the bar that has to be cleared to get a patent, patents should be for genuine ideas that move us forwards and where the creator should be rewarded not for being the first person to work for a company with enough money to file a patent on the obvious.

Why the iPad is temporary but the screen is forever

Just thinking about the old MSFT case with the DoJ where a split up of Windows and Office divisions was muted (but abandoned), with current rumours that Office will be on the iPad later this year there is a question on the post-PC revolution...

Will I be able to code?  If I've got Office then that covers 90% of everything I do in my current role.  10% requires some sort of virtualisation solution, but VDI could be acceptable.  This means for Powerpoint and Word jockeys like me there really is no reason for the company to give me a full laptop.

But I still like to code to relax and the latest iPad has a larger screen resolution, more memory, more storage, better network connections and a better connection to an external monitor than the laptops I used ten years ago to code with.  This got me thinking, what actually stops Apple releasing XCode for iPad?  What stops an eclipse port?  Well there is already some work around using the browser as the editor but I think more will be done.

So what do I need to code?

• A processor, RAM and storage space
• A big screen, ideally more than one
• A decent keyboard

So while the iPad could deliver on the processor and RAM and a single decent screen and bluetooth to a keyboard its actually a bit of overkill.  Why couldn't my iPhone be the processor, RAM and Storage?  Why won't that just be on Amazon or another cloud provider?

The Post-PC revolution is currently dominated by PC mentality devices, integrated boxes of screens and stuff.  Technologies such as 'AirPlay' however talk to what the future really is.  A device that connects remotely to screens, and other elements.  So the future will be about the ultra-lightweight 'iScreen' which connected automagically to your iPhone 12 so you don't need to worry about heat issues or weight as the screen will just be the screen and some pass through circuitry.  The drive will be for that connected device that you have to link to your local personal network of things.

Why do I know this?  Because Bill Joy gave a presentation at JavaOne in 2001 that predicted it all.

SaaS v cloud, its a licensing thing

One of the things I get asked quite a bit is what is the difference between SaaS and cloud solutions and while there are lots of options for me it comes down to a simple question:

How are you licensing it?  

Your SaaS vendors license via users or other capacity metrics.  Things go up, things go down but you license based on those 'things'.   So for SFDC its the connected users for instance, same with GoogleApps.  Critically the thing that you are licensing is a business outcome that works out of the box.  So you can log into SFDC or Google Apps straight away and get working, sure you can extend and customise if you want but fundamentally you license based on a real-world outcome and are delivered a service to deliver that outcome.

With Cloud providers you license based on capacity over time so bandwidth/hrs, CPU/hrs, storage/hrs but this is just the raw capacity.  Same really when you are looking at PaaS, again its really just about the capacity, you are buying a slightly higher order 'box' but its still dumb until you do things to it.  So you are licensing an IT asset in a utility way.

So with Cloud providers you are licensing a capacity and on its own it does nothing.

So now we come to the final question on the cloud, what if you aren't using PaaS or if you are you need some extra software.  This is where a cloud can quickly turn from a cloud into just a virtual data centre.  If your additional software on that cloud is licensed based on CPUs rather than CPU usage then you aren't doing 'cloud' anymore you've just turned your cloud hardware into a virtual data centre where you are back to paying for licenses based on physical sockets (an odd idea in a virtual data centre where contention might be high) and not based on utility.

So in conclusion:

If you are paying for an outcome and paying for it based on a physical world business metric (number of trades, shipments, users, etc) then its SaaS, its about the service not the software.

If you are paying for an IT asset based on an IT metric and paying based on usage related to time... the you are doing cloud.  BUT you cease to be doing cloud once you add software onto that environment which is licensed based on a physical IT metric unrelated to time (e.g. sockets/CPUs/cores).

FUD Farming

FUD Farming: the practice of selling expertise based, primarily or solely, on negative (or FUD) based messaging.

I'd like to include a new term into the lexicon: FUD Farming.  Over the years I've seen the following attempt to sell used over and over again

X is a complete and utter disaster, X will lead to the destruction of modern society and ultimately Armageddon.  X doesn't work like it should, you really don't want to use it, none of your competitors are using it and if you do use it how do you know it won't cause everything else that you have to stop working?

FUD as a term is apparently over 90 years old (as is my Gran, happy 92nd Birthday for tomorrow Gran) and has a rich and ignoble history in IT.  However what I've noticed with the wave of social media 'experts' and specialist consultancies that FUD appears to be the only thing they are selling.  I receive emails with headings like

Do you know that your employees are sharing sensitive information on Facebook

How competitors are using Twitter to damage your brand

How Social Media is undermining your current marketing strategy

Almost all the messages and lead paragraphs are plain old FUD and the answer is of course to employ the expert/specialist consultancy who really understand this FUD and can therefore help you. Its this approach which I'd like to christen FUD Farming which  allows us to call such individuals "FUD Farmers", these are the individuals whose primary or indeed only approach to selling is based around creating FUD, throwing it around as fact and then utilising that as the way to solve the problem that didn't really exist in the first place.  This later is a critical point, most of the FUD comes down in the end to 'have a sensible engagement policy that is communicated to your staff' or 'your staff are doing this, you can't stop them so educate them' and guess what here is just the $$$ course to do that.  Of course as a company you knew that already but thanks to the FUD you've been sold a pup by the FUD Farmer.

WebSockets v REST (v WS-*) more pointless than eclipse v Emacs (v vi)

Well the shiny kids have a new toy... its WebSockets and by jiminy if it isn't just the best thing ever.  Actually to be fair to people promoting WebSockets they do appear to be taking a more rational, and less religious, stance than the REST area but this discussion remains pointless.  Mark Little's recent InfoQ post was a good pitch on the debate.

Just as REST v WS-* is pointless so the WebSockets debate is pretty pointless as well.  Its a new way of shifting information from A to B, its an 'improvement' over REST and WS-* in some ways and not in others but it doesn't actually make the job of conceptualising solutions any easier.

Its a rubbish picture but it gets the point over.  REST, WS-*, WebSockets, IIOP, MQ, Flying Pigeons, Rats with backpacks and any other data shifting technology are about providing the mechanism via which two services can communicate.  Its a required piece but the key question is 'what is the cheapest way', the value is provided by what goes across that mechanism and to define that you need to understand how the producers and consumers need to interact and that requires a conceptual model and thinking.

The hardest part of IT remains in that conceptual part, the planning, the thinking and the representing back to the business what is being done.  REST, WS-*, WebSockets or any other mechanism do precisely bugger all in helping to get that done.   The question I'd pose is this

Its 2012 now and what has improved in the last ten years in terms of making systems easier to conceptualise and the business concepts easier to communicate and what has been done to make the translation of that into technology (producer, interaction, consumer) much simpler and straight forward?

From where I'm standing the answer appears to be a whole heap of bugger all. Does WebSockets make this problem much easier or is it another low-level coding mechanism?  Its of course the latter. When people moan about the walled garden of Apple or 'monolithic' ERP they are missing a key point:

Technical excellence in the mechanism isn't important, its excellence in delivering the value that counts.

See you in another 7 years for the next pointless debate.

Has cloud lost its buzz?

After doing a presentation the other day I joked to someone from IBM that the WebSphere 'Cloudburst' appliance was one of the silliest names I'd heard.  An appliance that was tagged as cloud.  He then informed me that its not called that anymore but is now called the much duller, but more accurate, Workload Deployer.  Now I'm still not sure as to why this is a piece of physical kit rather than a virtual machine but its an interesting shift in marketing over the last few years that now people are taking the word 'cloud' OFF products.

Now this could be because the definition of cloud is now clearer and marketing departments don't want to confuse people, or (and more likely) its because cloud isn't seen as 'shiny' any more and therefore has lost much of its ability to entice clients.  In the later case shifting to a more prosaic name makes sense.

This would be a good thing as it means we've got beyond the peak of the hype cycle and are now getting towards cloud becoming an important technical approach but not being the solution to world hunger or having value as a 'badge' to slap on something to make it more attractive.