Gabriel Sechan wrote:
From: Christopher Smith <[EMAIL PROTECTED]>
Andrew Lentvorski wrote:
The real slowdown comes when you shift from clean slate development
to maintenance. I can write 100+ lines of code per hour when I
start out. However, then I start having to debug things. Suddenly,
my lines of code per hour drops like a stone.
Maintenance always means fewer lines of code,
Not in the least. Take the following sets of code:
while(*x!=0)
*x++=*y++;
or
i=0;
while(x[i]!=0){
x[i]=y[i];
i++;
}
The second is more lines, but also more readable. I'll take it any
day of the week. This is a simple example, but its not uncommon. For
another example, I'd rather see a perl program add 10K lines and use
explicit variables than depend on the magic $_.
I think we're all in violent agreement with what you are saying. This is
not what we were talking about.
What we were referring to (and this was specifically what Andrew said)
was that when in maintenance mode, you tend to spend more of your time
thinking, analyzing, testing, etc., so you aren't writing code. Neither
of us were suggesting that brevity necessarily makes for more
maintainable code (indeed, my case for static typing is essentially that
while you end up typing more, it pays off in that it makes your code
more readible).
In general, I don't see why you'd think that XP would be particularly
bad in this mode.
Lack of documentation. Lack of real design or design documents. Code
thats constantly in flux, leaving it hard to find a dev that
understands most of it. Cruft and hacks from trying to make a two
week milestone, rather than spending time to do things the right way.
I'd maintain a program under any other process, including the much
maligned waterfall, before I'd touch one done by XP.
Yeah, those things are all a sign of XP done wrong. There should be real
documentation, especially design docs. There should be design. In fact,
there should be more design than on a normal project. The code should
actually be less in flux than on a normal project (yes, you are
constantly refactoring, but XP projects tend to produce less code per
man week for obvious reasons), although typically some parts of the code
get refactored more than others, those are also the ones where you'd
expect the most developers to have an idea of what's going on there. The
two week milestones shouldn't prevent you from spending time to do
things the right way, it should force you to break down "doing things
the right way" in to a series of small simple steps which are
individually verified, and this tends to reduce cruft and hacks.
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
