Actually (according to various news outlets over the past several years), these companies spend ten dollars on marketing for every dollar they spend on research/
Actually, the ratio is more like two to one. About 15 to 20% is spent on research, roughly twice that on sales and marketing.
Spin: (1) Marketing always delivers profits, research fails to deliver something useful 90% of the time. (2) There are millions of people who can do marketing, and only a handful who can do cutting-edge research.
This seems to go back all the way to the days when Netscape "incrementally evolved" HTML too, and frustrated developers commented that its next set of new HTML tags would probably be peek and poke.
The largest hole in our own (awful) password security must be this, and it has little to do with lazy users.
In our company, we must have about 50 different applications that require users to enter passwords; maybe more. Some were bought off-the-shelf, others were developed internally, and others were contracted out or written by consultants. Quite a lot of it was customized for us, or even developed entirely to our own specifications.
To the best of my knowledge, nobody of us has ever verified what actually happens to a password after it is entered in the login dialog. We don't do code reviews... at all. Password checking against the directory server is encouraged, to ensure that users need to remember as few passwords as possible.
So next time I log in to the financial software to file an expense note, the system may actually be mailing my password to John Doe, or to the competition. Who knows?
Well... Our own "high security" IT department not only issues shared account passwords with incrementing numbers, they have even suggested (and e-mailed) a standard procedure for turning your own name into a "secure" password by changing 'o' into '0' and such...
As long as the system algorithm accepts it and the password is changed every three months, they consider it must be secure. When I helpfully pointed out that changing 01 into 02 is not going to fool anyone, the answer was that the password cannot be guessed by others anyway, because the login screens allow only a small number of retries. This left me quite speechless, so I didn't push it any further. I could of course have said that it only takes lifting the keyboard and reading the post-it note. (IT doesn't like post-it notes stuck on top of keyboards, but they don't look underneath.)
Their holy grail is policy. If Policy Is Followed, It Must Be Good. If policy is not followed, they get bad points. The sobering reality is that their password policy must be making our systems considerably less safe, and it would probably be better if we had a less strict -- even allowing dictionary words -- but more reasonable set of rules.
Of course the patients where injected with parts of the virus that are not, in themselves, sufficient to cause disease.
The point is that, of course, cells are not part of a virus; cells are much bigger than as virus. Nor is DNA a part of a retrovirus such as HIV, which carries its genetic information in the form of RNA. Nor would it make sense to simply inject patients with parts of the genome, rather than selected (parts of) the proteins, in the hope that they would somehow develop immunity to proteins that are not even expressed.
So a phrase such as "The HIV-1 specific cells injected into the recipients were the DNA fragments of the virus which don't cause infection" betrays a painful lack of knowledge of virology and molecular biology, and gives no clue about the nature of the vaccine whatsoever.
The actual press release is more cautious than the excerpt that is quoted here; describing the result of the trials as saying that the vaccine is "safe and possibly effective." Apparently there were no ill effects, and if I interpret the text correctly, they detected antibodies against whatever these people were injected with. Which does not prove at all that the vaccine could be effective, because the envelope proteins of HIV are so variable that buidling up immunity is enormously difficult. However, it is probably as much as one could reasonably hope for in this first phase of trials.
That said, there is nothing in this press release to suggest that this vaccine trial will have a better outcome than the series of failed trials that have already preceded it. Mainly because there is very little information in this press release at all. Obviously, it was written by someone who did not have a clue about the science behind the trials; you can't tell from this what the vaccine consists of and how it is supposed to work. More worryingly, the "director of the National Institute for the Control of Pharmaceutical and Biological Products" is quoted as saying that "The HIV-1 specific cells injected into the recipients were the DNA fragments of the virus which don't cause infection." Which is nonsensical enough to suggest that the aforementioned director, who held the press conference, doesn't have a clue either. Probably he is more remarkable for his political skills than his medical ability.
But maybe these Chinese researchers are on the right track -- who knows? A vaccine against HIV is very much needed, and the hope that we will be able to create one seems to shrink with every new failure.
At the a fundamental level of software design, keywords like private and protected are used for good reasons. And one of them is to prevent writers of dependent software from relying on pieces of code that should not be considered part of the public interface, can change if the implementation (but not the interface definition) changes, or are simply too dangerous to mess with.
In my opinion, that can be legitimately extended to a wider level as well. If Microsoft feels that it is better to make only part of their interfaces publicly accessible, that should not only be their right, but also is simply a good conceptual design practice. Software authors who think that they can meaningfully improve their products by extending and deepening its OS and SDK dependencies are, in my opinion, simply wrong. (Even if the OS is not a Microsoft product.) It does nothing for quality, portability, or longevity of the code.
But if you feel that authors of Windows-based software have the right to understand the interactions with the whole Microsoft environment better, I would certainly agree. But this should not be achieved by having to delve in the obscure and volatile details of the code behind the public interfaces; an effort that is likely to be futile anyway. It should be achieved by designing and documenting the public interfaces properly; and that should remove the need to study the rest of the code. By definition of a good and properly documented interface, studying the code behind it should be superfluous. But forcing MS to waste work on documenting interfaces no sane person will want to use anyway, is not going to be a productive contribution.
As for them being unable to supply intelligible documentation -- yes, I am willing to believe that. Just by having a look at what they routinely supply as development kit documentation.
Obviously, Neelie is not a programmer and has never tried to write a program in a Microsoft environment, or even tried to figure out what their documentation is supposed to mean... If anything.
The example below is my favourite piece of Microsoftism, from the "I cannot believe that I am actually writing this" department:
And yes, this compiles and works. Surely there must be other gems of Microsoft protocols out there. Any other proposals?
I believe the Comission is wrong, and the companies that are lobbying the commission to get access to these protocols are even more wrong. We should not want more software that relies on more Microsoftisms. Au contraire.
I wish I had a list of the companies that are sueing for these protocols being made public. Then I would at least know whose software I certainly do not want to buy.
Well, the pharmaceutical company probably did spend somewhere between $400 and $800 million on the original development of the drug, so if it did not recover its R&D costs yet (and many drugs do not, not before the patent expires) then they may have a moral case.
I think this would be a good principle, if it could be generalized: Link the expiry date of the patent to the investment in it, or better to the return on investment. Say, minimum five years from the day of filing, plus a year extra for every $50 million that was not recovered from the R&D investment within that period.
That would mean that patents that are just sitting on the shelf without someone making an effort to develop a product would expire faster than they do now, while people who do invest in the development of a product are rewarded with extended patent rights.
After all the trouble Microsoft got in for bundling IE and Media Player with Windows, I would expect the people at Google (or Yahoo) to be a little smarter. Just how many million dollars do they actually want to get fined? I don't know about the USA, but the EU competition authorities do regard product bundling as an anti-competitive practice and illegal.
And frankly, Microsoft had at least a decent case that integrating a web browser and a media player in an OS makes sense, but bundling a search engine with a media player or a document viewer does not make any sense at all. Next they bundle them with the cornflakes.
One advantage the USA definitely has for technology startups is that basic research is funded with about $36 billion in public funds, i.e. roughly two-thirds of the basic research budget. That pays for a lot of research and potential business opportunities, and it is a spending level that most US competitors cannot hope to match.
Of course a discovery is not a product, and industry pays for most of the applied research and almost all the development. But it is basic research that provides the core around which a startup can condense. Or it keeps an industry alive and growing -- the success of the US aviation industry was to a considerable extent the success of NACA/NASA. And Silicon Valley started out from the base of Stanford University.
On overall R&D expenditure, the USA still outspends Japan and China by about a factor three.
Well, I have ever used PHP. But in my opinion the experience with bad languages such as BASIC (does anyone remember FORTRAN 77?) is not as exclusively negative as "ruining" people.
If you use "bad" languages a little, you will indeed learn bad habits. But if you use them a lot, you will be forced to learn at least some good habits, because otherwise you will lose vast amounts of time indeed. Bad languages do not enforce discipline, but they do teach self-discipline.
That said, I am reluctant to hire "experienced VBA programmers" and such - at least for serious work.
Well, I am a scientist, working in Europe not the USA, and my wages after (very steep) taxes are about $45,000 year, not including bonuses, employer's contributions to pensions and insurance, and other perks. For someone with my function that is below the market rate, but I am recently promoted to it. But I work in the private sector, not in an university.
I think that of my fellow employees, nearly one third are PhD scientists. For new positions, we head-hunt globally; the only continent from which we do not (yet) employ anybody is Antartica. In general we find it quite difficult to find people who are qualified for the jobs we are seeking to fill, and we often have to fall back to hiring people in the hope that they will grow into it. But oddly enough, although we have plenty of directors, marketing managers, and assorted business people from the USA (we are not based there, but are US owned), only a small minority of our research scientists was born and educated there.
It is not as if we have a filter in place to reject American candidates. We could not afford to. But they are just not there. Living standards here are considered slightly above what the USA has to offer, and certainly the food and the beer are a lot better, so in principle there is no reason why we should be unable to attract US scientists. As a matter of fact we do attract scientists from the USA -- they are just not American. Many of us have worked in the USA at one time. Personally, I have spent only a brief time there -- and characteristically, my US co-workers were immigrants themselves.
The truth is that there is a real shortage of US scientists, and there are many reasons for it. A low level appreciation by the public in general is certainly a factor; if you want to make money and be respected in the USA, becoming a scientist is somewhere well below lawyer and rap artist on your lists of options.
Another element, admittedly part of the former, is the pervasive anti-scientific climate in the USA. I agree with other posters that president Bush is not personally to blame for this. However, his plainly hostile attitude to science whenever it interferes with personal prejudice (or political expediency), is symptomatic for the disparagement of science that is festering in the circles that brought him forth, and has been so for quite a long time. This is a real enough phenomenon; America has been breeding a strange brand of religo-political conservatism that belongs more to the 18th century than the 21st. I am not sure whether it is an actual leftover from the revolution, or a new invention. Whatever its origin, it must be discouraging a lot of potentially great scientists, and it certainly has a harmful influence on scientific education.
The final factor, I think, is cultural. American science was flourishing in the 1960s, when there was a real spirit of discovery and advancement. Today, the country has become materialistic to the bone (even in its religion), and as a cultural motivation discovery has been entirely replaced by profit and practicality. Talk to an average American about what makes America great, and sooner rather than later he or she will say that Americans have fatter wallets than everybody else. Especially conservative Americans are standing every-ready to defend the USA's track record in terms of high GDP. It is a sad state for a country to end up in.
What is probably not a big factor is high school education. For what it is worth, US students are regarded as active and questioning by global standards; maybe they are a bit on the lazy side but they are respected for having probing minds and a willingness to ask questions. Such students should make excellent material for a university education in science; but too few of them choose to have it.
This served me well by way of a basic programming education, and when I was involved in restructuring the IT courses for science students we refined it but largely retained the concepts.
You should start with a two-part theoretical introduction. One half of that should lead to some broad understanding of the fundamentals of computers and their programming. History of computing, Turing machines, basic computer and CPU architecture, basic principles of computer networks, a cursory overview of machine code and assembler, basic concepts of different types of programming (object-oriented, procedural,...) languages and how they differ, relational vs. other databases, etc. The idea of this is to get the essential background and learn the jargon, so that if people throw new terminology at you, you can at least place it somewhere in the right context. The goal is not to get into any detail.
The other half of the introductory course should be rather more formal and very well understood before you start to do any programming. Crucial elements of are a good understanding of (boolean) logic and simple probability theory and statistics, a thorough introduction to data representation inside computers (data types, overflow and roundoff issues with data types, data conversion, arrays, pointers, linked lists, structures, etc., etc.) and a similarly strong introduction to control mechanisms (if-then structures, while loops, error handlers, etc, etc.) These are things that are important in almost any programming language, and a failure to deal with any of these correctly is a common source of bugs.
Once past the introductory course, you can lay aside the theory for a moment, and start programming -- seriously, not typing over simplistic examples from the textbook, but solving real if simple problems. You have to build up experience and the best way to do that is by slogging it out with a real problem.
It is best to pick a high-level programming language, and I advocate starting with an object-oriented one as it is easier to go from there to a procedural language than in the other direction. At this time I think Java might be the best choice; the essential tools for programming in Java are readily and freely available, and there is less risk of losing a student's time on obscure problems in Java than in say C++. These days C# also seems a reasonable option, but I have not yet studied it myself. And C++ might also be an option, but then at all cost avoid all Microsoftisms -- use g++ if you must.
Once you have some programming experience, it will be a good time to make a study of more advanced algorithms. (The disadvantage of using Java as a teaching language is that you will never be obliged to write your own quicksort.) The best way to understand these is to implement them, and you can't to that without some programming skills.
And when you feel that you have reasonable skills in one language, start learning another one. It doesn't matter which one, as long as it is different enough.
Quality arguments of this type are not confined to software alone. You will find the same reasoning in hardware engineering, and even in process engineering for manufacturing plants: There must be some balance between the benefit of solving a potential problem, and the adverse impact of changing systems in ways that often make them more complicated. So on the whole I find Sink's position reasonable enough.
Consider this one, however:
Vault's backend makes extensive use of features specific to Microsoft SQL Server. Contrary to popular belief, SQL isn't portable. Adapting the backend for any other database would take months, and the maintenance costs of two back ends would be quite high.
What this probably means is that Vault is relying on features highly specific to the Microsoft SQLServer engine, and that these external dependencies are not isolated behind some interface or localized in a specific module, but scattered all over the entire software. That's not a bug; that is a major design error. It probably implies that whenever Microsoft changes SQLServer in a version that is not 100% backwards-compatible, Vault's customers will have to put up with a lengthy series of minor and major bugs until they have all been ironed out. And if this is their design pattern, that may also be true for every other external dependency that they have. (Their line ending problem suggests as much).
As a potential customer, I would not care much about the length of the bug list, which actually says more about administrative neatness than about the stability of system. But I would be greatly worried about design errors like this, that fundamentally undermine the future of the system. If I buy it, it might turn out to be a millstone around my neck. And if a system is badly designed, it is also likely to contain more bugs and be less stable, because probably even it's programmers do not understand how it works.
Good fundamental design is still at the heart of develivering quality software. There is no replacement for it.
Relatively far-fetched, I would say. Look at the fluorescent proteins that probably make up most of that cited $100 billion per year (in 2000) for marine-biotechnology derived products. Very few people would use "wild type" fluorescent proteins for research, as these are not very efficient for our purposes. Instead researchers have developed the original jellyfish or coral proteins in entire families of mutated proteins with desirable fluorescent and other properties -- similar in structure, but a small change can turn a blue-fluorescent protein in a red-fluorescent protein.
The same is true for drugs. Pharmaceutical companies are looking for novel chemical structures and proteins in marine organisms to feed their chemistry libraries, but they are unlikely to be able to use these as drugs in their original form. Something an invertebrate uses as a toxin for self-defence may be a potential anti-cancer drug, but is likely to be too dangerous for use in humans. Instead chemists will study the structure-activity relationship for a family of related compounds in the hope of deriving a compound that is more active and safer. But that means that the end product will probably have to be synthesized.
Besides, it is an expensive chore to extract and purify a product that a primitive animal might be making minute quantities. It makes much more economic sense to go for expression in genetically modified cells.
By doing the letter by letter modulo 26 sum (a Vigenere encoding operation) of and smithysmithy... in Excel, I get
bmmblvlaamnnkmkzycsyypmispxfxgc
which is an interesting letter pattern and at least has a more natural letter frequency distribution than the original. The most frequent letters are m and y, which suggests that these could be e and i. As ii is not a frequent letter pattern, it is tempting to assume that m is e. However, the sequence is so short that such statistical assumptions are very risky.
And if there is a secondary substitution it must be more complex than a Caesar shift, for the +18 operation generates
teetdndsseffcecrqukqqheakhpxpyu
And others are not much better. This may be dead end. Or we may still have the wrong cypher sequence.
Yes, it can happen. Look for a example at recent drug trial incident in London, where a therapeutic antibody that had good results in animals (and apparently mild side-effects in monkeys) had dramatic and potentially fatal side-effects in human volunteers.
The effects are rarely that dramatic, as the worst effects are usually discovered in animal trials. (For added safety, at least two species are used, one rodent and one non-rodent.) However, unwanted side effects are the rule rather than the exception, and the only really reliable way to find out so far is through tests on human volunteers. Most drugs do fail in these trials!
Actually, even the drugs that do pass the clinical test stage and are approved rarely work for all patients. The FDA is happy if the drug helps a sufficiently large fraction of patients, and does not real harm except in exceptional cases. It is the average cost-benefit that counts, not the result for the individual patient, which is at this moment often impossible to predict.
For there is genetic patient-to-patient variation among humans as well, not to mention genetic variation among pathogens, and a drug that fits the protein in the body of patient A may fail to do so in patient B. And a drug that does A and B no harm may have fatal effects in patient C.
Genetic targeting of drugs has already caused a controversy around NitroMed BiDil, a heart medicine that is specifically effective for black patients — admittting that few Americans are of pure genetic "African" or "Caucasian" stock. The culturally acceptable (but scientifically dubious) solution is to allow patients to "self-identify" as black and therefore potential users.
For the future much hope is put in "personalized medicine", giving the patient a genetic analysis first to determine whether a drug would be really effective — or would have serious side effects. However, this too has obvious cultural and moral problems attached to it.
Many drugs work by binding to a target protein and inhibiting its activity in this way. However, there are several ways to achieve this. The conventional form of drug is a "small molecule", created by organic chemistry. These are called small because they are much smaller (and less complex) than proteins -- say more than a factor 10 smaller.
Small molecules can have enormous advantages: They are relatively easy to manufacture and to store, and if they are stable enough and well absorbed, they can be taken orally. If you want something simple and cheap for large-scale use, a small molecule is the way to go. However, the downside is that they are very complex and expensive to develop.
The other big category is that of the "biologicals", which includes proteins and peptides -- a peptide is essentially a small fragment of a protein, but still bigger than a small molecule. Antibodies are a category of proteins; in the case of antibodies, development is relatively easy because the body produces them naturally. There is also the possibility of taking a protein's natural binding partner, and then synthesising this on a large scale to outcompete the natural binding partner. The general expectation is that biogicals will be easier to develop than small molecules and for many diseases, will be the first form of treatment available.
The typical disadvantages of biologicals are that they need to be stored in a freezer, must be injected rather than swallowed or inhaled, and are expensive to manufacture. This usually restricts their use to relatively small numbers of patients, in hospital environments or receiving intense attention from their physicians. (Insulin is a well-known exception, however.)
Some people believe that small molecules are fundamentally unable to block certain interactions. The reasoning is that that something small can only attach efficiently to a target site if the available forces on that site are large enough, i.e. if there is a so-called "pocket" to fit the molecule in. While biologicals, because they are bigger, can bind over a wider area, so can be effective even if smaller forces are involved.
In this case, the scientists took peptides, which are relatively small, but instead of combining them into an actual protein (which would have been very complex and expensive) they grouped them together on the surface of a liposome, which essentially is a tiny droplet of fat. And the observation is that indeed, the interaction of the multiple peptides with the target still adds up, giving the liposome a much stronger binding to its target than the individual liposomes.
This creates numerous interesting possibilities. This might work with small molecules as well as peptides, for example; or you might even combine the two in a single treatment.
I wholeheartedly approve. For years, one of my biggest and most complicated tasks has been the transfer of data from source A to target B. Usually A is in a format that is undocumented and inconsistent. Reverse-engineering can be a nightmare when formats are badly designed (although that explains why they are often considered propietary) and used randomly. You would be surprised by the vast number of programmers who neglect to start a file with an identification tag and format version number.
I would happily go a step further than the MN proposal. I would require by law that all files produced by commercial software have to be in a formats that are documented and open, so that they can be read by any programmer skilled in the art and in possession of the documentation, which the supplier of the software has to give to you.
Actually anyone who creates a new format should be required by law to deposit its description in a public, easily accessible facility. A kind of Congressional or British library of file formats.
I am not totally opposed to patents on formats, but I would require any company that patents a file format to give any of its competitors a license for its use at small cost.
The website development and graphics are all contracted out. Only the content is developed in-house, by a scientific writer, so that we can be sure that it is both correct and well written. We can't ask web developers to check the content. I assume the legal department also checks it for any statements that various regulatory authories might object against. (Or adding SEC-required disclaimers etc.) I think that this in itself is a good model.
The biggest potential problem that I see is a tendency of upper management to try to influence detail design, and their unfortunate tendency towards glitz: Flash animations, rolling menus, ticker bars, high-resolution graphics, and the like. These might consume a lot of time and money and only rarely contribute to a good website. (One of the few happy exceptions I have seen is Nikon's microscopy training website, which is great.) But my personal preference would be for a site that is styled in a minimalistic way, light and fast.
Yes, the Soviets routinely did this as well. Strategy aside, they were always paranoid about espionage and unwilling to export their latest equipment for fear that it would fall in the wrong hands. Besides, they would also sell on a large scale to third world nations, who would find it difficult to maintain the most advanced equipment.
Selling high-tech defence equipment has always been as much about creating a dependency relation as about making money. (This much fighter jets have in common with cheap inkjet printers.) When you sell someone an expensive jet fighter, that country becomes dependent on you for training, spare parts, maintenance, and upgrades. Not just until the next version of Windows comes out, but for the lifetime of the aircraft, which is now as much as 30 to 40 years. A $25 million jet fighter without appropriate support is almost scrap metal.
Of course it is possible to go without support for some time. When Sadat kicked his Russian advisors out of Egypt, the Egyptians briefly considered fitting their MiG-21s with Rolls-Royce engines (would have been nice) before they bought Western equipment. More recently, Iran has been able to maintain US jet fighters in an acceptably operational condition without (officially admitted!) US support, but it clearly has not been easy and no doubt cost a frightening amount of money.
Weapons are by no means that standardized. Britain, France, Germany and some other NATO countries still develop their own missiles, and also various electronic and intelligence-gathering equipment, which is equally important.
The USA doesn't really like NATO weapons programs unless it can supply the weapons itself; its attitude is fundamentally protectionist and contains a lot of "NIH" syndrome. It has, for example, pulled out of the development of the ASRAAM missile and substituted its own AIM-9X.
For the UK, not having the source code might not only mean that it cannot integrate its own weapons, but also that it cannot sell its products to other JSF users. For example, ASRAAM has been sold to Australia for use on the F-18E. If JSF is a closed system, the USA could lock out any such competition and force buyers to purchase everything from US suppliers.
If that sounds paranoid... US officials have occasionally admitted that one of the goals of the JSF programme, at least it multinational aspect, is to drive other suppliers of combat aircraft out of business and ensure for the USA a monopoly on the supply of advanced defence equipment.
Of course one of the other reasons is to make foreigners pay some of the bills for US weapons development. The system is charming: participating nations have to pay a large fee upfront for allowing their industry to compete for JSF contracts. Then they are sold downrated equipment that is not as capable as the F-35 as operated by the USAF, USN and USMC (if it ever gets that far). One of the reasons the UK wants the source code, I assume, is that it wants to ensure that its aircraft will not be downgraded too much. (Nobody would take Washington's word for it... not any more.)
For the UK, JSF will be a bad deal. If the two planned RN large carriers are indeed completed, there is no real reason left to buy the F-35, and the British government may indeed be looking for a way to cancel its commitment to JSF.
This was at a time when the development programmes for advanced combat aircraft (and other military equipment) were successfully expanding into truly phenomenal cost overruns. The TSR-2 development cost estimates first doubled, and then tripled. The F-111 was so attractive to the UK government because its estimated unit price was about half of that of a TSR.2.
Of course, the UK had no monopoly on cost overruns, and McNamara's pet project went through the financial roof as well. The F-111 became even more expensive than the TSR.2 would have been. The TFX project that produced the F-111 tried to be all things to all people, actually rather similar to today's JSF project, and predictably it failed to do that. (You can easily guess my opinion of the JSF project.) The F-111B version for the US Navy was cancelled outright.
Besides, both the TSR.2 and TFX projects were arguably too far ahead of their time. The F-111 did not become a really effective combat aircraft before its first generation of pilots had retired, and its fragile 1960s electronic systems replaced by more modern and reliable ones. There is every reason to assume that TSR.2 would have suffered from the same problem.
I think the first step should be to look at better IT organisation and management strategies. The way many IT departments are run is still rather primitive; extremely self-centered and often based on reactive maintenance. While a good organisation should be driven by the business or project goals it is supporting, and have the efficiency of its contribution to these as its target.
While concepts such as 6-sigma and TPM are not entirely applicable to IT organisations, there are important lessons to be learnt from them. Crucially, they help to define more clearly the goals for an organisation and offer more realistic metrics for a department to operate on than we closed so-and-so many trouble tickets last year.
I think it is also realistic to not expect too much from one organisation. There is a tendency to lump all that is IT together in one organisation, on the pretense that any work involving computers must be similar and have identical organisational needs. That makes little sense; the actual IT tasks can be very diverse and require different people, different attitudes, and different strategies. It makes considerably more sense to give an IT person a reporting line to the manager of the process that he or she is trying to support, than to some manager whose only connection with the activities of that person is that they both have "IT" printed on their business card. In my opinion, IT centralisation is a sin that one should not commit without a very good excuse.
Slashdot Mirror
Actually, the ratio is more like two to one. About 15 to 20% is spent on research, roughly twice that on sales and marketing.
Spin: (1) Marketing always delivers profits, research fails to deliver something useful 90% of the time. (2) There are millions of people who can do marketing, and only a handful who can do cutting-edge research.
This seems to go back all the way to the days when Netscape "incrementally evolved" HTML too, and frustrated developers commented that its next set of new HTML tags would probably be peek and poke.
The largest hole in our own (awful) password security must be this, and it has little to do with lazy users.
In our company, we must have about 50 different applications that require users to enter passwords; maybe more. Some were bought off-the-shelf, others were developed internally, and others were contracted out or written by consultants. Quite a lot of it was customized for us, or even developed entirely to our own specifications.
To the best of my knowledge, nobody of us has ever verified what actually happens to a password after it is entered in the login dialog. We don't do code reviews... at all. Password checking against the directory server is encouraged, to ensure that users need to remember as few passwords as possible.
So next time I log in to the financial software to file an expense note, the system may actually be mailing my password to John Doe, or to the competition. Who knows?
Well... Our own "high security" IT department not only issues shared account passwords with incrementing numbers, they have even suggested (and e-mailed) a standard procedure for turning your own name into a "secure" password by changing 'o' into '0' and such...
As long as the system algorithm accepts it and the password is changed every three months, they consider it must be secure. When I helpfully pointed out that changing 01 into 02 is not going to fool anyone, the answer was that the password cannot be guessed by others anyway, because the login screens allow only a small number of retries. This left me quite speechless, so I didn't push it any further. I could of course have said that it only takes lifting the keyboard and reading the post-it note. (IT doesn't like post-it notes stuck on top of keyboards, but they don't look underneath.)
Their holy grail is policy. If Policy Is Followed, It Must Be Good. If policy is not followed, they get bad points. The sobering reality is that their password policy must be making our systems considerably less safe, and it would probably be better if we had a less strict -- even allowing dictionary words -- but more reasonable set of rules.
Of course the patients where injected with parts of the virus that are not, in themselves, sufficient to cause disease.
The point is that, of course, cells are not part of a virus; cells are much bigger than as virus. Nor is DNA a part of a retrovirus such as HIV, which carries its genetic information in the form of RNA. Nor would it make sense to simply inject patients with parts of the genome, rather than selected (parts of) the proteins, in the hope that they would somehow develop immunity to proteins that are not even expressed.
So a phrase such as "The HIV-1 specific cells injected into the recipients were the DNA fragments of the virus which don't cause infection" betrays a painful lack of knowledge of virology and molecular biology, and gives no clue about the nature of the vaccine whatsoever.
The actual press release is more cautious than the excerpt that is quoted here; describing the result of the trials as saying that the vaccine is "safe and possibly effective." Apparently there were no ill effects, and if I interpret the text correctly, they detected antibodies against whatever these people were injected with. Which does not prove at all that the vaccine could be effective, because the envelope proteins of HIV are so variable that buidling up immunity is enormously difficult. However, it is probably as much as one could reasonably hope for in this first phase of trials.
That said, there is nothing in this press release to suggest that this vaccine trial will have a better outcome than the series of failed trials that have already preceded it. Mainly because there is very little information in this press release at all. Obviously, it was written by someone who did not have a clue about the science behind the trials; you can't tell from this what the vaccine consists of and how it is supposed to work. More worryingly, the "director of the National Institute for the Control of Pharmaceutical and Biological Products" is quoted as saying that "The HIV-1 specific cells injected into the recipients were the DNA fragments of the virus which don't cause infection." Which is nonsensical enough to suggest that the aforementioned director, who held the press conference, doesn't have a clue either. Probably he is more remarkable for his political skills than his medical ability.
But maybe these Chinese researchers are on the right track -- who knows? A vaccine against HIV is very much needed, and the hope that we will be able to create one seems to shrink with every new failure.
At the a fundamental level of software design, keywords like private and protected are used for good reasons. And one of them is to prevent writers of dependent software from relying on pieces of code that should not be considered part of the public interface, can change if the implementation (but not the interface definition) changes, or are simply too dangerous to mess with.
In my opinion, that can be legitimately extended to a wider level as well. If Microsoft feels that it is better to make only part of their interfaces publicly accessible, that should not only be their right, but also is simply a good conceptual design practice. Software authors who think that they can meaningfully improve their products by extending and deepening its OS and SDK dependencies are, in my opinion, simply wrong. (Even if the OS is not a Microsoft product.) It does nothing for quality, portability, or longevity of the code.
But if you feel that authors of Windows-based software have the right to understand the interactions with the whole Microsoft environment better, I would certainly agree. But this should not be achieved by having to delve in the obscure and volatile details of the code behind the public interfaces; an effort that is likely to be futile anyway. It should be achieved by designing and documenting the public interfaces properly; and that should remove the need to study the rest of the code. By definition of a good and properly documented interface, studying the code behind it should be superfluous. But forcing MS to waste work on documenting interfaces no sane person will want to use anyway, is not going to be a productive contribution.
As for them being unable to supply intelligible documentation -- yes, I am willing to believe that. Just by having a look at what they routinely supply as development kit documentation.
Obviously, Neelie is not a programmer and has never tried to write a program in a Microsoft environment, or even tried to figure out what their documentation is supposed to mean... If anything.
The example below is my favourite piece of Microsoftism, from the "I cannot believe that I am actually writing this" department:
IXMLDOMDocumentPtr pXML = NULL;
...
HRESULT hr = pXML.CreateInstance(_uuidof(DomDocument40));
pXML->async = VARIANT_FALSE;
pXML->validateOnParse = VARIANT_FALSE;
pXML.Release();
And yes, this compiles and works. Surely there must be other gems of Microsoft protocols out there. Any other proposals?
I believe the Comission is wrong, and the companies that are lobbying the commission to get access to these protocols are even more wrong. We should not want more software that relies on more Microsoftisms. Au contraire.
I wish I had a list of the companies that are sueing for these protocols being made public. Then I would at least know whose software I certainly do not want to buy.
Well, the pharmaceutical company probably did spend somewhere between $400 and $800 million on the original development of the drug, so if it did not recover its R&D costs yet (and many drugs do not, not before the patent expires) then they may have a moral case.
I think this would be a good principle, if it could be generalized: Link the expiry date of the patent to the investment in it, or better to the return on investment. Say, minimum five years from the day of filing, plus a year extra for every $50 million that was not recovered from the R&D investment within that period.
That would mean that patents that are just sitting on the shelf without someone making an effort to develop a product would expire faster than they do now, while people who do invest in the development of a product are rewarded with extended patent rights.
After all the trouble Microsoft got in for bundling IE and Media Player with Windows, I would expect the people at Google (or Yahoo) to be a little smarter. Just how many million dollars do they actually want to get fined? I don't know about the USA, but the EU competition authorities do regard product bundling as an anti-competitive practice and illegal.
And frankly, Microsoft had at least a decent case that integrating a web browser and a media player in an OS makes sense, but bundling a search engine with a media player or a document viewer does not make any sense at all. Next they bundle them with the cornflakes.
Yes, seriously...
One advantage the USA definitely has for technology startups is that basic research is funded with about $36 billion in public funds, i.e. roughly two-thirds of the basic research budget. That pays for a lot of research and potential business opportunities, and it is a spending level that most US competitors cannot hope to match.
Of course a discovery is not a product, and industry pays for most of the applied research and almost all the development. But it is basic research that provides the core around which a startup can condense. Or it keeps an industry alive and growing -- the success of the US aviation industry was to a considerable extent the success of NACA/NASA. And Silicon Valley started out from the base of Stanford University.
On overall R&D expenditure, the USA still outspends Japan and China by about a factor three.
Well, I have ever used PHP. But in my opinion the experience with bad languages such as BASIC (does anyone remember FORTRAN 77?) is not as exclusively negative as "ruining" people.
If you use "bad" languages a little, you will indeed learn bad habits. But if you use them a lot, you will be forced to learn at least some good habits, because otherwise you will lose vast amounts of time indeed. Bad languages do not enforce discipline, but they do teach self-discipline.
That said, I am reluctant to hire "experienced VBA programmers" and such - at least for serious work.
Well, I am a scientist, working in Europe not the USA, and my wages after (very steep) taxes are about $45,000 year, not including bonuses, employer's contributions to pensions and insurance, and other perks. For someone with my function that is below the market rate, but I am recently promoted to it. But I work in the private sector, not in an university.
I think that of my fellow employees, nearly one third are PhD scientists. For new positions, we head-hunt globally; the only continent from which we do not (yet) employ anybody is Antartica. In general we find it quite difficult to find people who are qualified for the jobs we are seeking to fill, and we often have to fall back to hiring people in the hope that they will grow into it. But oddly enough, although we have plenty of directors, marketing managers, and assorted business people from the USA (we are not based there, but are US owned), only a small minority of our research scientists was born and educated there.
It is not as if we have a filter in place to reject American candidates. We could not afford to. But they are just not there. Living standards here are considered slightly above what the USA has to offer, and certainly the food and the beer are a lot better, so in principle there is no reason why we should be unable to attract US scientists. As a matter of fact we do attract scientists from the USA -- they are just not American. Many of us have worked in the USA at one time. Personally, I have spent only a brief time there -- and characteristically, my US co-workers were immigrants themselves.
The truth is that there is a real shortage of US scientists, and there are many reasons for it. A low level appreciation by the public in general is certainly a factor; if you want to make money and be respected in the USA, becoming a scientist is somewhere well below lawyer and rap artist on your lists of options.
Another element, admittedly part of the former, is the pervasive anti-scientific climate in the USA. I agree with other posters that president Bush is not personally to blame for this. However, his plainly hostile attitude to science whenever it interferes with personal prejudice (or political expediency), is symptomatic for the disparagement of science that is festering in the circles that brought him forth, and has been so for quite a long time. This is a real enough phenomenon; America has been breeding a strange brand of religo-political conservatism that belongs more to the 18th century than the 21st. I am not sure whether it is an actual leftover from the revolution, or a new invention. Whatever its origin, it must be discouraging a lot of potentially great scientists, and it certainly has a harmful influence on scientific education.
The final factor, I think, is cultural. American science was flourishing in the 1960s, when there was a real spirit of discovery and advancement. Today, the country has become materialistic to the bone (even in its religion), and as a cultural motivation discovery has been entirely replaced by profit and practicality. Talk to an average American about what makes America great, and sooner rather than later he or she will say that Americans have fatter wallets than everybody else. Especially conservative Americans are standing every-ready to defend the USA's track record in terms of high GDP. It is a sad state for a country to end up in.
What is probably not a big factor is high school education. For what it is worth, US students are regarded as active and questioning by global standards; maybe they are a bit on the lazy side but they are respected for having probing minds and a willingness to ask questions. Such students should make excellent material for a university education in science; but too few of them choose to have it.
This served me well by way of a basic programming education, and when I was involved in restructuring the IT courses for science students we refined it but largely retained the concepts.
You should start with a two-part theoretical introduction. One half of that should lead to some broad understanding of the fundamentals of computers and their programming. History of computing, Turing machines, basic computer and CPU architecture, basic principles of computer networks, a cursory overview of machine code and assembler, basic concepts of different types of programming (object-oriented, procedural, ...) languages and how they differ, relational vs. other databases, etc. The idea of this is to get the essential background and learn the jargon, so that if people throw new terminology at you, you can at least place it somewhere in the right context. The goal is not to get into any detail.
The other half of the introductory course should be rather more formal and very well understood before you start to do any programming. Crucial elements of are a good understanding of (boolean) logic and simple probability theory and statistics, a thorough introduction to data representation inside computers (data types, overflow and roundoff issues with data types, data conversion, arrays, pointers, linked lists, structures, etc., etc.) and a similarly strong introduction to control mechanisms (if-then structures, while loops, error handlers, etc, etc.) These are things that are important in almost any programming language, and a failure to deal with any of these correctly is a common source of bugs.
Once past the introductory course, you can lay aside the theory for a moment, and start programming -- seriously, not typing over simplistic examples from the textbook, but solving real if simple problems. You have to build up experience and the best way to do that is by slogging it out with a real problem.
It is best to pick a high-level programming language, and I advocate starting with an object-oriented one as it is easier to go from there to a procedural language than in the other direction. At this time I think Java might be the best choice; the essential tools for programming in Java are readily and freely available, and there is less risk of losing a student's time on obscure problems in Java than in say C++. These days C# also seems a reasonable option, but I have not yet studied it myself. And C++ might also be an option, but then at all cost avoid all Microsoftisms -- use g++ if you must.
Once you have some programming experience, it will be a good time to make a study of more advanced algorithms. (The disadvantage of using Java as a teaching language is that you will never be obliged to write your own quicksort.) The best way to understand these is to implement them, and you can't to that without some programming skills.
And when you feel that you have reasonable skills in one language, start learning another one. It doesn't matter which one, as long as it is different enough.
Quality arguments of this type are not confined to software alone. You will find the same reasoning in hardware engineering, and even in process engineering for manufacturing plants: There must be some balance between the benefit of solving a potential problem, and the adverse impact of changing systems in ways that often make them more complicated. So on the whole I find Sink's position reasonable enough.
Consider this one, however:
Vault's backend makes extensive use of features specific to Microsoft SQL Server. Contrary to popular belief, SQL isn't portable. Adapting the backend for any other database would take months, and the maintenance costs of two back ends would be quite high.What this probably means is that Vault is relying on features highly specific to the Microsoft SQLServer engine, and that these external dependencies are not isolated behind some interface or localized in a specific module, but scattered all over the entire software. That's not a bug; that is a major design error. It probably implies that whenever Microsoft changes SQLServer in a version that is not 100% backwards-compatible, Vault's customers will have to put up with a lengthy series of minor and major bugs until they have all been ironed out. And if this is their design pattern, that may also be true for every other external dependency that they have. (Their line ending problem suggests as much).
As a potential customer, I would not care much about the length of the bug list, which actually says more about administrative neatness than about the stability of system. But I would be greatly worried about design errors like this, that fundamentally undermine the future of the system. If I buy it, it might turn out to be a millstone around my neck. And if a system is badly designed, it is also likely to contain more bugs and be less stable, because probably even it's programmers do not understand how it works.
Good fundamental design is still at the heart of develivering quality software. There is no replacement for it.
Relatively far-fetched, I would say. Look at the fluorescent proteins that probably make up most of that cited $100 billion per year (in 2000) for marine-biotechnology derived products. Very few people would use "wild type" fluorescent proteins for research, as these are not very efficient for our purposes. Instead researchers have developed the original jellyfish or coral proteins in entire families of mutated proteins with desirable fluorescent and other properties -- similar in structure, but a small change can turn a blue-fluorescent protein in a red-fluorescent protein.
The same is true for drugs. Pharmaceutical companies are looking for novel chemical structures and proteins in marine organisms to feed their chemistry libraries, but they are unlikely to be able to use these as drugs in their original form. Something an invertebrate uses as a toxin for self-defence may be a potential anti-cancer drug, but is likely to be too dangerous for use in humans. Instead chemists will study the structure-activity relationship for a family of related compounds in the hope of deriving a compound that is more active and safer. But that means that the end product will probably have to be synthesized.
Besides, it is an expensive chore to extract and purify a product that a primitive animal might be making minute quantities. It makes much more economic sense to go for expression in genetically modified cells.
By doing the letter by letter modulo 26 sum (a Vigenere encoding operation) of and smithysmithy... in Excel, I get
bmmblvlaamnnkmkzycsyypmispxfxgc
which is an interesting letter pattern and at least has a more natural letter frequency distribution than the original. The most frequent letters are m and y, which suggests that these could be e and i. As ii is not a frequent letter pattern, it is tempting to assume that m is e. However, the sequence is so short that such statistical assumptions are very risky.
And if there is a secondary substitution it must be more complex than a Caesar shift, for the +18 operation generates
teetdndsseffcecrqukqqheakhpxpyu
And others are not much better. This may be dead end. Or we may still have the wrong cypher sequence.
Yes, it can happen. Look for a example at recent drug trial incident in London, where a therapeutic antibody that had good results in animals (and apparently mild side-effects in monkeys) had dramatic and potentially fatal side-effects in human volunteers.
The effects are rarely that dramatic, as the worst effects are usually discovered in animal trials. (For added safety, at least two species are used, one rodent and one non-rodent.) However, unwanted side effects are the rule rather than the exception, and the only really reliable way to find out so far is through tests on human volunteers. Most drugs do fail in these trials!
Actually, even the drugs that do pass the clinical test stage and are approved rarely work for all patients. The FDA is happy if the drug helps a sufficiently large fraction of patients, and does not real harm except in exceptional cases. It is the average cost-benefit that counts, not the result for the individual patient, which is at this moment often impossible to predict.
For there is genetic patient-to-patient variation among humans as well, not to mention genetic variation among pathogens, and a drug that fits the protein in the body of patient A may fail to do so in patient B. And a drug that does A and B no harm may have fatal effects in patient C.
Genetic targeting of drugs has already caused a controversy around NitroMed BiDil, a heart medicine that is specifically effective for black patients — admittting that few Americans are of pure genetic "African" or "Caucasian" stock. The culturally acceptable (but scientifically dubious) solution is to allow patients to "self-identify" as black and therefore potential users.
For the future much hope is put in "personalized medicine", giving the patient a genetic analysis first to determine whether a drug would be really effective — or would have serious side effects. However, this too has obvious cultural and moral problems attached to it.
To give a balanced answer: Yes and No.
Many drugs work by binding to a target protein and inhibiting its activity in this way. However, there are several ways to achieve this. The conventional form of drug is a "small molecule", created by organic chemistry. These are called small because they are much smaller (and less complex) than proteins -- say more than a factor 10 smaller.
Small molecules can have enormous advantages: They are relatively easy to manufacture and to store, and if they are stable enough and well absorbed, they can be taken orally. If you want something simple and cheap for large-scale use, a small molecule is the way to go. However, the downside is that they are very complex and expensive to develop.
The other big category is that of the "biologicals", which includes proteins and peptides -- a peptide is essentially a small fragment of a protein, but still bigger than a small molecule. Antibodies are a category of proteins; in the case of antibodies, development is relatively easy because the body produces them naturally. There is also the possibility of taking a protein's natural binding partner, and then synthesising this on a large scale to outcompete the natural binding partner. The general expectation is that biogicals will be easier to develop than small molecules and for many diseases, will be the first form of treatment available.
The typical disadvantages of biologicals are that they need to be stored in a freezer, must be injected rather than swallowed or inhaled, and are expensive to manufacture. This usually restricts their use to relatively small numbers of patients, in hospital environments or receiving intense attention from their physicians. (Insulin is a well-known exception, however.)
Some people believe that small molecules are fundamentally unable to block certain interactions. The reasoning is that that something small can only attach efficiently to a target site if the available forces on that site are large enough, i.e. if there is a so-called "pocket" to fit the molecule in. While biologicals, because they are bigger, can bind over a wider area, so can be effective even if smaller forces are involved.
In this case, the scientists took peptides, which are relatively small, but instead of combining them into an actual protein (which would have been very complex and expensive) they grouped them together on the surface of a liposome, which essentially is a tiny droplet of fat. And the observation is that indeed, the interaction of the multiple peptides with the target still adds up, giving the liposome a much stronger binding to its target than the individual liposomes.
This creates numerous interesting possibilities. This might work with small molecules as well as peptides, for example; or you might even combine the two in a single treatment.
I wholeheartedly approve. For years, one of my biggest and most complicated tasks has been the transfer of data from source A to target B. Usually A is in a format that is undocumented and inconsistent. Reverse-engineering can be a nightmare when formats are badly designed (although that explains why they are often considered propietary) and used randomly. You would be surprised by the vast number of programmers who neglect to start a file with an identification tag and format version number.
I would happily go a step further than the MN proposal. I would require by law that all files produced by commercial software have to be in a formats that are documented and open, so that they can be read by any programmer skilled in the art and in possession of the documentation, which the supplier of the software has to give to you.
Actually anyone who creates a new format should be required by law to deposit its description in a public, easily accessible facility. A kind of Congressional or British library of file formats.
I am not totally opposed to patents on formats, but I would require any company that patents a file format to give any of its competitors a license for its use at small cost.
The website development and graphics are all contracted out. Only the content is developed in-house, by a scientific writer, so that we can be sure that it is both correct and well written. We can't ask web developers to check the content. I assume the legal department also checks it for any statements that various regulatory authories might object against. (Or adding SEC-required disclaimers etc.) I think that this in itself is a good model.
The biggest potential problem that I see is a tendency of upper management to try to influence detail design, and their unfortunate tendency towards glitz: Flash animations, rolling menus, ticker bars, high-resolution graphics, and the like. These might consume a lot of time and money and only rarely contribute to a good website. (One of the few happy exceptions I have seen is Nikon's microscopy training website, which is great.) But my personal preference would be for a site that is styled in a minimalistic way, light and fast.
Yes, the Soviets routinely did this as well. Strategy aside, they were always paranoid about espionage and unwilling to export their latest equipment for fear that it would fall in the wrong hands. Besides, they would also sell on a large scale to third world nations, who would find it difficult to maintain the most advanced equipment.
Selling high-tech defence equipment has always been as much about creating a dependency relation as about making money. (This much fighter jets have in common with cheap inkjet printers.) When you sell someone an expensive jet fighter, that country becomes dependent on you for training, spare parts, maintenance, and upgrades. Not just until the next version of Windows comes out, but for the lifetime of the aircraft, which is now as much as 30 to 40 years. A $25 million jet fighter without appropriate support is almost scrap metal.
Of course it is possible to go without support for some time. When Sadat kicked his Russian advisors out of Egypt, the Egyptians briefly considered fitting their MiG-21s with Rolls-Royce engines (would have been nice) before they bought Western equipment. More recently, Iran has been able to maintain US jet fighters in an acceptably operational condition without (officially admitted!) US support, but it clearly has not been easy and no doubt cost a frightening amount of money.
Weapons are by no means that standardized. Britain, France, Germany and some other NATO countries still develop their own missiles, and also various electronic and intelligence-gathering equipment, which is equally important.
The USA doesn't really like NATO weapons programs unless it can supply the weapons itself; its attitude is fundamentally protectionist and contains a lot of "NIH" syndrome. It has, for example, pulled out of the development of the ASRAAM missile and substituted its own AIM-9X.
For the UK, not having the source code might not only mean that it cannot integrate its own weapons, but also that it cannot sell its products to other JSF users. For example, ASRAAM has been sold to Australia for use on the F-18E. If JSF is a closed system, the USA could lock out any such competition and force buyers to purchase everything from US suppliers.
If that sounds paranoid... US officials have occasionally admitted that one of the goals of the JSF programme, at least it multinational aspect, is to drive other suppliers of combat aircraft out of business and ensure for the USA a monopoly on the supply of advanced defence equipment.
Of course one of the other reasons is to make foreigners pay some of the bills for US weapons development. The system is charming: participating nations have to pay a large fee upfront for allowing their industry to compete for JSF contracts. Then they are sold downrated equipment that is not as capable as the F-35 as operated by the USAF, USN and USMC (if it ever gets that far). One of the reasons the UK wants the source code, I assume, is that it wants to ensure that its aircraft will not be downgraded too much. (Nobody would take Washington's word for it... not any more.)
For the UK, JSF will be a bad deal. If the two planned RN large carriers are indeed completed, there is no real reason left to buy the F-35, and the British government may indeed be looking for a way to cancel its commitment to JSF.
This was at a time when the development programmes for advanced combat aircraft (and other military equipment) were successfully expanding into truly phenomenal cost overruns. The TSR-2 development cost estimates first doubled, and then tripled. The F-111 was so attractive to the UK government because its estimated unit price was about half of that of a TSR.2.
Of course, the UK had no monopoly on cost overruns, and McNamara's pet project went through the financial roof as well. The F-111 became even more expensive than the TSR.2 would have been. The TFX project that produced the F-111 tried to be all things to all people, actually rather similar to today's JSF project, and predictably it failed to do that. (You can easily guess my opinion of the JSF project.) The F-111B version for the US Navy was cancelled outright.
Besides, both the TSR.2 and TFX projects were arguably too far ahead of their time. The F-111 did not become a really effective combat aircraft before its first generation of pilots had retired, and its fragile 1960s electronic systems replaced by more modern and reliable ones. There is every reason to assume that TSR.2 would have suffered from the same problem.
I think the first step should be to look at better IT organisation and management strategies. The way many IT departments are run is still rather primitive; extremely self-centered and often based on reactive maintenance. While a good organisation should be driven by the business or project goals it is supporting, and have the efficiency of its contribution to these as its target.
While concepts such as 6-sigma and TPM are not entirely applicable to IT organisations, there are important lessons to be learnt from them. Crucially, they help to define more clearly the goals for an organisation and offer more realistic metrics for a department to operate on than we closed so-and-so many trouble tickets last year.
I think it is also realistic to not expect too much from one organisation. There is a tendency to lump all that is IT together in one organisation, on the pretense that any work involving computers must be similar and have identical organisational needs. That makes little sense; the actual IT tasks can be very diverse and require different people, different attitudes, and different strategies. It makes considerably more sense to give an IT person a reporting line to the manager of the process that he or she is trying to support, than to some manager whose only connection with the activities of that person is that they both have "IT" printed on their business card. In my opinion, IT centralisation is a sin that one should not commit without a very good excuse.