To me the largest factor in determining whether the 1.0 release of something will be acceptable is time.
Given enough time for proper design and testing, a 1.0 release could be acceptable, but companies hiring consultants do not want to pay for the time, and companies that produce software for the general public have to rush products to market to beat company X, whose competing product is due for release, and (more importantly?) they need to please their stockholders.
Over the last 8 years I worked for 2 different companies. One was a 100 y.o., engineering-oriented organization. Whenever undertaking any significant new project, they did the kind of detailed, complete, time-consuming analysis that you describe, followed by a similarly thorough implementation. That company still exists and is doing OK, with a reasonable if not spectacular profit margin.
The second company didn't do any of that. When a decision needed to be made, they spent about 10 minutes looking at it, then made a choice. Rather than doing detailed project plans, they would constantly reassess and make direction changes. Their belief was that it was far better to do something and start getting feedback than spend too much time in analysis. This company also does pretty well, with a higer profit margin than the first.
Which approach is better? I don't know, but it was quite a culture shock going from one to the other! However, one thing is for sure and that is that people who are wedded to the "analyze-project manage" way of doing things (think PMI) are firmly convinced that the "fire - ready - fire - reaim" method is nothing but disaster waiting to happen. I am no longer so sure.
Hell, if software just had to do what it was doing in 1970, it would be more perfect than refrigerators.
Except that I have spent the last six years implementing ERP software that isn't as well-designed and doesn't do the job as well as equivalent MRP II systems from the early 1970s! I would actually say that software quality has regressed quite a bit since 1980!
Software likes to think of itself as 'engineering' but it's not. It's not structured, it's not methodical, it's not repeatable, it's not quanitatively quality controlled, it's not maintainable, it's not documented correctly, it's not impervious to new flaws after it's finished, it's never finished. Project managers don't [...]
Well, it can be (think aircraft control systems). It just generally isn't. Which tells us that there is some reason(s) buyers don't want well-engineered software.
Those reasons probably are (a) first cost of purchase (b) competitive advantage to be gained by using something "good enough" sooner rather than something perfect later.
Which doesn't excuse the behaviour of software suppliers, but the question is more complex than it appears.
Just like cars, refrigerators and houses, the quality of what you purchase is not perfect. And you should not expect software quality to be perfect any more than you expect your car to be perfect.
Get a refrigerator from 1950, another one from 1970, and one from 2001, and set them side-by-side. Make sure each one is the basic model, with no fancy gee-gaws or "futuristic controls".
I submit to you that the 2001 refrigerator is approaching perfection. Thermodynamic efficiency is approaching theoretical maximum, reliability is approaching 99.99999%, sound is down to essentially nothing, and the price in real dollars is about 1/10 that of the 1950 model.
Why? Because refrigerator makers (like auto makers) made a committment to improving, and attempting to perfect, their product.
Now, you can say that software hasn't been around as long as refrigerators, which is probably true (although it has been around since 1940, and the quality of what was done in the 1970s is often better than today's). However, the profit margin on software is also tremendously higher than that of white goods, and the rewards for management much greater. Yet the software industry refuses to clean itself up.
And BTW: The A-11 (or A-12 which was its real name) didn't have any guns or missiles, it was a pure reconnaissance plane.
Well, Ben Rich's version of the story disagrees with yours a bit. Of course he may not (and probably did not) tell the whole of the truth, but most of what he wrote corresponds with the public record.
There are a few companies out there that are honest enough in their internal culture to treat offers and counter-offers as pure business propositions. Cypress Semiconductor was rumoured to be one such, although I don't know personally.
However, 99.99% of organizations will behave exactly as the 10 reasons describe. Yes, I know, it was corporate employers who destroyed the idea of corporate loyalty in the 1980s. It is corporate employers who dump their long-timers to reduce medical costs and grab the pension money. It is corporate employers who will lay off 10,000 people to get a 1% pop in the stock price.
But the very same people who do these things will turn around and destroy the career of a person who accepts a counteroffer. Why? They have "shown disloyalty". Doesn't make sense, I know, but that is the way it is. Take the original offer and don't look back.
VIFF (Vectoring in Forward Flight) was the Harrier's ace in the hole during the Falklands war. A Harrier pilot can use his plane's VSTOL capability to instantly alter the pitch of a turn or cause a pursuer to overshoot.
Well, the RN let that rumour get around during the South Atlantic Engagement. General concensus is that the Harrier is not a very good dogfighter, and that the "ace in the hole" actually consisted of (a) SAS teams hidden on the Argentinian mainland, watching the airfields and notifying the fleet at sea when to expect strikes (b) a new model of Sidewinder AAM, which magically appeared in the magazines of the RN despite it not yet having been released for general use by the USAF (which paid for it).
General Dynamics sold their fighter business to Lockheed. I believe (although I don't have any references at hand) that when the F-14 and A-6 upgrades were terminated that Northrup also terminated their high-performance aircraft division. Certainly nothing of the old Grumman "Iron Works" is left.
But this whole - 'Boeing's plane was ugly' thing is sensationalistic journalism. The author throws it out there and then goes on to show that the author alone holds that opinion. It didn't make sense to me.
Respectfully, I would have to disagree.
If you have spent any time around high-performance airplane people, you know that (a) the looks of the airplane are in fact very important to them (b) in a situation like the JSF bake-off, they would know better than to ever say anything about that (and certainly not put it on paper).
So given the choice between two pretty good planes, one of which was ugly and one not, I don't doubt that the decison would be shaded toward the not-ugly one.
Now, if the ugly choice had been the only workable one, even the jet jocks would bite their tongue and make the right selection. But that wasn't the case with the JSF.
What are the differences? Why are there 2 new fighter planes coming out?
The F-22 is an air superiority fighter. It is designed to be able to destroy any other airplane in the sky, including other fighters, and maintain control of airspace. If it ever goes into operation, that is. It is intended to replace the F-15.
The JSF is really an attack plane, designed to hit ground targets, carry refueling tanks for other planes, and do similar grunt work. It really should be called the A-14, but flying anything with an "A" designation has been the kiss of death to an Air Force career since 1945, so all planes will be "fighters" in the future. JSF will replace the A-6, A-10, AV-8, and to a certain extent the F-18 and F-117.
I agree about the sensationalistic journalism. A plane shouldn't be solely picked cause its pretty. Its capabilities are far more important. Example would be the A-10's. They may be ugly but as conflicts have proved, they are invaluable at close combat support.
Problem is, your example contradicts your premise. It is well known in the Air Force that chosing the A-10 is the kiss of death to one's career. You want to make General, you fly the F-16. Similarly, although the A-10 is well-suited to its job and would be a great asset to the forces of the United States, 70% of those that were built are sitting in the desert waiting to be scrapped. Good at its job, but not sexy and not supersonic, so it has been the bastard stepchild of the USAF since the day it entered service.
1. Build aircraft that support a fragile and expensive pilot and be limited from a design and performance stand-point
Problem is, it is not entirely clear that you can take the human pilot out of the cockpit and put him 2000 km away without losing some critical capabilities. It seems to work in low-intensity situations, but the problem with war is that when you get into a high-intensity situation, nothing happens the way you expected it to happen. A human on the spot can integrate contextual clues and make an informed judgement. The operator far away in an air-conditioned van may not get the contextual clue that is critical to making the decision, since the designer didn't include a sensor for it.
The Mig-25 could fly so fast because it was designed to be able to intercept the A-11 spy plane (which later evolved into the better known SR-71). But the Americans didn't know that so they made an air superiority fighter out of "their" Mig-25. That's the main reason why the F-15 is so fast.
Actually, the MiG-25 is believed to have been designed to intercept the B-70. However, only two XB-70 prototypes were built before the program was cancelled; one crashed and the other is at the USAF Museum in Dayton OH. A very cool plane from an engineering standpoint.
Sorry, can't agree. The V-22 may be hulking and over-muscled, but if it is ugly, it is ugly in the way that a heavy-weight boxer is ugly. Which is to say, ugly in a way related to its function, such that the Marines would accept it.
So, no, Lockheed Martin did not, in fact, win the JSF as posted. Boeing did.
Living 10 miles away from the McDonnel-Douglas (Boeing) plant where Boeing's entry would have been built, had Boeing won, I can assure you that Lockheed did in fact win the competition. Which may very well lead to the United States having only one company capable of building fighter planes in 7 years or so.
OTOH, there is some speculation that Boeing doesn't care too much about losing JSF, as it is possible the action will switch to unmanned vehicles over the next 10 years. And they are way ahead of Lockheed in that area.
Now, anyone want to explain to me how the efficiency of that works out- you capture power from the jet engine (which is, itself, a big fan) and use it to drive a bigger fan on top of regular exhaust ducting... apparently that recovers more power than just running the jets, but I'm not sure I get how?
The Atlantic article discusses this, although not in any technical depth. Basically, the thrust-vectored jet engine (e.g. Harrier) must produce just about exactly as much downward thrust as the weight of the plane. I.e. if the plane weighs 15,000 kg, there can only be about enough thrust to balance 15,500 kg or so (ouch - I have forgotten the right units - multiply everything by g here I think). If there is less thrust the plane will crash, obviously, but if there is more thrust, the excess energy has to go somewhere. And since the exhaust is quite hot, that excess energy goes into melting runways, setting aircraft carrier decks on fire, etc. So a thrust-vectored design must necessarily always be on the verge of crashing while in hover.
Whereas the key point of the fan-supported design is not that it uses HVLP (high-volume, low-pressure) reaction, which it does, but that the exhaust is cold, so you can use as much of it as you want, and keep as much excess energy in reserve as you might need. According to the article, the first time they turned it on, intending to hover at 10 cm or so, the plane shot up to 10 m!
This was a breakthrough idea, similar to the invention of the original Harrier. Lockheed received a patent on it and everyone in the aerospace industry feels it was well deserved.
Funny thing is, at one point the JSF team was considering confiscating Lockheed's patent and giving it to McDonnnel-Douglas (Boeing), as Lockheed couldn't keep their program under control.
The compass and protractor are as obsolete as the sextant. If a kid graduates from school and doesn't know how to work a PDA, he's going to quickly learn how to work a deep fryer.
I had an ME professor who did consulting work for the nuclear industry. The NRC (US Nuclear Regulatory Commission) staff had done a 2-year, $10 million project to develop a computer model of crack propagation in reactor vessel heads.
The professor attended the meeting where the model was presented to the appropriate body for approval. He took one look at the results, then wrote down three equations that showed the model was fatally flawed.
In fact, his motto as a teacher was, "If you can't solve it in half a sheet of paper, you don't understand the problem". A little bit of an exaggeration in the real world, but not by much. {BTW - one of my classmates had his calculator battery go out during the final exam, which was worth 70% of the grade. He was freaking out, so I handed him my calculator without a word. Didn't need it, and those were some of the hardest problems I solved in engineering school.}
There is a difference between being able to do something by rote, and understanding what you are doing. I use calculators as appropriate but I don't use them where inappropriate, such as foundation classes.
The employees (kids) have a behaviour choice to make. That choice has a logical consequence associated with it. If they choose poorly, there will be a consequence to their choice, and it is their problem, not yours. Your job as an admin (parent) is to help them make an informed choice, provide sympathetic support when someone learns the hard way about a bad choice, and let them have the learning experience.
Would that life worked out that way. In reality, when the hard drive fails, you as the IT support person will be blamed for (a) not educating the users [despite the fact that they refuses all attempts at training] (b) not explaining the risks to management [despite the fact that you were bumped off the dept. heads meeting calendar for 20 weeks running] (c) not taking additional steps to protect users from themselves, given the critical nature of the systems involved.
Not fair, but that is what will happen. You may lose your job as a result, NOT the guy who failed to back up. And there may be some justice in that as well if you think about it.
Yeah thats a brilliant idea. Purposefully crash someones HDD to "drive a point home". Suddenly I'm not wondering why your looking for work in your sig.
Sorry dude - have to disagree there. The only way to really test disaster recovery plans is to engineer a "disaster". You have to get approval of directors/dept. heads first of course, but I have certainly showed up at some of my sites at 6 AM, shut down the server, put a red cardboard flame on it, and waited 'till my staff showed up. It is even better when you have the VP of Sales (ex-Marine) stop by every 10 minutes to scream about "money going down the drain". Makes an interesting morning for the staff!
Speaking as a person who had dealt with this both informally and formally since 1984, there is nothing you can do to force the issue in this situation. The employees view the "personal computer" on their desk as something personal, and they will fight against any effort for an outsider to control it (in the human mind, "backup regularly" = "fascist control". Don't ask me why, but there it is). And given the history of how PCs came to be used in businesses, this is not totally unreasonable.
So, you have two options: (1) If you have reasonablu fast network connections, take the choice away and install automated workstation-to-server software that runs every night. This won't work for roaming laptop users though. (2) Hold a series of "computer training classes". Say 4 or 5 half-hour classes where you teach e-mail ettiqute, tips and tricks, Internet searching, that sort of thing. Make them mandatory (you can usually finagle this through the HR or Training group of the parent org). At one of the classes, discuss backup, then pull out a form stating "I have attended the backup class and understand the consequences of failing to back up my work. My department and I accept full responsibility for failing to use backup tools provided". Require them to sign and turn it in (again, HR and Training will usually help with this). Send copies to the department heads.
That won't prevent data loss (or even the loss of your job if something goes wrong!), but it will help somewhat and also get at least some people thinking.
[IBM] just sold their Hard disk unit to [H]itachi. And a few days later they report a new storage format. Makes you think.
I just opened the front door to my house. And a few seconds later it started to rain really, really hard.
You might want to take a class in game theory and business strategy. The difference between the first post and your counterexample is that IBM very definately has non-public knowledge about (a) the future prospects of hard drive technology (b) potential replacements for mechanical hard drives. Given IBM's need for continued growth, if they have a technology in house that they think has, say, a 33% chance of replacing hard drive, it would make perfect sense to sell the hard drive business for 20 billion and invest 6 billion in the new technology. A gamble, but with a potentially huge payoff.
What if one's data contains dimpled chads? How will those bits be counted?
The funny thing is when I am done voting I always turn the card over and check for chads. After the Florida thing I mentioned this to my spouse, who gave me one of those "only someone like you would think of doing that". I finally realized it was a result of the many hours spent in front of an IBM 029 keypunch, followed by 4 hours waiting for the card deck to come back from the machine room. When one hanging chad can kill a day's work, you tend to check for such things. But I imagine the percentage of people with that experience is getting lower by the day.
If you go to any of the top CS schools in the country, you'll see where most of the top of the class goes-- Microsoft. The general consensus among students in the CS dept I attend is that people working for MS are real badasses. And it's the truth. The guys working for MS REALLY know what they're doing.
Sorry to have to disagree with you a bit there, dude. Compare Novell Netware 3.11 to MS LANManager 1.1 or 2.0. Compare Novell Netware 4.1x to NT 3.5. Compare Novell NDS to Active Directory (a bit harder to do, since AD was released 3 years late and 5 years after NDS). Compare Lotus Notes (or hell, even cc:Mail) to Exchange. In every case you will find that the former product was created by people who sat down and thought, really thought, about the problem domain. The resulting products may not have been perfect, but at least the creators put in some effort. While the corresponding Microsoft product was just a pale imitation (can you say "rip-off"?) of the originating product, CLEARLY created by people who DO NOT understand the problem domain but are just imitating what they have seen elsewhere.
Microsoft Excel might be the only exception to this rule, but even there M$ started out copying Visicalc/Lotus.
Slashdot Mirror
The second company didn't do any of that. When a decision needed to be made, they spent about 10 minutes looking at it, then made a choice. Rather than doing detailed project plans, they would constantly reassess and make direction changes. Their belief was that it was far better to do something and start getting feedback than spend too much time in analysis. This company also does pretty well, with a higer profit margin than the first.
Which approach is better? I don't know, but it was quite a culture shock going from one to the other! However, one thing is for sure and that is that people who are wedded to the "analyze-project manage" way of doing things (think PMI) are firmly convinced that the "fire - ready - fire - reaim" method is nothing but disaster waiting to happen. I am no longer so sure.
sPh
sPh
Those reasons probably are (a) first cost of purchase (b) competitive advantage to be gained by using something "good enough" sooner rather than something perfect later.
Which doesn't excuse the behaviour of software suppliers, but the question is more complex than it appears.
sPh
I submit to you that the 2001 refrigerator is approaching perfection. Thermodynamic efficiency is approaching theoretical maximum, reliability is approaching 99.99999%, sound is down to essentially nothing, and the price in real dollars is about 1/10 that of the 1950 model.
Why? Because refrigerator makers (like auto makers) made a committment to improving, and attempting to perfect, their product.
Now, you can say that software hasn't been around as long as refrigerators, which is probably true (although it has been around since 1940, and the quality of what was done in the 1970s is often better than today's). However, the profit margin on software is also tremendously higher than that of white goods, and the rewards for management much greater. Yet the software industry refuses to clean itself up.
Oh well.
sPh
sPh
sPh
However, 99.99% of organizations will behave exactly as the 10 reasons describe. Yes, I know, it was corporate employers who destroyed the idea of corporate loyalty in the 1980s. It is corporate employers who dump their long-timers to reduce medical costs and grab the pension money. It is corporate employers who will lay off 10,000 people to get a 1% pop in the stock price.
But the very same people who do these things will turn around and destroy the career of a person who accepts a counteroffer. Why? They have "shown disloyalty". Doesn't make sense, I know, but that is the way it is. Take the original offer and don't look back.
sPh
sPh
sPh
If you have spent any time around high-performance airplane people, you know that (a) the looks of the airplane are in fact very important to them (b) in a situation like the JSF bake-off, they would know better than to ever say anything about that (and certainly not put it on paper).
So given the choice between two pretty good planes, one of which was ugly and one not, I don't doubt that the decison would be shaded toward the not-ugly one.
Now, if the ugly choice had been the only workable one, even the jet jocks would bite their tongue and make the right selection. But that wasn't the case with the JSF.
sPh
The JSF is really an attack plane, designed to hit ground targets, carry refueling tanks for other planes, and do similar grunt work. It really should be called the A-14, but flying anything with an "A" designation has been the kiss of death to an Air Force career since 1945, so all planes will be "fighters" in the future. JSF will replace the A-6, A-10, AV-8, and to a certain extent the F-18 and F-117.
sPh
sPh
sPh
sPh
sPh
OTOH, there is some speculation that Boeing doesn't care too much about losing JSF, as it is possible the action will switch to unmanned vehicles over the next 10 years. And they are way ahead of Lockheed in that area.
sPh
Whereas the key point of the fan-supported design is not that it uses HVLP (high-volume, low-pressure) reaction, which it does, but that the exhaust is cold, so you can use as much of it as you want, and keep as much excess energy in reserve as you might need. According to the article, the first time they turned it on, intending to hover at 10 cm or so, the plane shot up to 10 m!
This was a breakthrough idea, similar to the invention of the original Harrier. Lockheed received a patent on it and everyone in the aerospace industry feels it was well deserved.
Funny thing is, at one point the JSF team was considering confiscating Lockheed's patent and giving it to McDonnnel-Douglas (Boeing), as Lockheed couldn't keep their program under control.
Anyway, a very good article all around.
sPh
The professor attended the meeting where the model was presented to the appropriate body for approval. He took one look at the results, then wrote down three equations that showed the model was fatally flawed.
In fact, his motto as a teacher was, "If you can't solve it in half a sheet of paper, you don't understand the problem". A little bit of an exaggeration in the real world, but not by much. {BTW - one of my classmates had his calculator battery go out during the final exam, which was worth 70% of the grade. He was freaking out, so I handed him my calculator without a word. Didn't need it, and those were some of the hardest problems I solved in engineering school.}
There is a difference between being able to do something by rote, and understanding what you are doing. I use calculators as appropriate but I don't use them where inappropriate, such as foundation classes.
sPh
Not fair, but that is what will happen. You may lose your job as a result, NOT the guy who failed to back up. And there may be some justice in that as well if you think about it.
sPh
sPh
So, you have two options: (1) If you have reasonablu fast network connections, take the choice away and install automated workstation-to-server software that runs every night. This won't work for roaming laptop users though. (2) Hold a series of "computer training classes". Say 4 or 5 half-hour classes where you teach e-mail ettiqute, tips and tricks, Internet searching, that sort of thing. Make them mandatory (you can usually finagle this through the HR or Training group of the parent org). At one of the classes, discuss backup, then pull out a form stating "I have attended the backup class and understand the consequences of failing to back up my work. My department and I accept full responsibility for failing to use backup tools provided". Require them to sign and turn it in (again, HR and Training will usually help with this). Send copies to the department heads.
That won't prevent data loss (or even the loss of your job if something goes wrong!), but it will help somewhat and also get at least some people thinking.
sPh
sPh
sPh
sPh
Microsoft Excel might be the only exception to this rule, but even there M$ started out copying Visicalc/Lotus.
sPh