That number of IT people sounds like about our own rate, around 30 people in a company with 600 employees. Of which about half a dozen are helpdesk people. In practice that is not enough for us.

Yes, it all depends on what you do. If your company only needs an off-the-shelf accounting system and MS Office, these 2 people should do fine. But we have half a dozen transactional database systems, a number of servers that are running heavyweight scientific data analysis, a commercial web interface which we need to keep running 24/7, very strong legal requirements to maintain privacy and data integrity, and almost daily requests to make changes to applications.

Our IT departement therefore includes programmers, database analysts, testers and validation staff, and of course various managers. These 24 extra people in practice boil down to only 1 or 2 skilled people to support every business-critical system, which means that there are serious gaps every time when people are on holiday or leave the company... We have to cover part of the gaps by allocating time from IT-skilled people in the business unit.

As for the helpdesk, simply giving everybody the same PC and the same image isn't a viable solution, although sadly our CIO is incompetent enough to think it would be. There is a rather wide gap in requirements between addressing the needs of a manager or his secretary, meeting the more demanding requirements or bio-informatician wrestling with gigabytes of sequencing data, and setting up a controller for a robot that could easily crack somebody's skull. Not to mention all the internal development of software tools.

However, in fairness, it also depends on how people are organized. Our management has discovered outsourcing, specialization, and centralization: In practice that leads to a bureaucratic merry-go-round in which a simple problem passes through a dozen different mailboxes before somebody does something about it. I've seen trouble tickets that bounced back and forth for two weeks before they landed on the desk of some IT manager, who honestly had to admit that he too couldn't figure out who was responsible for actually solving the problem.

My experience is from the user side, and I would strongly discourage uniforms for the IT helpdesk, in fact for any helpdesk.

The reality of life is that individuality matters, especially in a person from which one seeks help: People need to establish personal contact. And when it comes to essential tools such as computers, which can make our workday hell if they don't work properly, trust matters a lot. Putting your helpdesk people in uniform is the first step to make them uniformized drones. It will have a bad effect on employee morale, not just of the people who wear the uniforms, but also the people who call on them.

My advice is to fight it, tooth and claw. Instead promote rapprochement between the helpdesk people and the business by making sure that when people call, they get the same helpdesk person whenever possible. Don't over-emphasize central helpdesk lines and by all means avoid trouble ticket systems -- I've never seen one that didn't succeed in infuriating the end users.

The richer syntax means you can write code faster. But I am not so sure that that means that you can actually get you work done faster, although it of course depends on who you are and what you do. If you always work more or less in the same context, and that is not too complex, there will be no problem for you.

But my experience is that programmers spend half their time or more with trying to figure out what other programmers have done, and that they find that far more difficult and exhausting than writing their own code. That seems particularly true in an environment such as .NET, which comes with a rich set of libraries, including some that provide high levels of abstraction.

The problem with property syntax is not in the idea itself, but in its potential for abuse. As long as a.x = y is indeed a shorthand for a.setX(y), there is no problem. Dragons awake when somebody starts using it as a shorthand for a.addX(y). And yes, potentially somebody could write a.setX(y) and give it the functionality of a.addX(y), but the temptation to do so is much smaller.

But I admitted that I stretched it a bit when I quipped about properties being a bad idea. Operator overloading, however, almost certainly is.

I am not convinced that it is such a bad thing that Java-the-language is 'stagnated'. As language, Java was designed from the start to eliminate features that were, in the parlance of the day, "Considered Harmful". So yes, it was and is a bit restrictive. C# has a richer syntax, including "goto"... The richer syntax can be a plus because it often saves time in coding.

But creating code is what, 20% of the lifetime cost of a software package? And meanwhile C# provides the less disciplined programmer with plenty of opportunities to create write-only code. Never mind lambdas and closures --- I am not so sure that having properties in C# is a great idea, because their very purpose is to hide that code invocation happens. And I positively dislike the opt-out from declaring which exceptions a method throws. Exception handling is simply too important.

I'm still not convinced at all.

That your students where more "productive" after 16 weeks than CS majors is irrelevant. CS majors need to absorb quite a lot more of background information, which means that they inevitably will take a slower start. And, at the risk of upsetting everyone, in many places being a more productive programmer than a CS major is not that much of an achievement anyway. My own teachers managed to achieve that for many of us using dialects of PASCAL and, out of all possible creeping horrors, FORTRAN77.

That you students could write multimedia stuff perhaps illustrates the strength of the available programming environment and libraries, but not the quality or ease of use of the syntax of the language, or the need to invent a new programming language. It is technically possible -- if anyone would be mad enough to set himself to it -- to write a toolset and library that would allow students to quickly and conveniently write cross-platform multimedia games in FORTRAN77. That language doesn't have a particularly complex syntax.

And no doubt, given a trajectory of 16 weeks, this achievement also illustrates your own priorities as an educator. But if your standard of achievement computer education is generating multimedia games -- many aspire, but few are called to that job. And this risk of emphasizing this is that it reduces the activity of programming itself to a game. No doubt fun for the students, but do they really benefit?

I must wonder whether your students will know how to properly structure their code, how to handle possible error conditions and exceptions properly, and how to manage memory and resources. Will they be able to read the technical manual of an unfamiliar platform and get to grips with it, to figure out why a particular method call does not do what it is supposed to do, or to self-educate into another language than the sandbox you trained them in?

As for my knowledge of learning to program, I'll concede without hesitation that I am not a professional educator and unfamiliar with the literature on programming education. I have, however, far more experience that I would ever have liked to have in observing the gaps in the programming education of people, both IT professionals and amateurs, and the horrendous consequences these can have. And, incidentally, some experience of the difficulty of teaching people better strategies and habits. No doubt I have less practical experience of this than others -- I've seen only a few million dollars wasted, and I am sure others could faithfully claim orders of magnitude more.

So, although admittedly on thin ice where the how of educating people is concerned, I have pretty strong ideas on what people should learn. You fail to convince me that, if your students would apply for a job here, I should in any way regard it as an advantage that they were trained by you, or trained using rev.

Look at the tutorials; for example the File I/O code. I concede that to the average person without any programming education, this may look simpler than its C++ or Python counterpart, but is this syntax really simpler? I think not! On contrary this bit would be easier to code, with a rather lower risk of time-consuming compile errors, in many traditional languages.

I've seen enough attempts to "dumb down" computer languages for people whose computer programming examination only asked: "Which of the following three is not a valid BASIC keyword: (a) PRINT (b) GOTO (c) TERMINATE?" (I kid you not -- when I was at university, this was the level of knowledge expected from bachelor's students in, if I remember correctly, veterinary medicine.) Generally these languages did not succeed in making computer programming easier; they only succeeded in making it look superficially easier. The threshold appears lower for the uninitiated, but after the first three days there is no advantage and you're stuck with a stupid syntax.

The real choice, as far as I can tell, is between a "minimalist" design of a language which provides only those features that a developer is expected to really need, and a "maximalist" design that provides the extra features a programmer might like to have to save him some time and make code look more elegant. The pair Java and C#, despite their similarities in syntax, exemplify the contrasting approaches very well. Personally, having seen how even professional programmers can mess up their exception handling and mismanage their dependencies, I am firmly minimalist. Never mind time saved in writing code, that barely matters. What matters is time saved in code reviewing and debugging, and that is nearly always easier in a minimalist language.

That said, I hope there would be a market for a good, simple language suitable for automation purposes: Something that is suitable for anything from writing macros in a text editor to controlling a complicated robot, for which people now usually reinvent the wheel -- generally producing something roughly triangular with an off-set axle.

Yes, but is he supposed to know that the Royal Air Force has Air Marshals instead of Generals?

Anyway, his main point is an exaggeration. The RAF supported Whittle's work from about 1936 onwards, after having sponsored his engineering courses, first in the RAF, then at Cambridge. It was a mere trickle of money until the outbreak of war, but it was there. The scepticism about Whittle's work was fostered, ironically enough, by turbine specialists -- they did not believe a centrifugal compressor could be sufficiently efficient.

It is true that when the RAF decided to orders its first jet-powered aircraft, the experimental Gloster E.28/39, the German He 178 had already flown. But AFAIK they did not know that.

Technologically, the Japanese were not very advanced in the 1930s and 1940s. They were not as far behind as the Western powers had assumed, but they were behind nevertheless. However, they had that wonderful Japanese skill of achieving great results with very little. So if they lacked powerful aircraft engines, they compensated by making their aircraft lighter. There were downsides to that too, but given the available means, the results were very impressive.

That is why US commanders were surprised by the performance and agility of the A6M 'Zero'. The reports they received did not seem to make sense. They did not expect, and could not understand, that anyone would choose to go to war in a glorified sports aircraft, lightly built and lacking any armour. "An ideal sports aircraft for millionaires" was the verdict of US test pilots, when they got their hands onto one. And actually, they were right --- the vulnerability of the A6M cost the Japanese a lot of pilots they could not replace.

There is another lesson there. The Japanese knew their opponents could field superior technology, in almost any field, and would do it in superior numbers. They went to war nevertheless, in the belief that they could outsmart the US Navy and that sheer willpower and courage would bring victory. It didn't.

Sounds like you are making a strong, dedicated effort to keep systems running, but users are still unhappy, and they take it out on you. So perhaps it is time to do a sanity check: Assume for a moment that all existing systems would be 100% functional, without problems --- Would users be satisfied in that case?

If not, you can't win by doing the best possible maintenance or upgrade job. Perhaps the company should be thinking about some serious reappraisal of requirements and solutions.

Alternatively, bring your users into contact with the victims -- err, end users -- of a "professionally managed", large Corporate IT department. Then they may start to realize how lucky they are.

We are also more-or-less stuck with IE6 at work, because this is the "supported" browser of the IT department. Those of us who still retain adequate user rights to do it have installed Firefox -- and actually that is the unofficial advice we get from the people in the IT department if we report browser problems!

Very little of our internal applications doesn't run under Firefox. More is broken under IE6... Yet IT continues to install and support IE6 as default browser. (I don't know whether they are trying to fudge IE6 onto Windows Vista!)

Creating stem cells from adult cells is so far mainly interesting for research purposes. The first hope of researchers is that in the petri dish, culture flask or microtiterplate, stem cells and stem cell derived cell lines may be better research tools than the current cell lines. The cell lines currently used in laboratories are often cancer cell lines and poorly representative of the cells in someones brain or liver. Stem cells may also help us to better understand cell development and what happens when it goes awry.

For therapeutic applications, the first applications may depend on finding drugs that stimulate stem cells to differentiate: It may not be necessary to inject stem cells or cell derived from stem cells, because we may all carry cells with a differentiation potential. For example, regions of the brain seem to contain cells that could potentially differentiate to help people who are suffering brain damage or degeneration.

However, controlling differentiation is complex. While only four factors are sufficient to induce any cell to revert to a stem-cell state, inducing a stem cell to become e.g. a motor neuron is a very complex process that needs to be controlled step by step.

Not really. Because if people need to change their passwords frequently, they tend to go for stupid changes, such as incrementing a suffix number. I could make a pretty good guess of what some passwords on our systems will be a year from now, even though they are nominally changed every 90 days.

You would be amazed. And frankly, I feel I have too much exposure to IT in the enterprise rather than too little.

Back in the old days, in an organization of a few hundred people, I used to work closely with people in the IT department, and we got along very well. Even if half of the time I found it difficult to understand what they were talking about. But we all knew what we wanted, and that we needed to cooperate, and were successful.

But I have seen IT ever more centralized, first on an European level, then on a global level. And every time the organization became bigger, it also became more concerned with itself and less with users. Users are those nasty people who all insist on having different requirements, when IT "knows" that it is more efficient for all of us to have the same.

I have become a firm believer in the decentralization of IT. Only in small units can you have IT managers who really care and can be engaged in a conversation. The benefits of centralization and standardization are greatly outweighed by its disadvantages.

And crucially, the US military has the clout and money to have its suppliers resolve any bug or incompatibility, even to the point of having software redeveloped if they need to. That is a luxury few of us enjoy. Even today, some of the software packages I need won't run on Vista, or their suppliers recommend against it.

Unfortunately, I do. Seeing how the IT department just couldn't care less about what the users actually need in an organization with only a few thousand users, I shudder to think how bad it could be in the US military.

Although, to be honest, the best military organizations (and the current US military certainly ranks among them) have always paid great attention to gathering feedback and intelligence from the front line. Some hapless junior-low-cadre victim of the Corporate IT department is unlikely to be able to submit an "unsatisfactory report" on his software installation and have it processed by the command line. A junior officer in the US military probably can.

Easier to use: Maybe, but I find the ribbon a lot slower. My experience is that to some serious job in Excel, you find yourself switching back and forth between tabs all the time. In Word it is not as bad, but I still find it annoying.

The big problem with the Ribbon is that it is insufficiently customizable. In older versions of Office, you could pull frequently used functionality into toolbars, and impose your own ordering and grouping. In comparison the Ribbon only offers the same one-size-fits-nobody solution for everyone. Perhaps it works for the average Office user, but it doesn't work for me.

However, the Ribbon, if an issue at all, is certainly not the biggest problem with the user interface of Office 2007. For example, the biggest downgrade in Excel 2007 functionality is in the pop-up menus for charts. Here you are really slowed down, with functionality scattered around over different pages, and default settings that are inane. And PowerPoint 2007 has a maddingly annoying grid positioning system, which doesn't allow you to put drawn objects where you want them.