Hi Brane, I certainly do take maintainability seriously. What's that well-quoted figure? Something like 80% of the cost of software development is spent in the development phase?
Within the context of Subversion And the lessons learnt from libsvn_wc and with constant peer-review, is a truly awful of piece of code likely to make it through in the first place? I've seen plenty of occurrences where full-committers have been asked to revert / edit their changes . I'm almost arguing recursively I suppose, that peer-review is causing patches to be more sophisticated than required, but at the same time peer-review is working for SVN, to keep the chaff out of the wheat. Which means that I am either satisfied with the answer or I simply can't make up my mind. I was more concerned about I suppose; Are we at a situation of over-engineering so that code makes it past the peer-review stage - but is the over-engineering a true requirement or a waste of time? (it may well be decided that there is no "over" engineering at all - and that things are appropriately designed / implemented.) I still kind of lean towards, as long as code has appropriate / current comments - then any patch should be as simple as is human possible to meet the engineering requirements. Surely having the simplest code possible ensures greater maintainability? And specifically a patch about optimisation - then that should "only" be concerned with getting the job done as quickly (and simply with appropriate comments) as possible. I'm not at all expecting to change anyone's mind, or the methods used here in Subversion for development - I was merely curious. Thanks. Gavin. On 17/01/2011, at 8:17 PM, Branko Čibej wrote: > On 17.01.2011 08:08, Gavin Beau Baumanis wrote: >> Is the answer not; >> Code to the manner that provides the greatest return on a developer's time >> for THIS problem. > > You have to take into account the cost of maintaining the code, too. > > For example, it's usually "fastest" to not worry about coupling and > factoring, which makes the "fast" implementation usually a pile of > copy-paste, impenetrable mess. Which costs a lot more in the long run, > because sooner or later you have to untangle the mess in order to make > any kind of improvement. Witness libsvn_wc and how long it took for > anyone to dare throw it away and begin from scratch, because the > original was simply not amenable to improvements. :) > > -- Brane
