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
