No such thing as a small change | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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.
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:) Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller In reply to Re: The Core
by BrowserUk
|
|