was he ever kind?? Linus Torvalds, Richard Stallman, Steve Jobs, me...Gates was merely the guy that capitalized from idiots. Not king like behaviour to me. More like con-artist
but why? why did the survey around the nation prove that he is the man ,who is most admired and adored. i have heard they said two great men in America, two Bill!! when Bill Clinton was still a president. do you go to an extreme, or is the price for Windows too high? Please Register or Log in to view the hidden image!
Gates is a brilliant business man. He is very quick, very intelligent (brilliant, really), and (of course) very lucky. He was the right person in the right place at the right time when he started Microsoft. He was smart enough to realise this and lucky enough to be right.
I'm not a fan of his products or his conduct but he is undeniably the king. What is makes a king a king after all? Money, influence and power. In each catagory he's at the top
if game companies would make game for linux we would be free of microsofts spyware and vulnerability, i am running my internet thru a linux firewall to be safe but windows still pisses me off
I am not sure, it is supplied as an example to illustrate that students pay more attention to successful business man. Most of them want to be millionaire----the only dream.
Someone has ventured into my own area of expertise: software process improvement. Bill Gates's fifteen minutes of fame will end, probably within the next ten years. He'll probably get to keep most of his money but unless he gets a conscience transplant or retires, Microsoft will fade away like the American makers of those 5,000 pound, 13 mpg, only-stable-going-in-a-straight-line automobiles of the 1950s and early 60s. Gates's and Microsoft's attitude about quality assurance (their motto is "we can't even spell QA") is causing ever greater problems for users of the so-called information infrastructure, and ever more of those users are wising up to the fact that this is no joke. For the goddess's sake, hackers are finding wormholes in Windows XP that have been there since it was Windows 95. This product has defects that have gone undetected in tests and code inspections ("what's a code inspection?" is another Microsoft motto) for nine years, about six major and untold minor upgrades. That is absolutely pathetic. No corporate board of directors would survive a stockholders' election if it allowed its programming staff to do such a shoddy job of developing and maintaining its in-house software. Why should it have to settle for that abysmal level of quality when buying shrink-wrapped commercial software supposedly built by "professionals"? The revolution has begun. The legislature of the Spanish province of Extremadura passed a law that all computers for sale in the province must have their hard drives wiped clean of Windows and loaded with Linux. They have a gussied-up version of Linux with some of the icons and wallpaper replaced with Spanish symbols and scenery, and it's available for a free download from the government website. Sure, Extremadura is a small province without a lot of economic clout so this started out as a largely symbolic middle finger (actually in Spain I think it's the fist in the crook of the elbow) to Microsoft. But... funniest damn thing, after about two months the provincial government noticed that way more copies of "Linex" had been downloaded than there are people -- much less computers -- in the province. Turns out that people all over Europe, especially in Italy, were taking advantage of the offer. Meanwhile, Apple has come out with VirtualPC, an emulator which will do a decent job of running most not-too-complicated Windows-architected programs under OS/X. And they've quietly chartered a corporate sales branch. Linux, Macintosh -- and the armies of people who simply refuse to upgrade from Windows 98 and/or who run Mozilla or some other non-IE browser on their PCs as a way of staying out of the virus and trojan horse fast lane. Microsoft keeps saying the numbers of these people are too small to be a concern... but this is the company that can't do any math more complicated than balancing its bulging checkbook. The numbers are growing and the growth is accelerating. Almost every large company already has a Mac shop in its advertising department, because most creative, artistic people simply refuse to spend one second of their day learning to be software mechanics. The disparity between the tranquility of people actually devoting their time to doing their jobs in the Mac room and the people screaming about lost files, user-hostile interfaces, and projects a year behind schedule in the production departments keeps increasing and is not going unnoticed. IT professionals who used to dismiss Macintoshes as "toy computers" are now using them at home. (I sure as hell am.) A whole generation of kids who became Mac-literate in school is entering the workforce. And how about the -- what, 95 percent? -- of the world's population that doesn't own a computer yet? All the hungry, extremely well-educated people in the former Soviet bloc are just about at the cusp of their economic recovery and ready to gift the world economy with scores of new IT sectors. Want to bet that some of them are going to wonder why the hell they should saddle their own people with a PC architecture that is based on an 8080 with a monochrome, text-only interface, stand-alone processing, and a 1.4 mB floppy disk drive and has had everything else hung on it with paper clips and chewing gum? Maybe they'll thumb their noses at intellectual property laws and build cheap Mac clone hardware and software for their people. An operating system that gets thrown away with every processor upgrade so you've always got operating systems and applications built to contemporary software engineering standards instead of inherited from the software-development-as-a-medieval-craft philosophy of the 1980s. Or maybe they'll forge out on their own and develop a new architecture with a new operating system. Something fresh out of the 21st Century built by people who have learned from the mistakes of their predecessors. (Microsoft builds software with major flaws that we mainframe jockeys banished thirty years ago, such as deadlocks, application-layer programs crashing the operating system, and clandestine instructions sneaking in masquerading as data.) As the rest of the world enters the Computer Age, they will leave Bill Gates in the dust. As I said, he will get to keep his money because there's no justice in the universe. But he won't get to keep his title. And by the way, any American who's grooming their kids for a career in IT isn't paying attention. Don't yell at me, it's all Bill Gates's fault.
major problems is how gates makes people buy softaware, he says that this lalest version has none of the bugs he put in the last 1 what he doest say is that he has added a whole new set in order to claim that on the next version
As a mac user, gates is essentially satan in my book. But to be fair, part of window's vulnerability derives from the fact that it's ubiquitous. Their OS is used by the greater majority so that makes them the biggest target. Don't get me wrong, I find the comparison between windows and OSX similar to an abacus compared to a cray computer. Basically, I wouldn't trade my mac if you gave me free pc's for life but linux, mac and other competitive OS's have a security advantage just because their market share is too small a target for hackers to bother when compared to windows. my point? I'm not really sure. I just hate when people over-do the evils of their opposition. Window's is crap... we all know that much, no need to exaggerate.
I can't say that I agree that Windows is crap. Other than the IE ActiveX exploits, most Windows problems are caused by most Windows users being too ignorant. I've run a mfcr-installed WinXP Home for two years before upgrading to XP Pro about a year ago (Win2K is supposed to be even better for those that know what they're doing). I can honestly say that I have not had one piece of spyware on this computer, no unwanted popups, nothing wrong at all (exception: I got a worm the day I upgraded, between when I booted up the computer and finished running Windows Update, but that got fixed by the time I was done with WU). I run myself as administrator and my parents as users (without any rights), that way my dad can use his favorite IE without my having to worry about his installing anything. I don't have a password, so they can install something without my being there, but have to go out of their way (and usually talk to me first anyway).
Your whole post, except for this,: consists of MS & Gates bashing. As for this statement: Jeeze! There's no justice in the universe? Bill Gates is evil? He's the leader of a coorporation that produces low quality products that consumers want. Obviously, Microsoft (or any other company) will not rule forever but Bill Gates and MS made (and are still making) their mark. As Bill Gates being evil, I'll say it again, Someone has to be the richest in the world and I don't mind it one bit that it's Gates. Who's your favorite Billionaire? At least he's doing some good with his fortune.
Warren Buffett. He's a good old-fashioned limousine liberal. He doesn't believe in offshore outsourcing. When he gets control of a company, its employees end up with better leadership, less overtime, more job security, and the commitment of a bottomless source of capital to weather economic downturns. I was excited to learn that he took an interest in WalMart and bought a big chunk of its stock. As he acquires more power over the company whose motto was originally "Buy American," you'll probably start seeing fewer products for sale in WalMart made by people who took jobs away from Americans. Yes ok. Bill Gates is not Satan. He has a social conscience. He's a decent limousine liberal as far as he goes. If I were the goddess I'd probably not strike him dead with lightning. My objections to him are 100 percent professional. As a guru in Bill Gates's own profession, I know better than most people that he could have done better and still become filthy rich. He just didn't bother because he knew he could get away with it. To say that he builds crappy software that America wants is just too facile. Hardly anyone on Earth, even citizens of the country that started the computer revolution, knows enough about IT to know how good PC software could have been -- to second-guess Bill Gates. Americans don't know that every IT project should start with a risk analysis. If the odds of completing the project successfully are not good, then it has to be sent back to the people who thought it up and have its risks covered. Americans don't know that about 75% of the requirements of every IT project are not stated; they are either implicit or unconsciously expected. You can't just get a bunch of people to think up the requirements for a software product and then go off and start building it. You have to inspect the requirements, looking for the ones that are missing, the ones that conflict with each other, the ones that are impractical, the ones that are incomplete, the ones that are misstated, the ones that were tossed in because they seemed like fun but aren't really necessary. Americans don't know that building software is not like turning widgets out on an assembly line. Every software project builds exactly one widget. If it doesn't work, you can't toss it in the reject bin and sell your customer the next one off the line. You've got customers waiting impatiently for their one widget, while you run the "assembly line" backwards, correct the step in the process that caused the widget to fail, and then run it forward again. Americans don't know that you can't test quality into software. You have to build it in. Software defects have to be caught as soon as possible after they are injected into the product. Defects in requirements have to be found and fixed before they are turned into design specifications. Defects in specifications have to be found and fixed before they are turned into code. Software testing is fairly good at identifying defects in code, but not defects from the earlier phases in the project. And at that, testing is only about 30 percent effective. Code must be inspected just like the requirements and the specifications. People who write the avionics software that controls the airliners we ride in don't throw the code together, load it onto the airliner's computer, get on board, and see if it flies. And they certainly don't ask the airline's customers to get on board and see if it flies! Avionics project managers have proven that it is possible to build software with zero defects. Of course you can't build commercial software to the standards of avionics. It would take too long and cost too much. We don't need commercial software to be quite that good. If it fails once or twice a year, if it doesn't do exactly what we want but comes close enough to get the job done, if the interface has a quirk or two that we can work around, we can live with that while we're waiting for Release 1.1. But there's a huge gap between that quality standard, which is well short of the quality standard of Airbus's avionics software project managers, and the quality standard of Bill Gates's software project managers. The sad part is that it doesn't have to cost a lot to build higher-quality software. In fact, it's not clear that it has to cost any more than it does to build it the Microsoft way. Investing more money and attention and oversight in the early phases of a software project actually makes the later phases run faster and cheaper by giving the programmers and testers fewer surprises to stop and fix. In any given week, there is at least one software development conference and several seminars going on where these principles are explained clearly. It's not rocket science. It's simply a matter of treating software development as a genuine engineering discipline with repeatable processes and measurable goals, rather than as a black art that either succeeds or fails. Microsoft should not build one more piece of software until every single employee has been to a few of these conferences and seminars, and the company comes up with a formal software development methodology that can be managed, measured, assessed, and improved. Warren Buffett is getting his people to do that. (There's a professional reason that he's my favorite billionaire.) It's not only possible but downright practical. Software built by the IT departments in the Berkshire-Hathaway companies generally works right the first time out. Their programmers rarely get called out of bed to fix a problem that's preventing the users from doing their business. They have software process improvement teams and they are constantly finding ways to build software better, without making the process slower or more expensive. Bill Gates could do it too. He just doesn't goddamn want to because he just doesn't goddamn care because he's making enough money selling us junk. And that, friends, is what I have against him, and why I think his company will go down the toilet in the next ten years.
Good.I am assuming that you are working for Berkshire Hathway and follow Warren's Long term Value Investing poilcies?...He's my favorite too. How do you know that?.In,recent article,his most close associates say that his next aquisition is going to be Outsourcing Groups from India(yes,mind you India) who have long term monney spinning potential for him.Read Time Mag.last month probably. Why is that? i assume you have worked for Microsoft? How can you say these things?.My cousin has worked for Microsoft,People at MS are highly professional and skilled.If you ever read S/w Engineering in your Life,you wouldnt have said such a thing.Never ever a Formal Methodology can be strictly applied in a software firm.Since these decisions are taken dynamically.Microsoft has High CMM levels.(Off course you will say thats because it has bought those things too.). And MS doesnt do a Risk analysis? hahahahah... Your thoughts are Gibberish.Did you write all of this to impress upon a point or to demonstrate it using meaningful arguments?... Fraggle, While i have been a great Fan of Warren Buffet and his Value Investment strategies,i am told that e doesnt buy much of I.T. stocks since he has lesser knowlege of the Business. Even our Favorite Warren Admires Bill and his amazing group. This was taken from : Buffet-Bios bye!
Warren Buffet and Bill Gates are good friends, by the way. Share a common interest in the game of Bridge, if I'm not mistaken (which is very much a game of memory and intelligence, not to mention maturity and patience).
I've done work for B-H companies and have a lot of respect for most of them. As for investing, I don't have enough capital to be a real player, but I do have money in a fund that includes B-H stock. Well that's too bad. But everyone makes mistakes and corrects. Let's hope he sees the error of his ways. He has no need to make more money, but the Foundation that he and his recently deceased wife founded is his pride and joy, and just became bigger than the Gates foundation. It does some of the best and most effective charitable work on the planet and Buffett wants to keep it going. In any case, I wouldn't judge him prematurely, he's a long term thinker. Perhaps he's got a clever idea of a way for India to become prosperous without simply transferring prosperity from America. That would, after all, be consistent with his style, and one of the hallmarks of the Information Age is that wealth is much easier to create now. The measure of a software firm is not the professionalism and skill of its employees. It is the quality of its products. It is a damn shame, but despite the fact that Microsoft the company does indeed employ a whole lot of really good people, Microsoft the component of our economy produces abominable software. Of course not, but a good methodology is flexible and scalable, and the first step in any project is to choose the best methodology for the job. The incessant bullshit that I and my coworkers and 99% of the Windows user community put up with every single day is adequate evidence that Microsoft has not found a superior alternative to the state of the art in software engineering methodologies, and in fact is simply squandering the talents of all those good people who work there. Sperry-Univac, not exactly one of the best loved names in the history of IT, built more defect-free software thirty years ago. Apple makes Microsoft look like a something from the pre-industrial era. I wouldn't accuse anyone of doing anything that nefarious without evidence. It's just that the CMM is like democracy, it's a great idea but it's not sufficient. You can adopt the CMM and still build crappy software. But if you have people in charge who honestly believe in the CMM and understand it, the metrics you get from your projects will tell you soon enough where (or more likely who) your problems are and you can start fixing them. The fact that Microsoft's processes don't ever improve is clear evidence that Bill Gates genuinely doesn't care about making the CMM work and therefore genuinely doesn't care about his customers. That's yesterday's news. He's woken up and has realized that one cannot be a major player in the Information Age economy without knowing anything about IT. He's just taking it slow so as not to make any beginner's mistakes. He recently acquired a stake in Amazon.com, and the heads of the B-H companies are finding themselves under increasing pressure to improve their IT organizations in ways that imply that someone has been brought in that does know a lot about IT. Or as someone else said, Buffett and Gates are friends. Big deal. Gabriel García Márquez and Fidel Castro are friends too. Friendship is a type of love, and love of any sort follows no rules. Perhaps he will teach Bill Gates a thing or two about being an honorable billionaire and how to contribute to the U.S. economy instead of dragging it down with software that doesn't satisfy its requirements. There's no reason to automatically assume that Gates's habits will rub off on Buffett. After all, which is the elder?
Take a look at their Style of Working (If you were aware of that) 21 Rules of Thumb for Shipping Great Software on Time Jim McCarthy, Microsoft Corporation * * Shipping great software on time is a difficult but not impossible task. Elements you think would count the most count for very little. Development methodology, process, technical prowess, excellence of tools and depth of project management skills all influence the outcome of a software development project; but nothing indicates success as much as the manager?s ability to focus on a few critical and conceptually simple things. These things can be expressed as rules of thumb. I enumerate twenty-one of these rules of thumb. Pick a handful (or so), apply them, and your project will be more likely to succeed. I lump them into three groups: "Shipping," "Great Software," "On Time". Duh. I cover them in a different order, because the concepts build a bit. On Time * 1. Don?t know what you don?t know. * It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn?t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you. * Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don?t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty. * The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convert your ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being. * You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance rather than naively converting it to falsehoods. Bear down on them until they realize they haven?t comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite. 2. Get to a known state and stay there. The function of QA is to know (and articulate) the quality of the product at all times in the development cycle. This should be achieved by abbreviated, repeatable tests conducted daily, and full product sweeps conducted weekly or biweekly. It is not properly the job of QA to determine when a product is ready to ship; rather, the moment of shipworthiness in a product development cycle is evident to everyone involved, and is non controversial. This is because shipping has been the goal of the entire effort. Crossing the finish line, while it has intangible emotional and definite financial rewards, is no surprise when you?ve observed every single painful step toward it. The only reason you?ve been able to make these micro-observations is because you got to a known state and stayed there, and your QA is how you did it. Achieving a relatively accurate view into product status is a very challenging goal, requiring a highly motivated and competent QA team. It is also a pre-requisite for success. Many software development organizations have rudimentary or no real QA assets, and there is little that can be done for them until they make the appropriate investments in creating a modern development organization. A known state consists of all components having accurate status information at a given point in time. You know that it?s accurate because the status has been tested by QA. A developer articulating the status of his/her component is an exercise that does produce information, but if it happens to communicate the component?s status, it is only coincidental. This is someone else?s job. Status should consist of a comprehensive listing of tested and missing functionality, bug count sorted by severity, bug arrival rate, bug fix rate, projected total bug count, and other vital metrics. 3. Remember the triangle. There are only three things that you are working with as a development manager: resources (people and money), features and the schedule. Changing one has an impact on at least one other axis, usually two. It is a simple enough matter to mentally run through the sides of the triangle, or force others to do so, when discussing any part of it. Since the people, the product or the schedule is almost always what you?re discussing, this means that you must constantly envision the triangle. This leads to the most fruitful line of thought. 4. Don?t go dark. Some features have long development lead times, months or even years. Yet slips usually happen a little bit every day, and must be compensated for a little every day. This means that the granularity of development tasks must be such that deliverables are achieved at intervals sufficiently small that slips can be compensated for. A week is a long time to go without knowing what is happening. While micromanaging is always a danger, and will certainly be an accusation leveled against you from time to time, if the goal of the project is to ship great software on time, and if everybody accepts that goal as uppermost, they generally enjoy the chase. Team interdependency is also a powerful motivational force. 5. Use zero defect (ZD) milestones. Organize the project around the concept a reaching milestones with zero defects. Zero defects does not mean that the product does not have bugs, or missing functionality; it means that the product achieves the quality level that had been set for that milestone. The product is tested to that effect. The essential point of ZD milestones is that nobody makes the milestone until everybody does, and nobody leaves it until everybody does. This enables the team to discover what aspects of the project are in trouble. Load balancing can occur. Awareness of unknowns rises. At a milestone, the team and its leadership also have the opportunity to perceive the whole project status simultaneously, to draw conclusions about erroneous practices, to remedy bad design decisions and to reorganize for peak performance. Shipping is just the final milestone. Though the external organization cares most about shipping, which adds special pressure to that milestone, the team develops extraordinary focus and introspection about each and every milestone. 6. Beware of a guy in a room. This is really just a special case of "Don?t go dark." Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to shipping great software on time. Without regard to their individual brilliance, before investing a developer with a significant assignment, it is essential that they understand and agree with the type of development program you intend to run. They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and though there is a role for people of this disposition in the software world, it is not as part of a team devoted to shipping great software on time. There are many pathologies at play here as well as certain healthy patterns of creative behavior. One pathology is a type of savior complex that cannot be satisfied without blowing every single deadline but the last, and then emerging victoriously with a brilliant piece of work five minutes late. A more healthy pattern is that of the true innovator who is truly designing something great, but who has no personal resources left over for anything but the work at hand. Every ounce of psychological, emotional and intellectual energy is being consumed in the work itself. Teamwork, in this case, is an insignificant factor to a person immersed in this sort of creative experience. But whether or not the cause is healthy or bogus, the results are uniformly fatal to the professional development organization. Beware. Extricating yourself from this trap is nearly impossible. 7. Never trade a bad date for an equally bad date Generally, you know you?re going to be late before you know when you?re going to be done. Further, everybody on the team and everybody they come in contact with knows you?re not going to hit the schedule. The pressure to reset the end-date (or the milestone date) is enormous. Even though your information is obviously better now than when you originally set your goal, it is probably insufficient to make a new schedule. This is because with each slip, you and your team are spending your credibility. It is essential that after a slip, the next milestone be hit. This is so the team believes in their ability to manage the project, and so that the reserves of credibility are rebuilt for later consumption. It is difficult to say precisely and in all cases when you should "officially" slip. A good general rule is that the schedule should be reset when the total extent of the slip is known for each component, the causes of the slip are understood, and remedies are in place. Usually, this takes the effort of the entire team and its leadership, and must be an explicit, focused activity. After this level of work is achieved, create a new, closer and more conservative milestone which the team is very likely to hit, and promulgate that. Avoid just sliding the schedule out. Your near-in milestone should be extremely realistic, and uncertainties about later milestones will remain and should be highlighted. 8. When slipping, don't fall. Slipping is what happens when information that was unknown becomes less unknown. Though slipping is widely perceived to be a "bad" thing, it is the symptom of a good thing, as a fever is the sign of the body?s immune system at work. Although it is undesirable to have so many unknowns that slippage occurs, it is not an unusual situation, and may even be the norm. This is because much of contemporary software development is essentially experimental, i.e., new platforms, new operating systems, new programming technologies often coalesce on new programming projects to create a high degree of uncertainty. * In order to avoid calamity, certain measures should be undertaken in connection with a slip. Ideally, one or more of the pre-identified unknowns caused the slip. It is important that everybody involved understand that the risk to the schedule had been known previously. Alternatively, it is essential to understand how the unknown/s had come to be overlooked. How this gap occurred should become part of the group knowledge for future success. Also, determine whether or not people are working on the correct things. Often, slips occur because members of the team become occupied with features of marginal consequence, or features that are not part of the core product message. * If the slip was a surprise, your communications system is broken, and dramatic communications efforts are required. Large amounts of detail must be brought to the surface for everybody on the team to see. Assess the reality of all current near-term estimates. Expose denial. Team defensiveness will have to be pushed back for the purposes of group learning. Slips reveal your team?s weaknesses, presenting a good opportunity for insightful management and mentoring. Make sure that each individual who has a role in the slip receives the needed guidance and support. * Slips are also an opportunity to re-evaluate the feature content and resource loads, generally with an eye toward decreasing the features and shoring up weaker areas on the team. * A good slip should be a net positive. * 9. Low tech is good. * A smaller effort is almost always more desirable than a larger one. Shipping great software on time requires that we value an understood solution much higher than one fraught with unknowns. Keep in mind that customers would almost always rather see progress than promises. * 10. Design time at design time. * The product will ship when the design can be shown to be implemented. Developers and their managers often ignore the exigencies of time when creating a design. Instead, they should consider the implementation time as a critical design element. When evaluating alternative design decisions, the one that takes longer to implement is consuming more time and should therefore be disadvantaged in comparison to the alternative. This must always be weighed. Often, when appropriate design value is awarded to timeliness, implementation time can be substantially compressed. * 11. If you build it, it will ship. * Conversely, if you don't, it won't. The product should be built every day, along with all setup scripts and on-line help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack. This is the single biggest indicator that a team is functional and a product being developed. * * * 12. Portability is for canoes. * And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible. * * * Great Software * 13. Enrapture the customers. * Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws. Often, the market has grown uncomfortably dependent on software that doesn't meet its needs. In many software situations, customers spend hours per/day uncomfortably shoe-horning their lives into your product. As a consequence, they crave your understanding, and will respond enthusiastically to the least sign of it. Normal success, meeting customer expectations, means to improve the most outrageous and flagrant violations of their needs from version to version. They will likely stay with you if you are faithful about that, though they may well be sullen if not mutinous. * Great software, however, requires that you pivot your entire technology so that it flows in the direction of their deepest needs. You must innovate in ways that clearly affirm their inarticulate desires. Surprise them by articulating and resolving in your product concerns and fantasies that heretofore had been rumbling about only in their pre-conscious. The fantasies of the market are generally centered on issues of empowerment, control and security. The market wants to be able to do things with its computers that it currently can't. Customers often find they can't even publicly admit these needs for fear of computer illiteracy. They derive value and security from being able to apply your software. To admit that they can't do what they want to do requires a sense of security beyond most customers? reach. * Market understanding is the foundation of great software. To repeatedly demonstrate through a series of two or three releases that you genuinely understand the market will result in enormous customer loyalty and brand equity. You will be viewed as the source of the market's empowerment. They will be rapturous. * Gaining this understanding and embodying it in your software requires skill, tenacity and creativity. You must recognize the central market need and organize all your technology and communications efforts in the direction of satisfying that need. While good listening, careful observation and concept testing will be required for you to identify the correct need, addressing it in your product will have these effects: * 1. It will appeal to the customer's sense of security. * 2. It will extend the customer's control. * 3. It will be such that if all else were dropped from your product, but the central need was met in unique ways, the product would be compelling. * 4. It will clarify your product messages. * 5. It will simplify your product's use. * * * 14. Remember one thing: Unity. * Unity is the master principle of great software. Each element in the product is necessary to the value of the whole and all necessary elements are there. Since everything you need is there, you aren't tempted to go beyond the present experience, and since nothing is there that isn't required, your absorption into the world of the product will not be disturbed. Unity of purpose and unity in execution should be the hallmark of your team. Unity is achieved in a product by following certain creative principles (#15-#19, below), whether intuitively or consciously. * 15. State your theme. * Theme is the dominant idea that constitutes the basis of the design. All of the values of the product must stem from the theme. In order for people to comprehend the theme, it must be rendered with surpassing clarity. Theme is analogous to purpose. The more specific the purpose, the greater the effect. Having a theme to the product will require that you eliminate or at least minimize orthogonal values. This is painful and involves risk. * 16. Vary it. * Variation is the theme restated and elaborated in slightly altered and embroidered ways. Variation is the means by which we intensify the user's comprehension and appreciation of our theme, and leverage his/her growing consciousness in new ways. * 17. Balance it. * Allocate appropriate emphasis among the various elements of the product. If a key component supporting the theme, encountered every time the thematic function is enacted, is weak, the theme is weakly stated and the product will be justly criticized. * 18. Evolve it. * Evolution is when earlier parts determine later parts. Lessons learned in one part of the product apply to the others. Things progress in a way that is pleasing. Outcomes, if not predictable, are satisfying because the product foreshadows them in countless ways. * 19. Your product should be a hierarchy. * Hierarchy is when the elements of the product gain attention in proportion to their importance. Closely related to the property of balance, hierarchy provides a means for establishing and evaluating balance. If the theme is the top of the hierarchy, elements at the next level have balanced value with respect to each other, all equally supporting the thematic function, and so on throughout the rest of the hierarchy. * 20. Establish a shared vision. * It seems absurd to even have to state this, yet it is perhaps the most difficult thing of all to achieve. Everybody on the team must know what they are trying to achieve, what the finished product will look like, what the basis of the product strategy is, and when they must deliver it in order for it to have its intended effect. Contradictory visions must be resolved and unified. Harmonious purpose must be achieved, or greatness is out of the question and even shipping becomes infinitely more complicated. * * * Shipping * 21. Get the team into ship mode. * There is a moment on every development project when it is ideal for a team to enter ship-mode. Ship mode is a high performance period characterized by efficiency and determination. It is a period of flow. Before a team can enter ship mode, several pre-requisites must be satisfied. * 1. Shipment must be the next milestone. * 2. Everybody (or nearly everybody) must believe that achieving the milestone is possible. * 3. All members of the team must understand precisely what they must do prior to shipping. All unknowns are factored out. * 4. Management must lead the team to ship mode by entering ship mode first. That is, superfluous management hoo-ha is eliminated, the manager?s awareness of detail climbs, fire-drills and other de-prioritizing activities are eliminated entirely and tremendous focus is brought to bear. * 5. The team must desire to ship. Generally, a complete awareness of the effect of shipping (or not shipping) will create desire. * The team becomes especially vigilant about thinking things through, and looking for traps. Check-ins are made with extra precaution. Stabilization of the product is the principle goal. All development is complete but for bug fixing. * The endgame, the last stage of shipmode, is different yet again. It is conceptually a very simple exercise. There is a list of activities. When every activity on the list is complete, you ship. Though the list might have hundreds or thousands of items, it is still just a list. There is no time for any effort that does not contribute toward completing the items on the list. Everybody is expected to complete their items as promised. As unanticipated items arise, after appropriate resistance, they are put on the list. * A daily meeting should be established, with final decision-makers in attendance. Agenda is ad hoc, assembled at the beginning of each meeting. No item is postponed that can be handled now. The team is aware that all issues can be brought to this meeting for expeditious remedy. Management is involved, leading the team toward their goal. * The goal is an acceptable quality level at ship time. Only showstopper bugs should be addressed at all. Showstoppers are bugs that will either effect more than a handful of users or will cause unacceptably serious errors. Cosmetic changes, performance enhancements, new functions are not appropriate changes. The purpose of beta feedback during this period is to prove there are no showstoppers, provide advance warning of unanticipated market reaction and provide input to the next release. * Understand the range of quality that is acceptable to your customers. How many low priority bugs did your product ship with last time? Was it a problem? Are the customers better off with this product including this bug? Since destabilizing the software is more of a problem than most bugs, be very careful about which bugs you fix. This is why we have "ReadMe?s" and bug lists. * Shipmode is basically a succession of daily milestones climaxing with the product?s shipment. * Many thanks to the staff and management of the Visual C++ Business Unit at Microsoft, from whom I learned and plagiarized these ideas. bye! *
