Australia has a govenrment based on the British model, plus we're better than the poms at all sports (was going to say most, but in light of Australia beating the Pom soccer squad last time up, I'll stick with all).
So saying that they "probably" deserve what they're getting is entirely false, unless you're divulging classified information.
I said that because I still tend to believe that law enforcement people (and that is apparently what the people who have taken these people are) tend to be at least honest enough not to put behind bars someone who they themselves believe to be innocent. In other words, I can't believe that the US would be party to the mass arrest of innocents, and their long term incarceration (5 years and counting) without trial, unless they had a fair amount of evidence that the people in question were guilty of the crimes that they were arrested for. After all, they have released a fair number of their detainees already, without trial, after apparently clearing them of any chargeable wrong doings.
Yes, you are right, of course. It's something that travellers have had to concern themselves about since before marco Polo set foot in Asia (if he did, but that's another story).
The only new(ish) twist to this is it happening while the people concerned were in transit. I wonder which side of Immigration they were on? I know that back in the 70's, when I flew from Vancouver to Melbourne, I spent about 6 hours in a locked terminal in Hawaii, waiting for my plane to come in for the next leg from Dallas or somewhere like that, and there was no thought of putting the pax through immigration - we were all just in transit, and so effectively we were treated as never having entered the country. I've transitted through many other International airports over the years, and i have never been asked to pass through immigration while in transit, so I've never ever in fact entered those countries. Pity, I'd have liked all those interesting stamps in my passport.
If they didn't pass through immigration, how were they allowed to be arrested. I would have thought that they would be outside of normal US jurisdiction. Oh, well, such is life, I suppose.
Can anyone explain under what pretense the US gets to arrest noncitizens for violating US law? To be fair, the US has been doing that for quite a while now, and to be fair, if the foreign citizens were on US soil, and had broken US law (they weren't just share holders, but ex-executives of netteller), then you will be arrested if they catch you. Where it is very hard to justify is where the arrestees have actually been taken outside of the US, and not in a war zone. A lot of people in Gitmo have come into custody by that route. Probably they deserve to be there, but I still doubt the legality of a lot of the siezures that came out of the Middle East prior to the USA declaring war on anyone other than a fairly nebulous concept of "terrorist groups".
Under that heading are such groups as the IRA, which only a few years ago (and perhaps today - I really have no idea) was raising funds in bars in New York (which has a large Irish descent population). No arrests there, that I know of, but then, the NY constabulary is noted world wide (courtesy of numberous cop shows) as being made up of mainly Irish emigrees. I wonder if there is some connection?
I understand exactly where you are coming from, and again, you are reflecting the way society is oriented.
Any code change costs money, so anyone who is commercially engaged in software development under a free market economy will limit the number of changes that are made to a released product to what has to be changed (for security, for competitive reasons, for all sorts of reasons best understood by the developer). Rarely will a developer add gratis features, saving them for inclusion in the next release.
The model in use by Microsoft (and many others) is to give a product a certain life span (look at cars, or fashions, or cameras, or just about enything you can purchase for examples of product life cycles), and once the market is effectively saturated by a product, it is time to bring out a new one to replace the old, and again, certain decisions have to be made in what to include in the new product.
In the case of Office 2007, I believe, on balance, that Microsoft has probably chosen wisely to renew the menuing system in the major Office products. For Joe Average, the number of options available in the itty-bitty menu available in "Classic" Office is very limited, and with the options getting steadily greater, something had to be done to improve that part of the experience (MS word, but I think it probably fits on this occasion). Like others, I'm still to be convinced that the approach taken is the besat one available, but then, I am not a human interface designer.
The learning curve is there, of course, but they have given even the most pesimistic a hole to lower that curve, by allowing anyone to tailor a toolbar for all your most needed icons, and that is probably the reason why I haven't found 2007 too difficult - I just rebuilt my old 2003 toolbar in 2007, and for most of the common activities, used that instead of using the ribbons.
I've never tried to use an Excel spreadsheet with more that 64000 rows, but I sure have used Excel in circumstances where I've run out of columns, and the learning curve of Excel 2007 (which I haven't found to be too difficult) is worthwhile for me, to be able to get to those extra columns! I'm only using the Beta so far, but the Home and Student version should be arriving in a month or so for $27 above the heavily discounted version of the 2003 Teacher and Student version that I just purchased (and which I will probably never install, because I've been using the Beta of 2007 at home since early in the public Beta cycle).
The ribbons are new, and can be frustrating at times, but as I've already been through DOS, DR-DOS and its pseudo-windows, WordStar, Multimate, LetterPerfect for DOS, WordPerfect for DOS, WordPerfect for Windows, and every incarnation of MS Word since Word 2, I guess I'll take it in my stride, just like I have the previous ones.
I'm over 60, and still am surprised how "stick in the mud" a lot of people a fraction of my age appear to be when it comes to changing what they are familiar with for something newer.
"It was good enough for Grandpa, so it's good enough for me!" is such a retro reaction to change that I'll never understand it.
Well, we have one who has been imported from the USA in charge of a major corporation here, and from what you can find out about him in his last incarnation up in Colorado, it looks as though the generation of explanations of this nature is one of his more natural talents, and probably the one he was employed to use.
I absolutely agree with that. The problem is that a CEO going out and saying that he is doing it to assist with the corporation's bottom line, for the benefit of the shareholders will be immediately pilloried by all and sundry as a money grubbing capitalist swine, where as if he obfuscates by telling everyone that it's "an expansive moce", or similar, the focus is removed from the bottom line, and some 9the share holders, at least) are convinced enough to go along with it. The government gets the blame, and the CEO gets his well earned raise / bonus for cutting costs.
The big problem that everyone misses is to do with the motivation of the people making the edecisions.
Presidents, CEO's, or whatever you want to call them, of big corporates do not answer to the people, or the workers, or the government. They areONLY answerable to the share holders. Their job is to maximize profit, and one part of that is to minimize cost.
If they ignore their responsibility to their share holders, then they are in breach of their employment, and are liable to be dismissed.
How do they minimize costs? Well, for a software production organization, the major cost is likely to be human (salary, wages, accommodation, perks, etc), and if they can mimimize those, then they will go a long way towards maximizing retrurns. Given the way that capitalism works, the easiest way to do this is by finding a source of labour which is cheaper to hirew, and cheaper to accommodate. Can this be done effectively in a first world country? Probably no. Do these corporations go overseas to recruit? Almost certainly. Does this lead to a loss of jobs? Definitely.
As someone who has been on both ends of off-shoring deals (globalization, as my last employer called it) I can definitely side with those who believe that outsourcing costs jobs in the host country. What is of more ocncern is that when you off-shore a swag of jobs to somewhere else - especially in the manufacturing sector - you must also effect the nations balance of trade (money going off shore instead of being spent locally, and products being imported instead of being produced locally).
What's the answer? I am at heart a free-trader, but on this one, the ONLY answer that I can see is to make it less profitable for the corporation to carry out this type of activity, and that would have to be a government initiative of some sort. Perhaps reimposition of tarrifs for imports from countries that are taking jobs from the host nation, or even some form of taxation on corporations that are trying to maximize profit by off-shoring jobs to cheaper countries.
You will of course have corporations fleeing to tax havens (like the Bahamas), but legislative action could, I suppose, be used to counter that, as well - perhaps a punitive tax on share earnings earned by your country's citizens and organizations, that were generated in those tax havens. It's woth thinking about, anyway.
I enjoy being a project manager more than I enjoy being a programmer under the post-sox constraints.
I wasn't trying to say that you couldn't turn a good programmer into a good PM, just that too often that step pushes the person to his/her level of incompetence.
Last big project I worked on had 186 staff, including about 45 testers, and the development effort was split between 5 teams of about 20 each, all reporting to a Progject Manager.. On that project, I was a Project team Leader, with the lives and work of 21 programmers, following a release plan that HAD to work like clockwork. That was over 5 years ago, and since then I've moved into process and quality, which is MUCH more fun.
In the process (no pun intended), I've learnt a LOT about how project management is handled, and how it should be handled, and have taken part in the journey for a BIG company from CMM Level 1, all the way to CMMI Level 5, and have seen first hand just what is achievable by teams that embrace good process, and the improvements in quality, accuracy and (importantly) the estimating process when good process and metrics are adopted.
Agreed, but not always possible, as the hard parts often fall into view AFTER you've done a lot of the work
"Who'd have thought that little bitty piece there would have caused so much trouble?"
Or, as a cartoon I have on the wall of my cubicle says: "We decided to save the total screw up part for the end".
I also once had an entirely approrpiate wall mounted cartoon that showed a really complex diagram of how the application was to work, with a gap in the middle, and the PM explaining the gap as
"Here, we're expecting a great leap of faith to fill in the missing detail."
It never does, of course.
Has anyone here not read Yourdan's "Death March"? If you have any interests in projects and why they fail, then get hold of this book for a good read.
Each time I come into your country, I am thumb printed, and I don't personally see why there is hysteria about this action. After all, if I am going to be law abiding while in the country, I should have nothing to fear from stored fingerprints or stored DNA. I'd have thought that only people with guilty consciences or nefarious intent would object to fingerprinting / DNA sampling. I reckon that if we were all subject to such scanning, a lot of so far unsolved crime would remain unsolved no more.
When do they satrt doing the same for US citizens entering other countries?
Simultaneous management of multiple requirements (possibly 5,000 competing business requirements competing simultaneously); time (not so easy when the scope of the project is creaping, but the deadline isn't, or the estimating process was off, or the requirements have changed.....) while keeping track of 1,000 action items, issues, defects and delivery dates at the same time. It's extremely easy to see when a Project Manager is inexperienced, or undertrained, or bored, or being overworked into an early grave!
For project Managers there is the ongoing need to maintain team cohesion, and team spirit, and still get the code out the door - tested and working perfectly, on time and under budget.
Like musicians, being a good programmer doesn't mean that you'll make a good Project Manager. Some of the best programmers out there would be dead in the water if put in charge of a real project, for no fault of their own, other than being totally unequipped to run a project.
As for delivering on time and on budget, it is a well known truism that the first 90% of the job takes 90% of the budget, and unless you are REALLY lucky, it's likely that the other 10% of the job will also take 90% of the budget....but I digress.
Everybody dumps on the top dog. Until he's no longer top dog, and the new top dog has to take the abuse.
In Australia, we know this as the "Tall Poppy Syndrome", for some reason. The tall poppies being the ones that get cut down first. A well known human phenomenon, where everyone wants to jump on and destroy anyone who has been more successful, or is more popular, or more well known (the Tall Poppy), than the rest of the crowd.
Oh, and we've been very good at it for many years! It's almost our national sport.
There are *some* genuine discoveries on that list, but most of it is garbage.
Most of it is meant in fun, which is very much a tradition amongst news outlets at this time of year throughtout the English speaking world (yes, even the Australian-English speaking world)
That doesn't make it "garbage" - just not meant to be taken seriously, and if you look at the rest of the site, you'd soon realize that was the case!
I'm just surprised that there wasn't an explanation for 42 in other than Douglas Adams' words in the list! Oh well, next year, perhaps.
WRT the 400 liters of methane a day, a number of years ago I watched with interest a documentary of an experimental house in India, which was built with a huge bladder under the floow, said bladder being filled with cow dung on a regular basis, and the resultant gas was being used to cook the family meals. looked like a good use for this by-product, and helped to prevent the release of methane into the atmosphere, which must be a good thing IMO.
There are some things that you can do much better (and more safely) in an airline sim than you could on the real thing, such as:
* Simulate in-air emergencies, and practice the measures required to get through them safely (engine out, lost wheels, wheels jammed, that sort of thing) so that if the pilot ever needs to address the emergency, he/she has the knowledge, and the instincts, to tackle it correctly
* Simulate events such as loss of power on take off / aborted take off, without the risk to a real plane
* Encounter wind sheer without dumping a plane on the ground
* Stalls and spins
* Emergency landings
* Bad weather / instrument flying
To name but a few. And I'd rather ride behind a co-pilot who has practised what hhe/she needs to do in an emergency, than behind someone who theoretically knows what to do, but who has never practised the manoeuvre because of air safety issues.
BTW, the silly idea that MS FSX (or earlier) could be used to train a terrorist to be an airline pilot is just that - a silly idea!
I'm surprised at the number of "asking for code samples sucks" replies. I don't disagree that being able to think through a problem is important, but no more important that the quality of the finished product.
I agree, and that's why I suggested desensitizing some code that he/she has written, and using that, and why getting someone else to write it is really a stupid idea. If you didn't write it, you have no control over the quality, you can't sensibly discuss why you did it in a certain way, and you certainly don't show your prospective employer just what you're capable of.
Having said that, when interviewing prospective programmers (I don't do it any more, having risen to the glorified ranks of QA Manager), I would instead of asking them to produce code, give them some code to look at (nothing extra fancy, or complex), and ask them to give me their impression of the style and quality of the code that they were looking at. I found that very enlightening, as the newbie, or poor programmer, often had no opinion as to coding styles, while the experienced coder would recognise redundant of\r badly formed code quite quickly. We are, of course, talking here of 3GLs, and early 4GLs, so I really can't comment on whether this approach would work with today's crop of languages.
If you don't, then follow the advice of the anonymous coward above.
If you do, then you either provide some modules that you have written, or cobble up modules that work in a similar way, but which do not break any confidentiality agreements you may have - in other words, desensitize the code, and make sure you can explain the problem (in generic terms) and the solution that you chose (and why).
I'm surprised that anyone today is asking for code samples, unless they are looking for some esoteric language that you are expected to know before you start work for them - if that is the case, the ability to explain the problem, and the way you solved it, with demonstrative code that supports your explanation, would probably be the best approach IMO.
I didn't read the original question - just the text of the post.
Who owns any part of an application? The group who is paying fopr it, of course!
The analysts don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to develop good, solid specifications.
The programmers don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to develop good, solid code.
The DBAs don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to maintain a sound data base structure, that meets the needs of the owner.
The testers don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to identify and eliminate defects in the product BEFORE it hits production.
The QA person / people don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to make sure that the development has been carried out using all the mandated procedures, processes, forms and templates.
The operations guys don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to keep the application running properly.
The IT Manager doesn't own it - he/she isn't paying for it. He/she has RESPONSIBILITIES towards it, of course, because he/she is being PAID by the owners to run the department that provides and supports the application.
The users don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to work with the application, to the benefit of the owners.
So, we should be asking who is RESPONSIBLE for a particulr part of the development and deployment of new code, and I would answer ALL OF THE ABOVE!
Unless all of the above are involved in the decision making, they are put in a situation of responsibility without authority, which is totally unacceptable, and not tolerable by any of the groups involved.
So, communicate, communicate, communicate, and commit, commit, commit, and without commitment, don't proceed! And it, my friend, is the IT Manager's main responsibility to make sure is happening, efficiently, and effectively.
This sort of squabble is fairly common where people don't work together to make sure that what is advanced meets the needs of the company. The application doesn't belong to the developers, or the support guys, but belongs to the people who pay for it - the company.
Now that we have that out of the way, let's look at who says when something is ready to advance to the next environment, shall we.?
First, what model do you use? Do you develop in one environment, test in the next, and run in a production environment? Or do you develop and test in one, and run in production in another? Or something different to either of the above?
If you are using the three environment approach, then you need to get sign off from the developers before you move the code to test, and signb off from the testers before you move the code to production - but it doesn't start there, it starts when you are planning the changes.
Two environment development is more difficult, as the testers and the developers need to give each other space (time) for each to do their jobs properly.
Whichever you are using, don't ever give undercooked code to the tester(s) to work with - "oh, here's the code I want you to sign off on - I'll be updating it again tonight, and tomorrow night, and every night for the next week" is a sure way to lose those testers before you even start. "This is ready for test, and unless you find bugs in it, I don't intend to change it" is much better.
Changes come about for many reasons, but let's look at a typical application enhancement. Even in the smallest shops, there is some sort of decision made that the enhancement is wanted. That decision needs to include all the stakeholders - the users, possibly outside clients, the developments, any architecture team you may have, the Data base guru, support, testers, and operations. Get them involved up front, and you'll get less surprises later on.
Then there is the matter of pushing your code etc from Dev to Test. If the people I listed as being involved in the concept end are kept up to date, there should be no surprises when you come to moving the code to test (if there are, someone isn't communicating, or is ignoring, for whatever reason, communications that they have received).
The same applies to pushing from Test toe Production, only this time you MUST have the go ahead from users, because they are the ones who are possibly going to have to change their practices because of the changes.
I haven't even mentioned Configuration Management yet. Even if you don't use a configuration management tool ("we're too small and we don't make mistakes when advancing software etc, so we don't need it"(famous last words!)), you should consider a Config Management Board 9or if you don't like that term, a Config Management team, consisting of the same group that gave the go ahead to the development in the first place. That way, the people who need to communicate are also the people who have to make decisions, and the people who should have a say so in the go/no go decision before the code goes live.
Bug fixes should be handled similarly, but on a much shorter (typically hours not weeks) time scale. Involve all the players early,at least by email, and get buy in early, then hold them to their decision when time comes to move the change into production. No "one man security", either, if it is currently possible. The person who builds the code, the person who tests the code, and the person who moves the code to production should always be separate people - not one person carrying out three roles.
What next? Mainly communicate, and get acceptance / buy in from ALL parties early, and make sure that the buy in is kept current by alerting all parties of any changes that might affect their acceptance of the solution. No surprises at any stage is a real key here.
Slashdot Mirror
Irony is often lost between cultures - two peoples separated by a common language.
We have better weather, too!
I said that because I still tend to believe that law enforcement people (and that is apparently what the people who have taken these people are) tend to be at least honest enough not to put behind bars someone who they themselves believe to be innocent. In other words, I can't believe that the US would be party to the mass arrest of innocents, and their long term incarceration (5 years and counting) without trial, unless they had a fair amount of evidence that the people in question were guilty of the crimes that they were arrested for. After all, they have released a fair number of their detainees already, without trial, after apparently clearing them of any chargeable wrong doings.
The only new(ish) twist to this is it happening while the people concerned were in transit. I wonder which side of Immigration they were on? I know that back in the 70's, when I flew from Vancouver to Melbourne, I spent about 6 hours in a locked terminal in Hawaii, waiting for my plane to come in for the next leg from Dallas or somewhere like that, and there was no thought of putting the pax through immigration - we were all just in transit, and so effectively we were treated as never having entered the country. I've transitted through many other International airports over the years, and i have never been asked to pass through immigration while in transit, so I've never ever in fact entered those countries. Pity, I'd have liked all those interesting stamps in my passport.
If they didn't pass through immigration, how were they allowed to be arrested. I would have thought that they would be outside of normal US jurisdiction. Oh, well, such is life, I suppose.
Under that heading are such groups as the IRA, which only a few years ago (and perhaps today - I really have no idea) was raising funds in bars in New York (which has a large Irish descent population). No arrests there, that I know of, but then, the NY constabulary is noted world wide (courtesy of numberous cop shows) as being made up of mainly Irish emigrees. I wonder if there is some connection?
Alice's Restaurant will always have a special place in my heart.
And we all know WHY farts stink, don't we?
It's for the benefit of the hard of hearing!
Any code change costs money, so anyone who is commercially engaged in software development under a free market economy will limit the number of changes that are made to a released product to what has to be changed (for security, for competitive reasons, for all sorts of reasons best understood by the developer). Rarely will a developer add gratis features, saving them for inclusion in the next release.
The model in use by Microsoft (and many others) is to give a product a certain life span (look at cars, or fashions, or cameras, or just about enything you can purchase for examples of product life cycles), and once the market is effectively saturated by a product, it is time to bring out a new one to replace the old, and again, certain decisions have to be made in what to include in the new product.
In the case of Office 2007, I believe, on balance, that Microsoft has probably chosen wisely to renew the menuing system in the major Office products. For Joe Average, the number of options available in the itty-bitty menu available in "Classic" Office is very limited, and with the options getting steadily greater, something had to be done to improve that part of the experience (MS word, but I think it probably fits on this occasion). Like others, I'm still to be convinced that the approach taken is the besat one available, but then, I am not a human interface designer.
The learning curve is there, of course, but they have given even the most pesimistic a hole to lower that curve, by allowing anyone to tailor a toolbar for all your most needed icons, and that is probably the reason why I haven't found 2007 too difficult - I just rebuilt my old 2003 toolbar in 2007, and for most of the common activities, used that instead of using the ribbons.
The ribbons are new, and can be frustrating at times, but as I've already been through DOS, DR-DOS and its pseudo-windows, WordStar, Multimate, LetterPerfect for DOS, WordPerfect for DOS, WordPerfect for Windows, and every incarnation of MS Word since Word 2, I guess I'll take it in my stride, just like I have the previous ones.
I'm over 60, and still am surprised how "stick in the mud" a lot of people a fraction of my age appear to be when it comes to changing what they are familiar with for something newer.
"It was good enough for Grandpa, so it's good enough for me!" is such a retro reaction to change that I'll never understand it.
Well, we have one who has been imported from the USA in charge of a major corporation here, and from what you can find out about him in his last incarnation up in Colorado, it looks as though the generation of explanations of this nature is one of his more natural talents, and probably the one he was employed to use.
I absolutely agree with that. The problem is that a CEO going out and saying that he is doing it to assist with the corporation's bottom line, for the benefit of the shareholders will be immediately pilloried by all and sundry as a money grubbing capitalist swine, where as if he obfuscates by telling everyone that it's "an expansive moce", or similar, the focus is removed from the bottom line, and some 9the share holders, at least) are convinced enough to go along with it. The government gets the blame, and the CEO gets his well earned raise / bonus for cutting costs.
Presidents, CEO's, or whatever you want to call them, of big corporates do not answer to the people, or the workers, or the government. They areONLY answerable to the share holders. Their job is to maximize profit, and one part of that is to minimize cost.
If they ignore their responsibility to their share holders, then they are in breach of their employment, and are liable to be dismissed.
How do they minimize costs? Well, for a software production organization, the major cost is likely to be human (salary, wages, accommodation, perks, etc), and if they can mimimize those, then they will go a long way towards maximizing retrurns. Given the way that capitalism works, the easiest way to do this is by finding a source of labour which is cheaper to hirew, and cheaper to accommodate. Can this be done effectively in a first world country? Probably no. Do these corporations go overseas to recruit? Almost certainly. Does this lead to a loss of jobs? Definitely.
As someone who has been on both ends of off-shoring deals (globalization, as my last employer called it) I can definitely side with those who believe that outsourcing costs jobs in the host country. What is of more ocncern is that when you off-shore a swag of jobs to somewhere else - especially in the manufacturing sector - you must also effect the nations balance of trade (money going off shore instead of being spent locally, and products being imported instead of being produced locally).
What's the answer? I am at heart a free-trader, but on this one, the ONLY answer that I can see is to make it less profitable for the corporation to carry out this type of activity, and that would have to be a government initiative of some sort. Perhaps reimposition of tarrifs for imports from countries that are taking jobs from the host nation, or even some form of taxation on corporations that are trying to maximize profit by off-shoring jobs to cheaper countries.
You will of course have corporations fleeing to tax havens (like the Bahamas), but legislative action could, I suppose, be used to counter that, as well - perhaps a punitive tax on share earnings earned by your country's citizens and organizations, that were generated in those tax havens. It's woth thinking about, anyway.
I wasn't trying to say that you couldn't turn a good programmer into a good PM, just that too often that step pushes the person to his/her level of incompetence.
Last big project I worked on had 186 staff, including about 45 testers, and the development effort was split between 5 teams of about 20 each, all reporting to a Progject Manager.. On that project, I was a Project team Leader, with the lives and work of 21 programmers, following a release plan that HAD to work like clockwork. That was over 5 years ago, and since then I've moved into process and quality, which is MUCH more fun.
In the process (no pun intended), I've learnt a LOT about how project management is handled, and how it should be handled, and have taken part in the journey for a BIG company from CMM Level 1, all the way to CMMI Level 5, and have seen first hand just what is achievable by teams that embrace good process, and the improvements in quality, accuracy and (importantly) the estimating process when good process and metrics are adopted.
"Who'd have thought that little bitty piece there would have caused so much trouble?"
Or, as a cartoon I have on the wall of my cubicle says: "We decided to save the total screw up part for the end".
I also once had an entirely approrpiate wall mounted cartoon that showed a really complex diagram of how the application was to work, with a gap in the middle, and the PM explaining the gap as
"Here, we're expecting a great leap of faith to fill in the missing detail."
It never does, of course.
Has anyone here not read Yourdan's "Death March"? If you have any interests in projects and why they fail, then get hold of this book for a good read.
When do they satrt doing the same for US citizens entering other countries?
Simultaneous management of multiple requirements (possibly 5,000 competing business requirements competing simultaneously); time (not so easy when the scope of the project is creaping, but the deadline isn't, or the estimating process was off, or the requirements have changed.....) while keeping track of 1,000 action items, issues, defects and delivery dates at the same time. It's extremely easy to see when a Project Manager is inexperienced, or undertrained, or bored, or being overworked into an early grave!
For project Managers there is the ongoing need to maintain team cohesion, and team spirit, and still get the code out the door - tested and working perfectly, on time and under budget.
Like musicians, being a good programmer doesn't mean that you'll make a good Project Manager. Some of the best programmers out there would be dead in the water if put in charge of a real project, for no fault of their own, other than being totally unequipped to run a project.
As for delivering on time and on budget, it is a well known truism that the first 90% of the job takes 90% of the budget, and unless you are REALLY lucky, it's likely that the other 10% of the job will also take 90% of the budget....but I digress.
We came, We saw, We wopped their collective asses!
In Australia, we know this as the "Tall Poppy Syndrome", for some reason. The tall poppies being the ones that get cut down first. A well known human phenomenon, where everyone wants to jump on and destroy anyone who has been more successful, or is more popular, or more well known (the Tall Poppy), than the rest of the crowd.
Oh, and we've been very good at it for many years! It's almost our national sport.
Most of it is meant in fun, which is very much a tradition amongst news outlets at this time of year throughtout the English speaking world (yes, even the Australian-English speaking world)
That doesn't make it "garbage" - just not meant to be taken seriously, and if you look at the rest of the site, you'd soon realize that was the case!
I'm just surprised that there wasn't an explanation for 42 in other than Douglas Adams' words in the list! Oh well, next year, perhaps.
WRT the 400 liters of methane a day, a number of years ago I watched with interest a documentary of an experimental house in India, which was built with a huge bladder under the floow, said bladder being filled with cow dung on a regular basis, and the resultant gas was being used to cook the family meals. looked like a good use for this by-product, and helped to prevent the release of methane into the atmosphere, which must be a good thing IMO.
Neither do I, and it looks like I'm not alone in that. Please explain?
* Simulate in-air emergencies, and practice the measures required to get through them safely (engine out, lost wheels, wheels jammed, that sort of thing) so that if the pilot ever needs to address the emergency, he/she has the knowledge, and the instincts, to tackle it correctly
* Simulate events such as loss of power on take off / aborted take off, without the risk to a real plane
* Encounter wind sheer without dumping a plane on the ground
* Stalls and spins
* Emergency landings
* Bad weather / instrument flying
To name but a few. And I'd rather ride behind a co-pilot who has practised what hhe/she needs to do in an emergency, than behind someone who theoretically knows what to do, but who has never practised the manoeuvre because of air safety issues.
BTW, the silly idea that MS FSX (or earlier) could be used to train a terrorist to be an airline pilot is just that - a silly idea!
I agree, and that's why I suggested desensitizing some code that he/she has written, and using that, and why getting someone else to write it is really a stupid idea. If you didn't write it, you have no control over the quality, you can't sensibly discuss why you did it in a certain way, and you certainly don't show your prospective employer just what you're capable of.
Having said that, when interviewing prospective programmers (I don't do it any more, having risen to the glorified ranks of QA Manager), I would instead of asking them to produce code, give them some code to look at (nothing extra fancy, or complex), and ask them to give me their impression of the style and quality of the code that they were looking at. I found that very enlightening, as the newbie, or poor programmer, often had no opinion as to coding styles, while the experienced coder would recognise redundant of\r badly formed code quite quickly. We are, of course, talking here of 3GLs, and early 4GLs, so I really can't comment on whether this approach would work with today's crop of languages.
If you do, then you either provide some modules that you have written, or cobble up modules that work in a similar way, but which do not break any confidentiality agreements you may have - in other words, desensitize the code, and make sure you can explain the problem (in generic terms) and the solution that you chose (and why).
I'm surprised that anyone today is asking for code samples, unless they are looking for some esoteric language that you are expected to know before you start work for them - if that is the case, the ability to explain the problem, and the way you solved it, with demonstrative code that supports your explanation, would probably be the best approach IMO.
Who owns any part of an application? The group who is paying fopr it, of course!
The analysts don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to develop good, solid specifications.
The programmers don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to develop good, solid code.
The DBAs don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to maintain a sound data base structure, that meets the needs of the owner.
The testers don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to identify and eliminate defects in the product BEFORE it hits production.
The QA person / people don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to make sure that the development has been carried out using all the mandated procedures, processes, forms and templates.
The operations guys don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to keep the application running properly.
The IT Manager doesn't own it - he/she isn't paying for it. He/she has RESPONSIBILITIES towards it, of course, because he/she is being PAID by the owners to run the department that provides and supports the application.
The users don't own it - they aren't paying for it. They have RESPONSIBILITIES towards it, of course, because they are being PAID by the owners to work with the application, to the benefit of the owners.
So, we should be asking who is RESPONSIBLE for a particulr part of the development and deployment of new code, and I would answer ALL OF THE ABOVE!
Unless all of the above are involved in the decision making, they are put in a situation of responsibility without authority, which is totally unacceptable, and not tolerable by any of the groups involved.
So, communicate, communicate, communicate, and commit, commit, commit, and without commitment, don't proceed! And it, my friend, is the IT Manager's main responsibility to make sure is happening, efficiently, and effectively.
Now that we have that out of the way, let's look at who says when something is ready to advance to the next environment, shall we.?
First, what model do you use? Do you develop in one environment, test in the next, and run in a production environment? Or do you develop and test in one, and run in production in another? Or something different to either of the above?
If you are using the three environment approach, then you need to get sign off from the developers before you move the code to test, and signb off from the testers before you move the code to production - but it doesn't start there, it starts when you are planning the changes.
Two environment development is more difficult, as the testers and the developers need to give each other space (time) for each to do their jobs properly.
Whichever you are using, don't ever give undercooked code to the tester(s) to work with - "oh, here's the code I want you to sign off on - I'll be updating it again tonight, and tomorrow night, and every night for the next week" is a sure way to lose those testers before you even start. "This is ready for test, and unless you find bugs in it, I don't intend to change it" is much better.
Changes come about for many reasons, but let's look at a typical application enhancement. Even in the smallest shops, there is some sort of decision made that the enhancement is wanted. That decision needs to include all the stakeholders - the users, possibly outside clients, the developments, any architecture team you may have, the Data base guru, support, testers, and operations. Get them involved up front, and you'll get less surprises later on.
Then there is the matter of pushing your code etc from Dev to Test. If the people I listed as being involved in the concept end are kept up to date, there should be no surprises when you come to moving the code to test (if there are, someone isn't communicating, or is ignoring, for whatever reason, communications that they have received).
The same applies to pushing from Test toe Production, only this time you MUST have the go ahead from users, because they are the ones who are possibly going to have to change their practices because of the changes.
I haven't even mentioned Configuration Management yet. Even if you don't use a configuration management tool ("we're too small and we don't make mistakes when advancing software etc, so we don't need it"(famous last words!)), you should consider a Config Management Board 9or if you don't like that term, a Config Management team, consisting of the same group that gave the go ahead to the development in the first place. That way, the people who need to communicate are also the people who have to make decisions, and the people who should have a say so in the go/no go decision before the code goes live.
Bug fixes should be handled similarly, but on a much shorter (typically hours not weeks) time scale. Involve all the players early,at least by email, and get buy in early, then hold them to their decision when time comes to move the change into production. No "one man security", either, if it is currently possible. The person who builds the code, the person who tests the code, and the person who moves the code to production should always be separate people - not one person carrying out three roles.
What next? Mainly communicate, and get acceptance / buy in from ALL parties early, and make sure that the buy in is kept current by alerting all parties of any changes that might affect their acceptance of the solution. No surprises at any stage is a real key here.