Hi All,
It is a very interesting notion that Gavin throws at us. I think it is
very important for an open-source project to maintain it's code in a way
that it is easy for a new guy (like me) to make quick and meaningful
changes. Most open-source projects with a large development community
ends up in a mess of perfectly working, yet highly unreadable code.
However, as a pair of fresh eyes looking at the code, I can safely say
that though being an open-source project, Subversion has managed to stay
"readable". This can only be attributed to the hours of work spent on
"over-engineering" the code (BTW, I personally don't think anything can
be over-engineered. In my book, it is merely an synonym for perfection).
There are parts of the code (in svn) that have been written with the
notion of "getting things done". And these are the parts that I really
find difficult to assimilate. I think time spent *earlier* to sanitize
the code is time better spent, than trying to read the mind of the
original implementer at a *later* point in time.
Regards,
Arwin Arni
On Tuesday 18 January 2011 07:26 AM, Gavin Beau Baumanis wrote:
> Hi Brane,
>
> I'm pretty sure the context of the quote is along the lines of;
>
> Poor design and implementation proves to be a burden in terms of maintenance costs, in the long run.
> And instead of having bums on seats for (entirely) new development, manpower is, instead, wasted on maintenance tasks because of poor design / lack of a prototype etc.
>
> I guess it is an implementation / coding practice question;
> Would a developer's time not be better spent on;
> Doing the "guts"of the job and at a later stage once the engineering is proven to be accurate / reflective of the requirements - then worry about private / public API requirements.
>
> Especially in an OSS project where resources are lean and transient, it is "my" (perhaps naive) view that spending x hours on writing an API that might not ever be used by another consumer is in fact x hours wasted that could have been spent on a more worthwhile task.
> When the requirement of a service to be consumed comes to bear, that is the time to create an appropriate API.
>
> From my past experiences, I have created many an API that have never-ever been used, purely because the design standard said an API was required, though the engineering requirements of satisfying the task at hand negated that requirement entirely.
>
> Again - I don't presume to know any better - and in fact I started the thread because of a desire to hopefully learn from it,
> I'm not trying to be deliberately argumentative - I am just a proponent of a good debate that fleshes out better outcomes / knowledge - selfishly for myself - and hopefully for others too.
>
> Gavin.
>
>
>
> On 18/01/2011, at 9:13 AM, Branko Čibej wrote:
>
>> On 17.01.2011 23:07, Gavin Beau Baumanis wrote:
>>> 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?
>>
>> I believe it's "should be spent" rather than "is spent" ... in reality,
>> I've yet to see a project that didn't incur horrendous maintenance costs
>> as a result of shortcuts taken during development.
>>
>> -- Brane
>>
Received on 2011-01-18 07:38:14 CET