You don't hail from Liverpool by any chance do you? :)

On a more serious note, I think the concept you expressed here in somewhat utopian terms, is actually a pretty good vision of not just what would be nice in the future, but what will have to become reality in order for software development to make it's next (I could almost say first) tentative step to moving from a craft to a form of engineering.

Imagine that your version control/development collaboration system didn't just detect and record changes to the files posted into it, but went a few steps further.

• detected and recorded the changes.
• automatically recompiled the affect parts of the project.
• ran the affected parts of the unit, integration and regression suits. and produced statistics.
• profiled the code and generated comparisons of raw performance, memory usage, etc,
• performed a static analysis of the code looking for deprecated usage;
• flagged dubious practices;
• compared function and method signatures against previous versions loking for API changes;
• looked for changes in assertions;
• collated variable names and detected possible typos by flagging new variable names with low usage counts and/or a high degree of correlation with a similarly named existing variable ( @indexes .v. @indices ).
• detected the possibility of out-of-synch comments by noting that the code for a function, method or block had changed but the associated comments hadn't.

I don't think individually, any of these things are beyond the capabilities of existing programming techniques, languages or programmers. In fact I would go as far as to say that I think that I have seen most of the algorithms and coding techniques required to do this, be asked for and answered here at PM over the last year. The only grey area I see is that using perl to parse perl is notoriously difficult, but for other, simpler, more clearly defined languages, perl probably has the power required to do all of this now. The only things missing are the desire, agreement and funds and/or commitment.

I don't suggest that the availability of such a system would suddenly and dramatically improve the productivity or precision of software development, but I do believe it could produce the metrics that would highlight both the need for improvements and the directions that need to be driven to achieve them.

It's been my long held belief that the most significant factor holding back both software quality and productivity is the absence of meaningful metrics. When a mechanical engineer makes a change to the design of a component, he can pretty much just pick up a micrometer, a set of scales or put the component in a wind tunnel and get an instant measure of the effects of the change in some meaningful manner. It doesn't always tell the whole story. There have been several car designs over the years that measured really well on the scales of Cd (coefficient of drag) which translated into either better performance or better fuel economy, that where simply so ugly that the general public eshwed them.

Given the performance of modern processors, the time a programmer spends barely utilising the power of their cpu whilst typing into an editor or just sitting starring at the screen waiting for inspiration, should be being used to generate some metrics about the effectiveness of what s/he doing. Not for the sake of managerial purposes like the old kloc/week type stuff, but to give the programmer feedback. Peer level code reviews can be very effective, but anyone who's worked in an environment that uses them will know that as often as not, they can end up becoming religious wars or simply ego-fests. Interminable discussions about the benefits or otherwise of one technique, style or practice over another, with both proponents and opponents basing their arguments upon scant information gleaned from one benchmark, error or bug fix, in one previous situation that may or may not be applicable to the current situtation. Even if the legendary "programmer's ego" problem can be dismissed, we all tend to base or opinions upon our experiences and we each have a different set of experiences, so our opinions differ. Without a set of realistic and relevant metrics to act as a deciding factor, it becomes a free for all of argument about who's set of experiences are the more relevant, who's debating skills are the greater, and finally, whos has the greater (managerial) seniority.

Sorry to hijack your vision and bend into one of my windmills:)

It is intrinsic to the nature of the programming task that you cannot do it without having a large number of things in your head at once. OK, there are programming-related tasks that can be done getting into the specifics less - otherwise sites like this could not happen. But estimates that I have seen is that about a third of the work of a professional programmer is work that you cannot begin to be productive at unless you have already had 15-20 minutes getting a good "mental flow" going.

In other words the same principles that make interruptions such a productivity killer also make it impossible to produce useful software out of a million programmer's "wasted interrupt time".

Book recommend: if you haven't read Peopleware, do.

UPDATE: I think of this place as being somewhere you go to get the kind of advice you can give based on small pieces of code which zby commented on below. He might have a different vision though.

It is intrinsic to the nature of the programming task that you cannot do it without having a large number of things in your head at once

That's true - but it does not mean that you can't give advices based on small parts of the code. Those advices would be helpfull or not - the author would decide eventually if they fit into the whole picture, but they can lead him into new ways of thinking. This schema can work since the cost of reading an advice is not that big.