If 'move' statements actually moved stuff, rather than copying it!
:-)
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 ...
Thursday, 21 January 2010
The Preservation of Software as Art
I remember way back when I was taught the difference between 'hardware' and 'software':
"If you can kick it, it's hardware, otherwise it's software."
... and that's the problem. Software, unlike some work of art lacks any physical form. You can't scrape off a landscape scene to reveal some hidden masterpiece - once the code is gone, it's gone for good.
Okay - yes - what am I doing, mixing 'art' and 'software' in the same sentence. Most everyone who looks at the majority of software knows it's nothing 'aesthetic' and certainly not 'art'. But that's not always the case. Kind of like those Microsoft ads, us geeks know that at some point in the future, software design will be seen as sexy. There will be a time when the creative process of solving such and such a problem, or designing that process will be viewed as something more refined than mere(!) engineering (or, possibly, considered on a par with traditional engineering). And by then, I wonder what will have been lost? How many designs, systems, applications, architectures, will have been erased, dumped, deleted, lost forever to the code heaven where all lost codes go? Already, how many pre-y2k systems were suitably elegant, and sophisticated to deserve more than the fate they suffered? True. Not all. Maybe not even 'many', but some - yes, certainly some I'd think.
So, should we be preserving these systems, rather than casually erasing them? How many 'legacies' should we be losing, and how many preserving? I don't mean 'maintaining', just moth-balling for future generations. For those yet to come. At least to learn from our mistakes (lest be destined to repeat them). I bet Microsoft still have Windows 3.0 available, but how many lines of business systems built in the 70s are still around somewhere? I know for certain that incredibly sophisticated and complex applications I have worked on are now no more. And literally no more. There presence lost from the software world; no longer in the physical world. No mark left, and no possibility of resurrection. Newer isn't always better; and even if it is better, then what came before isn't automatically irrelevant.
So, a museum of software. More than simply 'oldversion.com'. A celebration of what came before. A collection worth treasuring. Worth keeping. A testament to the endevour that came before. Surely, we should not be casually destroying this art?
"If you can kick it, it's hardware, otherwise it's software."
... and that's the problem. Software, unlike some work of art lacks any physical form. You can't scrape off a landscape scene to reveal some hidden masterpiece - once the code is gone, it's gone for good.
Okay - yes - what am I doing, mixing 'art' and 'software' in the same sentence. Most everyone who looks at the majority of software knows it's nothing 'aesthetic' and certainly not 'art'. But that's not always the case. Kind of like those Microsoft ads, us geeks know that at some point in the future, software design will be seen as sexy. There will be a time when the creative process of solving such and such a problem, or designing that process will be viewed as something more refined than mere(!) engineering (or, possibly, considered on a par with traditional engineering). And by then, I wonder what will have been lost? How many designs, systems, applications, architectures, will have been erased, dumped, deleted, lost forever to the code heaven where all lost codes go? Already, how many pre-y2k systems were suitably elegant, and sophisticated to deserve more than the fate they suffered? True. Not all. Maybe not even 'many', but some - yes, certainly some I'd think.
So, should we be preserving these systems, rather than casually erasing them? How many 'legacies' should we be losing, and how many preserving? I don't mean 'maintaining', just moth-balling for future generations. For those yet to come. At least to learn from our mistakes (lest be destined to repeat them). I bet Microsoft still have Windows 3.0 available, but how many lines of business systems built in the 70s are still around somewhere? I know for certain that incredibly sophisticated and complex applications I have worked on are now no more. And literally no more. There presence lost from the software world; no longer in the physical world. No mark left, and no possibility of resurrection. Newer isn't always better; and even if it is better, then what came before isn't automatically irrelevant.
So, a museum of software. More than simply 'oldversion.com'. A celebration of what came before. A collection worth treasuring. Worth keeping. A testament to the endevour that came before. Surely, we should not be casually destroying this art?
Subscribe to:
Posts (Atom)