Wednesday, September 01, 2010
Re: BBC Radio 4 asx stream with Chrome or Rhythmbox
Hi
Try playing the stream using a different player such as VLC.
Either load the URL (Media > Open network stream) or play from the command line:-
vlc http://www.bbc.co.uk/radio/listen/live/r4.asx
Friday, January 26, 2007
Wow its been a long time since I was last here! Since my last post back in 2004 I have changed jobs twice and am now working for a larger company. This was just a quick note to recover my link back to this blog - hopefully more when I get some more time.
Thursday, January 08, 2004
Tuesday, November 18, 2003
http://www.gantthead.com/article/1,1380,195807,00.html
You Can't Be Serious?!
William Knight
October 13, 2003
When you are blessed with talented staff, a simple vision and a realistic timeframe for completion, how can you make sure your project is only as good as the last--and does not make your life stressful by exceeding expectations?
The halcyon days of software project management are gone; failing to plan is not planning to fail anymore, it is planning to lose your job. Because you have read all the books, know the terms and the appropriate techniques for running a good project--and doubtless been on training courses to consolidate your experience--to destroy a project you have to be far subtler than simply not planning.
To manage a project to failure and still maintain a career, you must tick the appropriate quality and assurance boxes on the way and have plausible deniability for the disaster. The perfect situation is for the project to fail, for nobody to be able to pinpoint why and for you to be certain of a long-term position without changing projects too often or climbing the management hierarchy too quickly.
Here then, are 10 ways to manage a project to failure without being blamed.
Busy
Always be busy. Make certain you keep all the appointments for your bosses and your customer of course, but make it fiendishly difficult for your staff to talk to you and only make "provisional" or "penciled in" bookings. If you are forced to provide a time and date, just cancel at the last minute. Whenever you do conduct meetings, apologize for being late, keep looking at your watch and rush off early.
Organization
Create multiple role names for the same person; six or seven and not defined in any one place. Use role names from all the books you've read and change them slightly to get the numbers up. For example, Software Manager, Software Development Manager and Software Engineering Manager are all similar enough to laugh off a complaint but sufficiently different enough to spread confusion in meetings so that assigned actions are plausibly forgotten. An advanced technique is to create roles not assigned to any person but merely suggesting responsibility. Sprinkle these role names liberally in conversation and documentation.
One-to-Ones
Manage through one-to-one conversations. By not having team meetings--after all, it's well known they waste time--your decisions will be passed by word of mouth until they have collected an air of myth and many different interpretations are being followed. The judicious use of role names will help you here: Introduce a new role name during each one-to-one so the person only "thinks" they know who you mean--but dare not ask for fear of looking dumb.
Team Meetings
Sometimes you will be forced to have a team meeting. Make sure it is at such a high level it is of no use to anybody but still satisfies the "regular team meetings" box on the assurance form.
Language
Create your own project language. Even better, borrow a language from another source and then it is plausibly deniable. Similar acronyms for similar ideas work best because there is great scope for confusion. For example, use "SS" for all the following: System Software, Safety System, Software Security, Security System, System Specification. Acronyms are marvelous when you cannot avoid passing on real information in your one-to-ones. Before the real information, use a string of acronyms as references--the listener will be so busy working out the context they'll miss the details, and you're too busy to repeat yourself so they won't ask.
Document Index
Do not be tempted to call a document by a meaningful name, but invent a referencing system and only speak of documents by the reference. Numbers are best, and provide the happy possibility of incorrect naming. A single slip of the finger and a document can be lost--that's not true of meaningful names, where the slip merely results in a spelling mistake and the author looks foolish. The system seems so sensible and the quality guys will love it, but think about it for a second. Imagine all your own books were numbered and you kept an index. You'd only know how to find your absolute favorites, and visitors wouldn't dare touch your bookshelves. This technique is a favorite of the failed project because the information is available for in-depth audits but impossible to find for everyday use.
Team Building
Have many autonomous teams in the project and make sure they are geographically separated: up the stairs, in another building…if you can get away with it, use an offshore team in another country. Mix this with one-to-ones, document reference schemes, the unique project language and your staff will have no chance of talking sensibly to each other--ever. When challenged, you are balancing resource, leveraging expertise and reducing costs.
Troublesome Individuals
Sometimes a member of staff will get ideas. Install a regime of "Responsibility and Entrepreneurship," and suggest the individual takes on the challenge to fix the problems. This will stop most casual ideas in their tracks because "ideas people" are not doers; they won't raise an issue if they think they'll have to pursue it. If you have done good work with the project language, one-to-ones and document referencing, even a keen individual will soon be drowning in a sea of opinions. If they keep coming up with good suggestions, just give them a new role name and heap on the responsibility. They'll soon get fed up and stop irritating.
Mismatched Planning
All plans should have achievable milestones, of course, but make sure they do not correlate. Management has delivery milestones based on requirements, software has build milestones based on components and testing has version milestones based on functionality. As long as there is no description of what functions match which requirements in what components, you will deliver a catalogue of untested software in the wrong builds with tons of missing functionality.
Process Improvements
In your one-to-ones, the "entrepreneurship" program and the high-level team meetings always stress the need to measure and improve. Of course, everything must be written down for audits, so with careful management you can produce an escalating stream of documents that obscures real information with endless changes.
If, after all the above, your project is not well on the way to doom like a dirty snowball racing to a slushy end and is still hitting the timescales, perhaps you ought to consider getting people communicating--who knows what you might achieve.
William Knight has worked as a developer, a project manager and a consultant to some of the worlds largest IT consumers in a career spanning 18 years.
You Can't Be Serious?!
William Knight
October 13, 2003
When you are blessed with talented staff, a simple vision and a realistic timeframe for completion, how can you make sure your project is only as good as the last--and does not make your life stressful by exceeding expectations?
The halcyon days of software project management are gone; failing to plan is not planning to fail anymore, it is planning to lose your job. Because you have read all the books, know the terms and the appropriate techniques for running a good project--and doubtless been on training courses to consolidate your experience--to destroy a project you have to be far subtler than simply not planning.
To manage a project to failure and still maintain a career, you must tick the appropriate quality and assurance boxes on the way and have plausible deniability for the disaster. The perfect situation is for the project to fail, for nobody to be able to pinpoint why and for you to be certain of a long-term position without changing projects too often or climbing the management hierarchy too quickly.
Here then, are 10 ways to manage a project to failure without being blamed.
Busy
Always be busy. Make certain you keep all the appointments for your bosses and your customer of course, but make it fiendishly difficult for your staff to talk to you and only make "provisional" or "penciled in" bookings. If you are forced to provide a time and date, just cancel at the last minute. Whenever you do conduct meetings, apologize for being late, keep looking at your watch and rush off early.
Organization
Create multiple role names for the same person; six or seven and not defined in any one place. Use role names from all the books you've read and change them slightly to get the numbers up. For example, Software Manager, Software Development Manager and Software Engineering Manager are all similar enough to laugh off a complaint but sufficiently different enough to spread confusion in meetings so that assigned actions are plausibly forgotten. An advanced technique is to create roles not assigned to any person but merely suggesting responsibility. Sprinkle these role names liberally in conversation and documentation.
One-to-Ones
Manage through one-to-one conversations. By not having team meetings--after all, it's well known they waste time--your decisions will be passed by word of mouth until they have collected an air of myth and many different interpretations are being followed. The judicious use of role names will help you here: Introduce a new role name during each one-to-one so the person only "thinks" they know who you mean--but dare not ask for fear of looking dumb.
Team Meetings
Sometimes you will be forced to have a team meeting. Make sure it is at such a high level it is of no use to anybody but still satisfies the "regular team meetings" box on the assurance form.
Language
Create your own project language. Even better, borrow a language from another source and then it is plausibly deniable. Similar acronyms for similar ideas work best because there is great scope for confusion. For example, use "SS" for all the following: System Software, Safety System, Software Security, Security System, System Specification. Acronyms are marvelous when you cannot avoid passing on real information in your one-to-ones. Before the real information, use a string of acronyms as references--the listener will be so busy working out the context they'll miss the details, and you're too busy to repeat yourself so they won't ask.
Document Index
Do not be tempted to call a document by a meaningful name, but invent a referencing system and only speak of documents by the reference. Numbers are best, and provide the happy possibility of incorrect naming. A single slip of the finger and a document can be lost--that's not true of meaningful names, where the slip merely results in a spelling mistake and the author looks foolish. The system seems so sensible and the quality guys will love it, but think about it for a second. Imagine all your own books were numbered and you kept an index. You'd only know how to find your absolute favorites, and visitors wouldn't dare touch your bookshelves. This technique is a favorite of the failed project because the information is available for in-depth audits but impossible to find for everyday use.
Team Building
Have many autonomous teams in the project and make sure they are geographically separated: up the stairs, in another building…if you can get away with it, use an offshore team in another country. Mix this with one-to-ones, document reference schemes, the unique project language and your staff will have no chance of talking sensibly to each other--ever. When challenged, you are balancing resource, leveraging expertise and reducing costs.
Troublesome Individuals
Sometimes a member of staff will get ideas. Install a regime of "Responsibility and Entrepreneurship," and suggest the individual takes on the challenge to fix the problems. This will stop most casual ideas in their tracks because "ideas people" are not doers; they won't raise an issue if they think they'll have to pursue it. If you have done good work with the project language, one-to-ones and document referencing, even a keen individual will soon be drowning in a sea of opinions. If they keep coming up with good suggestions, just give them a new role name and heap on the responsibility. They'll soon get fed up and stop irritating.
Mismatched Planning
All plans should have achievable milestones, of course, but make sure they do not correlate. Management has delivery milestones based on requirements, software has build milestones based on components and testing has version milestones based on functionality. As long as there is no description of what functions match which requirements in what components, you will deliver a catalogue of untested software in the wrong builds with tons of missing functionality.
Process Improvements
In your one-to-ones, the "entrepreneurship" program and the high-level team meetings always stress the need to measure and improve. Of course, everything must be written down for audits, so with careful management you can produce an escalating stream of documents that obscures real information with endless changes.
If, after all the above, your project is not well on the way to doom like a dirty snowball racing to a slushy end and is still hitting the timescales, perhaps you ought to consider getting people communicating--who knows what you might achieve.
William Knight has worked as a developer, a project manager and a consultant to some of the worlds largest IT consumers in a career spanning 18 years.
