There's been a lot of talk over the past couple of years regarding 'The Cloud' - people advocating the use of it either within the realms of business or personal computing, as a means of reducing costs and enabling anyone to have their own virtual data centre.
However, that utopia isn't really the case, is it? Cloud computing by that standard is still some way off, and might never really arrive. The idea of The Cloud marketed to us is one of your computer, your data, being somehow "out there" in some floating opportunity, scalable and configurable at a whim. The reality is that the majority of 'Cloud' suppliers are the same people who have been selling server-space and virtual servers for the past 5 years. All we're doing is buying a re-branded offering from them. There's no amorphous 'cloud'; you buy cloud-space and you can go look at the servers you are running on - touch them, feel them, and - most importantly - have them turned off. Have your cloud dissolved. Just ask Wikileaks ... how did their Amazon cloud work out for them? Turns out that rather than being "out there" it was on a collection of Amazon owned servers. Not a worldwide entity, but very firmly based on US soil, and able to be switched off.
In a true 'Cloud' the data and processors would be truly distributed, and replicated across multiple nodes not located in any single country. It would be no more in one place than in any other. A bit like an internet on top of our current one. And if you tried to switch off a server here another would take its place there. Imagine - not just the internet everywhere, but all the web pages everywhere too. A web of collected nodes all providing data and processing services, owned and controlled by no-one. TBL's vision, just extended beyond the communications level.
Real Cloud Computing.
Thursday, 13 January 2011
Wednesday, 20 October 2010
Tuesday, 19 October 2010
Web Design reminders...
Gosh, old IE and Firefox don't play well together.
Mental notes(!):
Also do remember that IE works more to standards if you include a correct HTML header (conforming) tag such as:
Mental notes(!):
- IE prefers any events to be declared on the INPUT elements (e.g. SELECT) rather than on the FORM object
- IE doesn't trigger an 'onchange' event for a radio button until you click elsewhere on the form(!) To make it work in both IE and FF, use 'onclick'.
Also do remember that IE works more to standards if you include a correct HTML header (conforming) tag such as:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Friday, 4 June 2010
Appraising isn't a level playing field
So we've all had those periodic performance appraisals ... objectives setting, seeing how we've done against the last set of objectives and so on, making sure those objectives are S*M*A*R*T of course(!)
... well, my problem with this is that it's not really a level playing field. Sure, let's agree on some objectives for the future, and see how we've done against them; but not all objectives were created equal. It's kind of like saying, "Hey Fred, you need to get Jim to run the length of Britain in two days", and that becomes Fred's objective. So, Fred's objective is to tell Jim to run the length of Britain, and Jim's objective is to run the length of Britain in 2 days. Now, it seems to me that Fred is likely to achieve his objective, so well done Fred. And Jim - well, not so likely. If we are measuring performance against objectives then Jim fails, and Fred succeeds.
Okay, in reality Jim is unlikely to agree to that objective, but more realistic cases are commonplace. Your job is to manage me whilst I build a new social network application; my job is to build the application. Is it fair that we both get judged in the same way against those objectives? How often have you seen 'objective complexity' be included in the assessment? Should it?
I think it's a bit like Olympic diving competitions. The dive has a difficulty level and that sets how high a mark you can actually achieve. Even if you do the perfect dive at a difficulty of 2.3, you'll still not perform to the grade of someone doing a decent dive of difficulty 3.7. The easy objectives should offer less reward is all I'm saying. But have you seen this in practice? Who goes around normalising the objectives, rather than normalising the performance grades?
Let's even things out by recognising that some things are harder to achieve than others.
... well, my problem with this is that it's not really a level playing field. Sure, let's agree on some objectives for the future, and see how we've done against them; but not all objectives were created equal. It's kind of like saying, "Hey Fred, you need to get Jim to run the length of Britain in two days", and that becomes Fred's objective. So, Fred's objective is to tell Jim to run the length of Britain, and Jim's objective is to run the length of Britain in 2 days. Now, it seems to me that Fred is likely to achieve his objective, so well done Fred. And Jim - well, not so likely. If we are measuring performance against objectives then Jim fails, and Fred succeeds.
Okay, in reality Jim is unlikely to agree to that objective, but more realistic cases are commonplace. Your job is to manage me whilst I build a new social network application; my job is to build the application. Is it fair that we both get judged in the same way against those objectives? How often have you seen 'objective complexity' be included in the assessment? Should it?
I think it's a bit like Olympic diving competitions. The dive has a difficulty level and that sets how high a mark you can actually achieve. Even if you do the perfect dive at a difficulty of 2.3, you'll still not perform to the grade of someone doing a decent dive of difficulty 3.7. The easy objectives should offer less reward is all I'm saying. But have you seen this in practice? Who goes around normalising the objectives, rather than normalising the performance grades?
Let's even things out by recognising that some things are harder to achieve than others.
Monday, 1 February 2010
No dirty linen to learn from
Following on from my previous post, I think there's one other important aspect of the 'lack of software permanence' - it's un-physical nature. When we make mistakes, it's general for us to learn from them. And not only us, but others who see our mistakes. So, an engineer can learn not only from their mistakes but from the mistakes of others they come across. And these mistakes are obvious - they're in your face and undeniable.
However, for software, we erase our mistakes. They are gone. For good. And not only lost to the author, but to any others who might have learned from them. Again, destroying that which we create seems to lead to a lack of general improvement in the 'art' of software engineering.
What's that Santayana quotation -
Those who do not learn from history are doomed to repeat it
How many software projects have you been involved with where the same mistakes are made over and over again? Is the skill in software development increasing in the same manner of collective best-practise prevalent in other disciplines, or are we successively repeating failures, and hitting only lower and lower grades ...
Subscribe to:
Posts (Atom)