Home > Archive > Extreme Programming > July 2005 > extreme programming (thoughts)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
extreme programming (thoughts)
|
|
| matt@mailinator.com 2005-07-24, 8:35 pm |
| (note: i am not an XP expert, nor have i received formal training in
it. rather, im a good developer recently assigned to an xp project.
these are my first impressions. no need to flame, but am interested in
your experiences w/ XP and how they may be different)
so last w or so i was put on a different project at work. my new
assignment is on the "eXtreme Programming" gig -- for the
non-programmers out there, no, im not making this up. its actually
called extreme programming (XP). what makes it so extreme? strange
haircuts and cardboard guitars? no. technie adrenaline junkies? hardly.
free mountain dew? i wish. no, what makes this extreme is that it's
extremely stupid. let me explain.
in xp, you stick all your programmers into one room together. now,
knowing the personal hygiene of some devs, that alone is reason to be
wary. next, you give them half as many computer as they need -- yep, we
have to share computers, 2 devs to a box. one is the "pilot" the other
is the "navigator". this is called paired programming. what more, you
do not have a fixed desk, nor partner. everyone rotates machines and
partners. better hope youve got your flu shots. oh and at least two
daily "stand up" meetings were everyone is forced to, you guessed it,
stand up for the duration.
that is the physical arrangement. there is more to xp than that.
the core idea is nice: fast, flexible design & development. during the
stand up meetings you have the devs, designers, and business owners all
in the room together for hashing out requirements details. things can &
do change, but the cost of development time reflects that, which keeps
the biz owners honest.  .
but it starts to get stupid, fast. rather than estimate in hours or
days, things are qualfied in "nuts". nebulous units of time (NUTs).
each nut is worth a certain number of days, but that figure changes. i
think its designed to prevent the biz owners from having quantatative
expectations, instead "it's all relative, baby".
next is the code.
biggest beef: NO COMMENTING ALLOWED! thats right, we're designing
highly complicated financial systems, and i'm not allowed to document
or include helpful comments for any future developers. the idea is, as
explained to me from the lead, is that this forces better code. because
when some code starts getting bulky or complicated, you just break it
down into smaller methods, and (get this) -- give each method a verbose
descriptive name. you mean a name thats like a..comment?! great. so now
we remove comments, and add tons of extra methods... in effect making
it mandatory for a future programmer to examine (more) program code
line-by-line, scrolling around to find & understand dozens of extra
methods. how elegant! those poor saps.
the last major, major difference is unit testing. rather than draw a
design model, program it, add error handling, and send the app to QA,
we do massive amounts of programmatic unit testing. by this i mean,
write code to test your code. explicity and specifically testing every
possible outcome in a futile attempt to write "bulletproof" code. the
layers of programmatic development i am forced to code are mind
boggling. 80% of my time is spent writing test cases and code, writing
methods to insert & remove data for the tests, etc. and this is with
the aid of NUnit and NUnitASP, popular tools for this process. and it's
still this time consuming. 80% of my time for supporting the other 20%.
and you know what? its futile. because in the end, it *still* has to go
to QA, and they *still* find bugs -- because when you put complex
systems together, weird things happen. theres no quantifiable &
programmatically way to get around that simple truth. humans are
flawed, thus any system we design will have flaws. EOS.
now, put it all together:
- days of busywork writing undocumented code, at a cost of two
programmers
- 10+ people in a room together
- no personal desk, space, cube pictures/decorations, etc..
....and what do you get? a collosial waste of resources, and a
de-humanizing workplace. but damn it looks good on paper.
so did the commies.
matt
--
Matt Del Vecchio
| |
|
| matt wrote:
> biggest beef: NO COMMENTING ALLOWED!
Okay, guys: Even the trolls can answer whether he's really doing XP or not.
But USENET will make a sucky coach. Can't they get a real one??
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| John Liptak 2005-07-24, 8:35 pm |
| In article <1121973424.760800.81430@f14g2000cwb.googlegroups.com>,
<matt@mailinator.com> wrote:
>(note: i am not an XP expert, nor have i received formal training in
>it. rather, im a good developer recently assigned to an xp project.
>these are my first impressions. no need to flame, but am interested in
>your experiences w/ XP and how they may be different)
My company went to XP and them back to a little more waterfall
like process. Some of what I have to say is about the way WE did
things vs. the way you seem to be forced to do things.
>
>so last w or so i was put on a different project at work. my new
>assignment is on the "eXtreme Programming" gig -- for the
>non-programmers out there, no, im not making this up. its actually
>called extreme programming (XP). what makes it so extreme? strange
>haircuts and cardboard guitars? no. technie adrenaline junkies? hardly.
>free mountain dew? i wish. no, what makes this extreme is that it's
>extremely stupid. let me explain.
>
>in xp, you stick all your programmers into one room together. now,
>knowing the personal hygiene of some devs, that alone is reason to be
>wary. next, you give them half as many computer as they need -- yep, we
>have to share computers, 2 devs to a box. one is the "pilot" the other
>is the "navigator". this is called paired programming. what more, you
>do not have a fixed desk, nor partner. everyone rotates machines and
>partners. better hope youve got your flu shots. oh and at least two
>daily "stand up" meetings were everyone is forced to, you guessed it,
>stand up for the duration.
We only did pair programming on request. Like the real XP, your
not really allowed to say no when asked, but people had their own
computers etc.
This had the positive effect of making good written documentation
a priority. If you didn't write it well enough, you had to sit with
the person and explain it. And if they were working from India, you
had to work strange hours to do so.
We only had stand up's once a day (actually, we still have them).
Standing keeps the meetings short.
>
>that is the physical arrangement. there is more to xp than that.
>
>the core idea is nice: fast, flexible design & development. during the
>stand up meetings you have the devs, designers, and business owners all
>in the room together for hashing out requirements details. things can &
>do change, but the cost of development time reflects that, which keeps
>the biz owners honest. .
Ok, standups are NOT about hashing out requirements. The requirements,
planning game, etc. don't have to be hard.
>
>but it starts to get stupid, fast. rather than estimate in hours or
>days, things are qualfied in "nuts". nebulous units of time (NUTs).
>each nut is worth a certain number of days, but that figure changes. i
>think its designed to prevent the biz owners from having quantatative
>expectations, instead "it's all relative, baby".
Some developers estimate high. Some developers estimate low. Estimating
in NUTs (good name btw), has the advantage of self-correcting for
estimating acuracy problems. In the end; however, it comes back to the
same thing: the customer can have x NUTs per iteration and nX NUT's
per release. That way you don't get into an argument about "It should
not take 12 hours to do Y".
>
>next is the code.
>
>biggest beef: NO COMMENTING ALLOWED! thats right, we're designing
>highly complicated financial systems, and i'm not allowed to document
>or include helpful comments for any future developers. the idea is, as
>explained to me from the lead, is that this forces better code. because
>when some code starts getting bulky or complicated, you just break it
>down into smaller methods, and (get this) -- give each method a verbose
>descriptive name. you mean a name thats like a..comment?! great. so now
>we remove comments, and add tons of extra methods... in effect making
>it mandatory for a future programmer to examine (more) program code
>line-by-line, scrolling around to find & understand dozens of extra
>methods. how elegant! those poor saps.
What a stupid rule. We never had it. The requirement is to focus
on communication and testing. So lets say that some code is not very
clear. You could (a) comment it or (b) refactor it.
For a:
+ Some people write better comments than code
+ You can express some issues better in written words
+ You can have examples.
- People don't always keep the code in sync
For b:
+ your unit tests are usually easier
+ your unit tests are usually better
+ it's in sync with the code
- if done poorly it can cause navigation issues in understanding
In my experience, good comments include things like:
* What pattern your implementing
* copy paste from sample input data (in the unit test)
* things done differently than you would expect. This is real
important. The code ONLY shows what works. If you spent 40
hours finding out that the obvious does not work it NEEDS a
comment.
My today personal favorite: A Weblogic integration business
process (jpd) web service that is done as a doc/literal from
workshop will incorrectly generate the client jar file if the
top level element of the document also has a defined type.
That needs a comment.
>
>the last major, major difference is unit testing. rather than draw a
>design model, program it, add error handling, and send the app to QA,
>we do massive amounts of programmatic unit testing. by this i mean,
>write code to test your code. explicity and specifically testing every
>possible outcome in a futile attempt to write "bulletproof" code. the
>layers of programmatic development i am forced to code are mind
>boggling. 80% of my time is spent writing test cases and code, writing
>methods to insert & remove data for the tests, etc. and this is with
>the aid of NUnit and NUnitASP, popular tools for this process. and it's
>still this time consuming. 80% of my time for supporting the other 20%.
>and you know what? its futile. because in the end, it *still* has to go
>to QA, and they *still* find bugs -- because when you put complex
>systems together, weird things happen. theres no quantifiable &
>programmatically way to get around that simple truth. humans are
>flawed, thus any system we design will have flaws. EOS.
We never spent 80% of our time writing tests. Again, it sounds like
you have gone to the extreme here. The goal is not "bulletproof" code.
The goal is reduced bugs.
If you design your tests along with the code, you will find that your
code is structured differently. You should not have to write a lot
of code to "insert & remove data". The methods in your classes should
be PROVIDED the data that they work on.
This is the critical difference between good unit test code and bad
unit test code (and the code it tests). You should be able to run
almost all of your unit tests WITHOUT hitting a database. You will
find that your code will have a bunch more Factory classes. Those
factory classes will be subclassed for your unit tests to provide
"canned" data. In Java we use anonymous inner classes to extend those
unit test canned factories to provide an "different" data we need for
a particular test.
Yes, your QA will still be needed. But good unit testing will make you
much *MORE* producting and your code quality better.
>
>now, put it all together:
>
>- days of busywork writing undocumented code, at a cost of two
>programmers
>- 10+ people in a room together
>- no personal desk, space, cube pictures/decorations, etc..
>
>...and what do you get? a collosial waste of resources, and a
>de-humanizing workplace. but damn it looks good on paper.
And as long as it's not treated as a religion, it works very
well in practice. We went back to a more waterfall way of
working, but iterations, standups and unit testing are still
working out very well here.
>
>so did the commies.
>
True, but I found XP much more democratic that you do. We could
discuss trade offs with our clients.
>
>matt
>
>--
>Matt Del Vecchio
>
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| i work for a big bucks credit card company. they brought in "coaches".
i wasnt in on the initital project w/ the coaches, but this the
knowledge our xp consultants are passing on to me now. they have it
wrong?? that would be a Good Thing (tm), imo!
matt
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| john,
thanks for your comments. as this is my first experience w/ xp, and
first time talking to outside devs about it, it is good to hear its not
all as ours is. our group is very strict about following what the
coaches taught them.
good to know about the commenting, for example. tho im not sure i agree
about better unit testing w/ the other way... i generally like to
comment things such that one can "skim" the code, w/o having to
actually read/analyze each line. obviously that means not all the
commented code is particularly obscure (and thus worthy of an
individualized method/test).
again on the paired programming. make no mistake, i like working with
others and have no problem asking/responding to requests for "extra
eyes" or opinions. but i really detest the removal of personalized
cubespace. i believe that people need their own space, to be happy and
to try things. w/o that space we are pushing ourselves into automaton
territory.
agreed on the stand ups. i mis-rep'd that a bit, im afraid. we do keep
them between 15-20 minutes, sometimes less if no issues.
interesting about your unit testing sans db. i wish! my first day was
spent writing helper "TestsDA" classes for inserting relative data into
the db, and removing it. besides C#, whole lotta SQL invested there....
perhaps if we had some framework of factory classes for testing that
would ease the pain. interesting.
matt
| |
|
| matt wrote:
> interesting about your unit testing sans db. i wish! my first day was
> spent writing helper "TestsDA" classes for inserting relative data into
> the db, and removing it. besides C#, whole lotta SQL invested there....
> perhaps if we had some framework of factory classes for testing that
> would ease the pain. interesting.
Yes! Refactoring your tests should have emerged exactly these "factory
classes".
Like I diagnosed elsewhere, your team does not refactor enough, and does not
refactor the test-side enough at all.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| John Roth 2005-07-24, 8:35 pm |
|
<matt@mailinator.com> wrote in message
news:1121981621.641585.321800@o13g2000cwo.googlegroups.com...
> john,
>
> thanks for your comments. as this is my first experience w/ xp, and
> first time talking to outside devs about it, it is good to hear its not
> all as ours is. our group is very strict about following what the
> coaches taught them.
Which means that they haven't gotten it yet. "The Rules" are there
as training wheels for learning. Once you've gotten it, you'll find
that you'll change some things around, and you'll still have something
that most of us would recognize as "XP".
> good to know about the commenting, for example. tho im not sure i agree
> about better unit testing w/ the other way... i generally like to
> comment things such that one can "skim" the code, w/o having to
> actually read/analyze each line. obviously that means not all the
> commented code is particularly obscure (and thus worthy of an
> individualized method/test).
The whole "no comment" thing is a bit overblown. Good code is
clear code, and clear code doesn't need comments. However,
there are lots of reasons why one might want to comment
something. The critical issue is to keep one's eye on clarity: if you
find a need to comment something, always ask whether the code
could be made clearer so that the comment wouldn't be needed.
> again on the paired programming. make no mistake, i like working with
> others and have no problem asking/responding to requests for "extra
> eyes" or opinions. but i really detest the removal of personalized
> cubespace. i believe that people need their own space, to be happy and
> to try things. w/o that space we are pushing ourselves into automaton
> territory.
A good War Room has personalized space, usually along the
sides. It's impossible to pair more than about six hours a day,
and it's important to have a desk and system that you can use
for keeping up with mail, etc.
> agreed on the stand ups. i mis-rep'd that a bit, im afraid. we do keep
> them between 15-20 minutes, sometimes less if no issues.
Actually, a standup shouldn't be about issues. It's about trading
plans so that everyone is on the same page. Issues are worth
about 30 seconds - then they should be taken offline.
> interesting about your unit testing sans db. i wish! my first day was
> spent writing helper "TestsDA" classes for inserting relative data into
> the db, and removing it. besides C#, whole lotta SQL invested there....
> perhaps if we had some framework of factory classes for testing that
> would ease the pain. interesting.
One of the core processes in XP is Test Driven Development, or TDD.
If you're not doing TDD, you can't be doing XP (although the reverse
isn't true: lots of people do TDD without doing XP, and it works
quite well for them).
TDD depends on running your complete suite of unit tests continuously,
which in turn means that they have to run fast. Like hundreds a second.
You can't do an external DB (or much of anything else) and hit that
speed requirement.
Those same tests, however, do need to run with a real data base
during the integration tests (which you run during checkin) or the
nightly build/integrate/test/package/trial deploy cycle.
And it does take a while to learn TDD - usually about six months
or so.
John Roth
>
>
> matt
>
| |
|
| John Roth wrote:
> A good War Room has
Please. We prefer the term "Peace-Challenged Room".
--
Karl Rove
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
|
| John Roth wrote:
> And it does take a while to learn TDD - usually about six months
> or so.
And who was this coach? I have an idea who based on "NUTs"...
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| oh, its TDD. i mean we think it is.. we have NUnit integrated into our
IDE, have a test for each method, test the controls (.NET), NUnitASP
for testing the pages, button clicks, etc... theres a lot of testing.
but it sure isnt fast -- believe its 2 minutes to run all of proj's
tests. lots of da layer interaction... definately not using the
technique youve described for reserving db access to the build box.
for instance, my first task was building a databound list control. much
time was spent getting the specific relational data into the db, as my
buddy explained we cant assume the data to be there. after doing that,
we wrote tests to test the data coming back from the proc's resultset.
not sure how we'd do it otherwise -- dont we need to, you know, call
the proc to test our new proc as well as the databinding?
matt
| |
|
| matt wrote:
> oh, its TDD. i mean we think it is.. we have NUnit integrated into our
> IDE, have a test for each method, test the controls (.NET), NUnitASP
> for testing the pages, button clicks, etc... theres a lot of testing.
> but it sure isnt fast -- believe its 2 minutes to run all of proj's
> tests. lots of da layer interaction...
Hmm. TDD means you write failing tests, write code to pass the tests, and
refactor to improve design and test speed.
In this case, I think your biggest bottleneck is ASP's pathetic integration
with a server.
> definately not using the
> technique youve described for reserving db access to the build box.
When you reply with Google Groups, please use Preview->Edit to leave in the
replied-to text. I think your reply to John Roth.
> for instance, my first task was building a databound list control.
AAaarrg. Okay, you have three bottlenecks - databound controls, testing thru
the GUI to get to the business features, and ASP's HTTP/HTML round trip.
> much
> time was spent getting the specific relational data into the db, as my
> buddy explained we cant assume the data to be there. after doing that,
Did you ask your buddy why your test rig did not already have bottled
methods you could re-use to blast a standard database into the db layer?
> we wrote tests to test the data coming back from the proc's resultset.
> not sure how we'd do it otherwise -- dont we need to, you know, call
> the proc to test our new proc as well as the databinding?
Read this:
http://www.objectmentor.com/resourc...leDialogBox.pdf
It says you should test the capacity of the GUI independent from the GUI,
meaning you should build an isolated, server-side module with the same shape
as the GUI, but no GUI controls in it.
The GUI Layer itself should be thin, and your biggest problem on this
project is the amount of crap you must write to test-thru the GUI.
So, in conclusion, you have discovered ASP sucks. XP just illustrated this
for you, so you decided to blame XP in hopes to go back to debugger-oriented
code-and-fix in ASP.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| philip,
you are incorrect. my message, #10, was a reply to john's, #7. the
google nav-tree comfirms this.
i prefer not to keep the reply-to text in my replies, its wasted space
to me.
> TDD means you write failing tests, write code to pass
> the tests,
yes, and thats what we're doing; thats what i mean when i say we use
"NUnit integrated w/ the IDE". we have test classes that we code for
the different methods, then we run those tests in visual studio -- it
compiles, builds, tests, reports.
then there are the NUnitASP tests, which arent testing the methods-only
(as NUnit does), but test thru the web interface. have you used these
tools?
> your biggest problem on this project is the amount of
> crap you must write to test-thru the GUI.
...agreed, its a pain in the ass. but we test both, gui testing and
plain method testing in the IDE.
> So, in conclusion, you have discovered ASP sucks.
> XP just illustrated this for you, so you decided to
> blame XP
....you do realize im rereferring to ASP.NET, and not "ASP", right? if
so, then i would strongly disagree with you. while off-topic, asp.net
(C#) is a very capable web language for building web apps. it's object
model is nearly identical to that of window's forms, C# is just dandy,
and the IDE (debugger) is usually pleasant to work with. in short, it
does what i want it to and thus does not suck.
so no, that isnt why i have issues w/ xp. thanks tho.
matt
| |
|
| matt wrote:
> you are incorrect. my message, #10, was a reply to john's, #7. the
> google nav-tree comfirms this.
Not everyone can use nav-trees.
> i prefer not to keep the reply-to text in my replies, its wasted space
> to me.
USENET is a volunteer system that works best with complete, readable posts.
Trim your quotes to not waste space, but leave in just enough context.
(Heck - we are back to simple rules with a profound effect again!)
>
> yes, and thats what we're doing; thats what i mean when i say we use
> "NUnit integrated w/ the IDE". we have test classes that we code for
> the different methods, then we run those tests in visual studio -- it
> compiles, builds, tests, reports.
>
> then there are the NUnitASP tests, which arent testing the methods-only
> (as NUnit does), but test thru the web interface. have you used these
> tools?
No, but I know testing thru HTML and HTTP is very hard.
So either way a test takes seconds to return results, right? And you write
failing tests, and check they fail for the correct reason, before writing
passing code, right?
> ..agreed, its a pain in the ass. but we test both, gui testing and
> plain method testing in the IDE.
And then you refactor to resolve duplication, in both the code and tests,
right? So subsequent tests become easier to write?
> ...you do realize im rereferring to ASP.NET, and not "ASP", right? if
> so, then i would strongly disagree with you. while off-topic, asp.net
> (C#) is a very capable web language for building web apps. it's object
> model is nearly identical to that of window's forms, C# is just dandy,
> and the IDE (debugger) is usually pleasant to work with. in short, it
> does what i want it to and thus does not suck.
If ASP.NET didn't suck, it would be easier to test-first.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| > Not everyone can use nav-trees.
not my bag, man.
> USENET is a volunteer system that works best with complete, readable posts.
well, then call me crazy because back when i ran a bbs for distributing
FidoNet, we tried to encourage minimizing posting bandwidth in order to
save our pocketbooks the long distance. i usually address or quote
where i find it appropiate. if it's still too confusing, perhaps
another reader may help you.
> No, but I know testing thru HTML and HTTP is very hard.
i definately hear that. NUnit is an open-source unit testing framework
for .net. it tries to alleviate the pain. yes, you write you tests
first, they fail, you begin working on passing tests. maybe ill post
some samples or something later.
> If ASP.NET didn't suck, it would be easier to test-first.
....flamebait avoided. the platform should have little, if anything, to
do w/ the ability to test. i get the feeling you dont practice xp on a
web platform, so im really not sure what you are comparing asp.net to.
only another web platform would be valid, and there i fail to see how
it would be any easier. more, if xp *were* easier on one web platform
over another, then i would question its overall practicality.
matt
| |
|
| matt wrote:
>
> ...flamebait avoided. the platform should have little, if anything, to
> do w/ the ability to test.
The ability to test means the ability to rapidly submit to program control
outside a narrow envelop. I have researched hard-to-test-first things for
years, and the HTTP-HTML pipe is near the top of the list. If you can't
test-first a given platform, then there are many other things you can't do
with it.
> i get the feeling you dont practice xp on a
> web platform
I wrote a chapter of a book on it. Oh, also a few HTML-oriented projects.
None using ASP.NET on a public web site. Maybe ASP.NET is just so special
that nothing I know about the topic in general applies.
But we are too far afield. How easy are new tests to write, how fast do
tests for one module run, and how decoupled is your GUI Layer from your
logical stuff?
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| if you are not familar w/ ASP.NET, then you should definately check it
out before your next book revision, lest you suggest it sucks...
legacy ASP was a total pain in the ass, but ASP.NET is very similar to
doing windows vb/forms apps. the event model is nearly the same, its
server-side code, namespaces, class libraries compiled into .DLLs, etc.
in fact i believe they made it just like windows on purpose to make
traditional app developers more comfortable.
so much of the testing is simply done on the project's classes, which
are typically developed in MS Visual Studio 2003, the most popular IDE.
the business logic tests are written in a seperate project w/i the same
parent solution as the business logic itself. at that step they are not
gui-aware. later you write tests for that. datalayer classes are
likewise in a seperate project unrelated to the web/gui. in the real
world, these logic projects are compiled into stand-alone .DLLs,
dropped into a web app's /bin folder. the consuming web app then
references the assembly, and calls its methods. very little suckage,
and special only in that its way easier than before.
as for how easy it is to write, ask me next w. the 5 tests for my
data-retriving methods (consumed by my web control) take about 12
seconds, but im pretty sure thats including build time for the project.
matt
| |
|
| matt wrote:
> so much of the testing is simply done on the project's classes...
> the business logic tests...not gui-aware...
> as for how easy it is to write, ask me next w. the 5 tests for my
> data-retriving methods (consumed by my web control) take about 12
> seconds, but im pretty sure thats including build time for the project.
Those are all very healthy indicators. Maybe this XP thing isn't sucking
after all.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| > Those are all very healthy indicators. Maybe this XP thing isn't sucking
> after all.
i think the way i wrote that was confusing -- it takes about 12 seconds
to execute the 5 tests. writing them (and the sql tests, and the gui
tests) took a couple days.
i stand by my original post -- xp, as it is known at my organization,
is not an attractive solution to me thus far. i am still in the
learning curve, so perhaps i am not an ideal judge. but....the amount
of time ive spent writing test cases for this very simple data
retrieval & binding control is insane. this is a task which i could
wrap up in a couple of hours. as part of that time, i would have error
handling & error logging. i just find it very hard to believe that *if*
there were any bugs w/ my control, it would have taken more time to
debug & fix it than i spent writing tests. whats more, we must double
that time, since there were two of us -- would it really take me *four
days* to debug a problem in this control!? of course not.
now multiply this for every control, every peice of code everywhere.
adding up all those (double) man hours, i simply cant imagine QA &
future debug time being as expensive as development+test time. theres
no way. in all my years of webdev, ive just never had to spend that
kind of time on debugging.
but like i said, i develop financial loan application websites -- not
powergrids. maybe the manhours spent on this testing are more useful to
serious apps, because the code i see in my industry seems to get
re-written every few years anyway.......
matt
| |
|
| matt wrote:
>
> i think the way i wrote that was confusing -- it takes about 12 seconds
> to execute the 5 tests. writing them (and the sql tests, and the gui
> tests) took a couple days.
Eek. After writing each intermediate test you watched it fail (if you
intended it to fail), and then made it pass, right?
Those tests were each like 5~15 minutes to write, right?
> i stand by my original post -- xp, as it is known at my organization,
> is not an attractive solution to me thus far.
There is something very wrong with your situation. The other 10 programmers
should have been making sure tests are easier to write, over time.
You are the user of the test-side code, and your team should attend to its
usability.
> i am still in the
> learning curve, so perhaps i am not an ideal judge. but....the amount
> of time ive spent writing test cases for this very simple data
> retrieval & binding control is insane. this is a task which i could
> wrap up in a couple of hours.
In general, yes, writing new test for a completely untested, legacy system
might take that long.
You don't have a "legacy" system, meaning a test-free system.
Does _everyone_ there take longer than 5-10 minutes per new test?
> as part of that time, i would have error
> handling & error logging. i just find it very hard to believe that *if*
> there were any bugs w/ my control, it would have taken more time to
> debug & fix it than i spent writing tests. whats more, we must double
> that time, since there were two of us -- would it really take me *four
> days* to debug a problem in this control!? of course not.
Sorry, that's the advanced gains you get if you all do TDD right. You are
not doing it right, so you are correct to note that what you are doing can't
lead to those benefits.
Please read the TDD PDF I fronted, and report any discrepancies.
If you find none, I would need you to write a _detailed_ description of your
current activities, so _I_ can extend my paper to cover the misconceptions
you endure!
You might also like to take a scratch project (such as "convert integers to
roman numerals", or "score a bowling game"), and write it with Pure TDD, as
I specified, and watch how rapid development gets.
> now multiply this for every control, every peice of code everywhere.
> adding up all those (double) man hours, i simply cant imagine QA &
> future debug time being as expensive as development+test time. theres
> no way. in all my years of webdev, ive just never had to spend that
> kind of time on debugging.
Again, your team is not getting the basic advantages, so they can't expect
the advanced ones. If TDD were truly like your experience, _nobody_ would
write books about it!!
I suspect that the pair programming has had a mild di vantage: To
reinforce a bad form of TDD, to support it, and to teach it. You guys really
need more coaching. (And sorry about my other post[s], but I'm considered
one of the more polite ones!)
Another metric question: How long is the average test case, from top to
bottom? 5 lines? 15 lines? 50 lines?
> but like i said, i develop financial loan application websites -- not
> powergrids.
What's the difference? The first titular XP project was an HR Payroll
application. Who mentioned powergrids?
> maybe the manhours spent on this testing are more useful to
> serious apps, because the code i see in my industry seems to get
> re-written every few years anyway.......
Oh, that's another thing. Code written via XP tends to have very good
staying power. No more rewrites.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| E. U. Reka 2005-07-24, 8:35 pm |
| I wish XP were more relevant to me. Anyone else hear the crickets or
is it just me?
| |
|
| E. U. Reka wrote:
> I wish XP were more relevant to me. Anyone else hear the crickets or
> is it just me?
How is your defect rate? How much time per day do you spend with no
alternative but to use a debugger and hunt some weird bug?
How long is the average time between your business side requests a feature
and your users have it?
If you have good answers to those questions, we all need to hear what you
are doing!
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| E. U. Reka 2005-07-24, 8:35 pm |
| Sorry, I guess I should move on if those questions are what are
relevant here. There doesn't seem to be any time for metrics in
applications/integration/web arena. We're not even supposed to be
developing software according to the higher ups.
I'll tell you this: the average time between business side requests a
feature has decreased dramatically not because we write a zillion unit
tests on a bloated overly-rationalized Java or .NET. It's because we
switched to LAMP. I don't have a metric on it. There is more joy
throughout the food chain however.
Here's a possibly relevant problem: When I do write a "module", I do
it TDD. But then the module changes hands and is no longer done TDD--
the test cases dropped, the time to see results of a change goes from
1 second to 15 minutes.
Here's another one: when the developers first see a problem,
immediately they want to normalize tables and do design upfront. How
do you tactfully fight against premature normalization? I prefer to
not break off the address table for example. I've been through enough
extract-translate-load tasks to never want to normalize anything again.
What do you do? Give them a dozen ETL tasks on unnecessarily
normalized tables until they get the message?
The problem is developers who want to do BDUF don't know how to define
a problem. Those who know what design is don't see a spark plug when
they look at a spark plug. And they'd know when to do design. Where
are those people?
| |
|
| E. U. Reka wrote:
> I'll tell you this: the average time between business side requests a
> feature has decreased dramatically not because we write a zillion unit
> tests on a bloated overly-rationalized Java or .NET. It's because we
> switched to LAMP. I don't have a metric on it. There is more joy
> throughout the food chain however.
If only this LAMP could shine on more PHBs...
> Here's a possibly relevant problem: When I do write a "module", I do
> it TDD. But then the module changes hands and is no longer done TDD--
> the test cases dropped, the time to see results of a change goes from
> 1 second to 15 minutes.
Not even. You went from 1 second with high bug resistance, to 15 minutes
_without_ assurance that all your behaviors were defended. So after the 15
minutes there is a higher chance of hidden bugs.
> Here's another one: when the developers first see a problem,
> immediately they want to normalize tables and do design upfront. How
> do you tactfully fight against premature normalization? I prefer to
> not break off the address table for example. I've been through enough
> extract-translate-load tasks to never want to normalize anything again.
> What do you do? Give them a dozen ETL tasks on unnecessarily
> normalized tables until they get the message?
Teams who have drank the Koolaid and can't live without testing and
refactoring, they invest in time, up-front, to build an extra layer around
their database, to make it behave like a reasonable module and submit to
refactoring.
Without that extra time and investment, refactoring a database is very hard
(and again introduces the risk of hidden bugs). So databases and GUIs become
the standard excuses why TDD is hard. Don't blame TDD if some legacy module
was not written via TDD!
> The problem is developers who want to do BDUF don't know how to define
> a problem. Those who know what design is don't see a spark plug when
> they look at a spark plug. And they'd know when to do design. Where
> are those people?
I thought we were trying to make sure we don't need them. That makes them
more effective when we get them.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Pawel Slusarz 2005-07-24, 8:35 pm |
| <matt@mailinator.com> wrote in message
news:1121990513.915968.76400@g44g2000cwa.googlegroups.com...
> you are incorrect. my message, #10, was a reply to john's, #7.
the
> google nav-tree comfirms this.
>
> i prefer not to keep the reply-to text in my replies, its
wasted space
> to me.
Compliance with voluntary standards is a good thing, though.
http://www.netmeister.org/news/learn2quote.html
http://www.cs.tut.fi/~jkorpela/usenet/brox.html
This is the first time I see someone questioning the Netiquette.
Are you sure your problem is with XP only?
Paul
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| those are good questions, philip! i will try to get some answers. i had
a big install last nite (non-xp), so i havent been on it. get back to
you next w.
matt
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| > This is the first time I see someone questioning the Netiquette.
> Are you sure your problem is with XP only?
get real, loser. theres absolutely nothing wrong w/ my posts. i quote
a minimal amount of text -- only the punkass lines that i have an issue
with, as above. ive probably been posting to newsgroups before you knew
how to install windows. back in the fidonet days we were extremely
concerned about wasted bandwidth on our little 2400 baud modems.
if you would prefer i quote your whole damn messages then keep
dreaming.
and way to jab me about my "problem". so far, you give a stranger the
idea that xp users in this group are no different than the fanboys in a
starwars group -- you respond to criticism of your beloved ideal by
lashing out at the person. nice.
matt
| |
| E. U. Reka 2005-07-24, 8:35 pm |
| Phlip wrote:
> E. U. Reka wrote:
>
>
> Not even. You went from 1 second with high bug resistance, to 15 minutes
> _without_ assurance that all your behaviors were defended. So after the 15
> minutes there is a higher chance of hidden bugs.
Ok, not 15 minutes. 30 min, 2 hours, 1 hour, two months,
whatever, just throwing dice now. The ability to set breakpoints would
not fix this. Ok, this is unmanageable--I can tell you because I have
a certain method that it will be fixed, I just can't say when with any
solid basis. Perhaps that "when" question is what is answered with a
consistent practice.
>
>
> Teams who have drank the Koolaid and can't live without testing and
> refactoring, they invest in time, up-front, to build an extra layer around
> their database, to make it behave like a reasonable module and submit to
> refactoring.
Ignoring "team" for now...
The layer is either never enough or it's too much. And then it's time
to retire. I've started jamming everything into one table turned
sideways. I did a SQL self-joined 45 times to extract to a
spreadsheet. Wasn't too bad. Either SQL or business logic can extract
the sideways table to spreadsheet.
This works for me but I can't expect The Team or an Industry to do it
this way. So we'll do it the old crappy way.
>
> Without that extra time and investment, refactoring a database is very hard
> (and again introduces the risk of hidden bugs). So databases and GUIs become
> the standard excuses why TDD is hard. Don't blame TDD if some legacy module
> was not written via TDD!
It'd be easy if you turned columns into rows and did EJBs they way they
are mean't to be done but nobody ever talks about. Not even in
Mastering EJBs will they talk about it. Don't have columns with
business names. Moving the table sideways generates a lot of testable
business logic. But no, even in Mastering EJBs they talk about an
"address table" or an "account table" with columns that encode the
semantic meaning. Then drench the thing in two layers of liquid
nitrogen(XML) so that it's a nightmare to change anything. (This
sideways table is very stable and would not change, the columns being
metadata, drenching in XML would be fine).
>
>
> I thought we were trying to make sure we don't need them. That makes them
> more effective when we get them.
>
Yeah ok there is no need for phases. We're talking effectiveness.
There is a simultaneous problem
definition/ranking/testing/implementation/delivery of individual
unwanted effect resolutions or features in XP.
Think we'd end up with a sideways table if we only DTSTTCPW this way
breaking it down to individual wanted/unwanted effects? I think we're
still pretty biased if the first thing we think about is breaking out
an address table...
| |
|
| E. U. Reka wrote:
> Think we'd end up with a sideways table if we only DTSTTCPW this way
> breaking it down to individual wanted/unwanted effects? I think we're
> still pretty biased if the first thing we think about is breaking out
> an address table...
(DTSTTCPW means Do Simple Things, folks, related to You Aren't Gonna Need
It.)
On an XP project, the two things you will need, up front, are tests and
refactoring. So you invest a little to learn to test your GUI, and a little
to make sure your DB schema is refactorable. Those are phases.
XP didn't break. The legacy code we must adapt to XP broke.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| E. U. Reka 2005-07-24, 8:35 pm |
|
Phlip wrote:
>
> to make sure your DB schema is refactorable. Those are phases.
Do you have a pointer to the "Best Practices for Refactorable DB
Schemas" page that must surely exist? I can toss that around to at
least get them to stop what they're doing.
>
> XP didn't break. The legacy code we must adapt to XP broke.
What I got out of this thread is a renewed sense that the current
process we use is in fact completely unmanageable. Thanks.
| |
|
| E. U. Reka wrote:
>
> Do you have a pointer to the "Best Practices for Refactorable DB
> Schemas" page that must surely exist?
Scott Ambler seems to have staked out the Database Refactoring niche, but I
can't vouch for its contents:
http://www.google.com/search?q=refa...se+scott+ambler
> I can toss that around to at
> least get them to stop what they're doing.
Hmm. Will throwing documentation at colleagues improve process? Hmm. I'l
have to get back to you about that one.
> What I got out of this thread is a renewed sense that the current
> process we use is in fact completely unmanageable. Thanks.
You're welcome. (I think!)
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| CBFalconer 2005-07-24, 8:35 pm |
| matt@mailinator.com wrote:
>
>
> get real, loser. theres absolutely nothing wrong w/ my posts. i
> quote a minimal amount of text -- only the punkass lines that i
> have an issue with, as above. ive probably been posting to
> newsgroups before you knew how to install windows. back in the
> fidonet days we were extremely concerned about wasted bandwidth
> on our little 2400 baud modems.
.... snip ...
No, I don't think your only problem is with XP only. I am not
going to fuss about heavy snippage, but you really should leave
attributions in for what you do quote, and leave an indication of
snippage where you do snip.
What makes you think high speed 2400 baud modems are anything
special? We used lots of 1200, even 300. Things were somewhat
improved when we could replace ARC/ARCE with LHARC. And I don't
recall MsgEd having any problems doing proper quoting. Binkley
also worked.
"Anything you can do I can do better" includes crotchetiness.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
| |
| Ilja Preuß 2005-07-24, 8:35 pm |
| Matt,
I'm curious - what was your intent in posting this post to an Extreme
Programming discussion group?
Cheers, Ilja
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| > "Anything you can do I can do better" includes crotchetiness.
youre still a punk. have fun in your little xp sandbox.
| |
| matt@mailinator.com 2005-07-24, 8:35 pm |
| > I'm curious - what was your intent in posting this post to an Extreme
> Programming discussion group?
to get some input from other xp teams. to find out if theyre all like
ours (painful).
so far, 95% of the posts are from trainers/authors. would be interested
in getting more dev feedback.
matt
| |
|
| matt wrote:
>
> youre still a punk. have fun in your little xp sandbox.
Sorry to interrupt the fun, but you aren't following carefully if you think
CBFalconer is an eXtremo.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| John Roth 2005-07-24, 8:35 pm |
| <matt@mailinator.com> wrote in message
news:1121980510.504547.309330@g49g2000cwa.googlegroups.com...
>i work for a big bucks credit card company. they brought in "coaches".
> i wasnt in on the initital project w/ the coaches, but this the
> knowledge our xp consultants are passing on to me now. they have it
> wrong?? that would be a Good Thing (tm), imo!
Who were the coaches from? Unfortunately, the only thing in your
post that gives me a clue is the term "NUT", which unfortunately
has wandered all over the place from its original home, so it's not
much of a clue.
I don't get the impression that there was a decent knowledge
transfer from the coaches to the team. That could either be
because the coaches were the typical "big consulting company"
consultant who has no practical experiance, or they weren't on
site long enough to actually transfer knowledge in a practical
fashion.
John Roth
>
> matt
>
| |
| John Roth 2005-07-24, 8:35 pm |
|
<matt@mailinator.com> wrote in message
news:1122154300.766886.309760@f14g2000cwb.googlegroups.com...
>
> to get some input from other xp teams. to find out if theyre all like
> ours (painful).
>
> so far, 95% of the posts are from trainers/authors. would be interested
> in getting more dev feedback.
Of the people who've answered you, Phlip and Ilia are both working
developers. I'm also a developer, somewhat retired and responsible
for the Python port of Fit. I don't know who the others are; I've never
heard of them.
John Roth
>
>
> matt
>
| |
| CBFalconer 2005-07-24, 8:35 pm |
| matt@mailinator.com wrote:
>
>
> youre still a punk. have fun in your little xp sandbox.
PLONK. Enjoy playing with yourself.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
| |
|
| matt wrote:
[color=darkred]
> to get some input from other xp teams. to find out if theyre all like
> ours (painful).
Yup. That's why there's a newsgroup. It's just us and news:rec.omasochism
> so far, 95% of the posts are from trainers/authors. would be interested
> in getting more dev feedback.
I resent the implication I'm a trainer or author. I have trained quite a few
by authoring posts on the 'net, but the majority of my daily work is just
testing, coding, refactoring, and pairing.
However, in general, USENET is the cream of the crop of both trolls and
thought leaders.
You might consider an answer to Ilja's question like "I'm trying to learn
how I can help my team, regardless of their religion, function better."
I think he implied he didn't expect that answer.
--
Punk
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
|
| John Roth wrote:
> Of the people who've answered you, Phlip and Ilia are both working
> developers. I'm also a developer, somewhat retired and responsible
> for the Python port of Fit. I don't know who the others are; I've never
> heard of them.
One reason XP spread so fast is anyone who recites the verbiage (accurately
or not) starts sounding like a coach.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Ilja Preuß 2005-07-24, 8:35 pm |
| matt@mailinator.com wrote:
>
> to get some input from other xp teams. to find out if theyre all like
> ours (painful).
Ah, ok - see my other post that should follow, then! :)
| |
| Ilja Preuß 2005-07-24, 8:35 pm |
| Phlip wrote:
> You might consider an answer to Ilja's question like "I'm trying to
> learn how I can help my team, regardless of their religion, function
> better."
>
> I think he implied he didn't expect that answer.
I asked because to me the post sounded more like someone venting his anger.
But as I know that written communication is highly vulnerable to
misunderstandings, I gathered I'd rather ask than draw premature
conclusions.
Expect a more elaborate reply either today or in a couple of days (not sure
wether I'll find the time today).
Cheers, Ilja
| |
| E. U. Reka 2005-07-26, 5:02 pm |
| I can't believe you guys were stupid enough to try XP literally. It's
a HEURISTIC.
| |
|
| E. U. Reka wrote:
> I can't believe you guys were stupid enough to try XP literally.
In many coaches' experiences, trying XP by the book (the _original_ /Extreme
Programming Explained: Embrace Change/) is a lot lower risk than mix and
match.
Yes, you build a common workspace, and install pair stations with dual
keyboards. Yes, you have a planning game, write stories on cards, and
implement them via test-first. Yes, you integrate when the wind blows and
release wly.
A lapse in any of those practices adds risk. Either do things the way you
learned, and slowly increment XP in, or convert all at once to total XP.
Half XP sucks.
> It's a HEURISTIC.
Yes. A Heuristic is a distinction in behavior used to tune a dynamic
attractor. XP attracts good code. Did all tests pass? Yes: Integrate. Did a
test fail unexpectedly? Yes: Undo. Does the onsite customer approve the new
feature? Yes: Mark its card done and pull another one.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Ilja Preuß 2005-07-26, 5:02 pm |
| E. U. Reka wrote:
> I can't believe you guys were stupid enough to try XP literally.
Well, if you read carefully, they didn't.
Cheers, Ilja
| |
| E. U. Reka 2005-07-26, 5:02 pm |
|
Phlip wrote:
> Yes, you build a common workspace, and install pair stations with dual
> keyboards. Yes, you have a planning game, write stories on cards, and
> implement them via test-first. Yes, you integrate when the wind blows and
> release wly.
>
> A lapse in any of those practices adds risk.
I disagree. If we listed the effects of the practices, we could
concievably come up with an even more cost-effective way of achieving
the same effects.
Is XP the ultimate process that contains the ultimate distillation of
practices, or are it's advocates caught in a self-reinforcing belief
system?
>
>
> Yes. A Heuristic is a distinction in behavior used to tune a dynamic
> attractor. XP attracts good code. Did all tests pass? Yes: Integrate. Did a
> test fail unexpectedly? Yes: Undo. Does the onsite customer approve the new
> feature? Yes: Mark its card done and pull another one.
I misspoke. XP is a thought process that contains heuristic practices.
Like any process, it produces results. Results are traceable to
practices--nobody is smart enough to produce results without a process.
If the results aren't predictable enough, you have to either pay more
to add off-the-shelf processes making them more predictable, or invent
locally cheaper processes that are based on the practice of listing the
sought-after effects, to begin with.
| |
| E. U. Reka 2005-07-26, 5:02 pm |
| To read carefully wasn't my intent ;-)
| |
|
| E. U. Reka wrote:
>
> I disagree. If we listed the effects of the practices, we could
> concievably come up with an even more cost-effective way of achieving
> the same effects.
You don't know the practices well enough. Each is minimal, simple to
implement, and _un_balanced. The other practices balance them.
The reason this newsgroup exists is someone found a set of practices that
fit together efficiently.
If your education is still at the stage "Well, pair programming must cost
twice as much", then we are not ready to discuss minimalism yet.
When I said, "A lapse in any of those practices adds risk," I mean doing
many XP practice but not all will unbalance things. For example, without
continuous integration you can't release frequently. That is no excuse to
propose a higher-cost alternative to continuous integration, such as code
ownership.
Another poster on this thread has reported on a project that called itself
"XP", when they really meant "we don't design". The project got in trouble
when changes stressed their poor design.
> Is XP the ultimate process that contains the ultimate distillation of
> practices, or are it's advocates caught in a self-reinforcing belief
> system?
Try it. Maybe you will be seduced by the Light Side too.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| E. U. Reka 2005-07-27, 5:03 pm |
|
Phlip wrote:
> E. U. Reka wrote:
>
>
> You don't know the practices well enough. Each is minimal, simple to
> implement, and _un_balanced. The other practices balance them.
Yeah, I know. I thought about this. For example, PP is unbalanced
because there would be constant argument and offence taken, were it
not for the toolbox of values (simplicity, courage etc), practices
(TDD), and unofficial side heuristics (DTSTTCPW) to that each partner
can call on at any time to take leadership in some way.
I got the unbalanced concept but didn't articulate it.
>
> The reason this newsgroup exists is someone found a set of practices that
> fit together efficiently.
Where did they look?
>
> If your education is still at the stage "Well, pair programming must cost
> twice as much", then we are not ready to discuss minimalism yet.
To introduce PP, you first set it up unbalanced. You don't introduce
it as "ok we're going to interrupt our most senior dude's train of
thought".
>
> When I said, "A lapse in any of those practices adds risk," I mean doing
> many XP practice but not all will unbalance things. For example, without
> continuous integration you can't release frequently. That is no excuse to
> propose a higher-cost alternative to continuous integration, such as code
> ownership.
>
> Another poster on this thread has reported on a project that called itself
> "XP", when they really meant "we don't design". The project got in trouble
> when changes stressed their poor design.
>
>
> Try it. Maybe you will be seduced by the Light Side too.
This may be silly, but wouldn't it be more effective means of
transmission of XP if it were built-up from first principles instead of
us having to swallow these practices without any explanation of what
specific problems(there's an ordinary word) they were solving?
I mean, I've been trained, officially immersed, been looking
off-and-on at it for 5 years, yet I still don't get it. What's it
take? You guys have a covert kernel methodology underneath that
generates your overt methodology phrased in ordinary language. What is
it? Does Tom Cruise know about this?
| |
|
| E. U. Reka wrote:
> Yeah, I know. I thought about this. For example, PP is unbalanced
> because there would be constant argument and offence taken, were it
> not for the toolbox of values (simplicity, courage etc), practices
> (TDD), and unofficial side heuristics (DTSTTCPW) to that each partner
> can call on at any time to take leadership in some way.
The balancing force there is simply TDD. The rhythm of writing tests,
passing them, and refactoring can become as easy and flowing as a video
game.
If you get stuck, you have the ultimate help. Otherwise, you would have to
find someone and explain the situation to them.
The odds of feeling stuck under PP go way down. But pairing while debugging
is a nightmare.
Most of the things here are easy not to do...
http://www.c2.com/cgi/wiki?HowToPissOffYourPair
....that's the point of the page.
cost[color=darkred]
>
> To introduce PP, you first set it up unbalanced. You don't introduce
> it as "ok we're going to interrupt our most senior dude's train of
> thought".
Pleeeeeze let me interrupt our most senior dude's train of thought!
> I mean, I've been trained, officially immersed, been looking
> off-and-on at it for 5 years, yet I still don't get it. What's it
> take? You guys have a covert kernel methodology underneath that
> generates your overt methodology phrased in ordinary language. What is
> it? Does Tom Cruise know about this?
Don't tell anyone this, but XP forms a dynamic attractor within a phase
space of potential code states. Frequent iterations and heuristics, at all
scales, tune this process, allowing entropy to favor elegance. These forces
make the right thing to do also the easiest thing to do.
I think we have all worked in shops where the right thing to do was
hardest...
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
>
| |
| E. U. Reka 2005-07-27, 5:03 pm |
| Thank you Phlip, I think having the un-balancing concept will do the
trick and I can probably guess what you are referring to as minimalism,
orbit taking over...
| |
| Laurent Bossavit 2005-07-27, 5:03 pm |
| EU,
> You guys have a covert kernel methodology underneath that
> generates your overt methodology phrased in ordinary language.
> What is it?
Well spotted, except it's not exactly "covert". Go through the abundant
bibliography in the White Book, and you'll find many of the principles
"underneath". For instance, Weinberg's systems thinking stuff has left
recognizable marks all over XP.
There are two ways you might think about this. Consider a hologram; even
a small piece contains the whole picture. On the other hand, it's better
to have the chicken than to have the chicken soup.
Laurent
| |
| Phlip 2005-07-27, 10:00 pm |
| Here's from a great new thread on the XP mailing list:
Article on XP pathologies?
Paul Butcher wrote:
> I am looking for an article which describes "XP Pathologies".
> Specifically, I'm looking for a list of ways to tell that your local
> implementation of XP is broken and needs remedial action.
>
> I've had a hunt through the various XP books and websites, but can't
> find quite what I'm after - I can't believe that it isn't out there
> though!
In theory, you do each practice in The White Book or The Silver Book,
and it's XP.
In practice, we have learned to identify common failure modes, and
trace them back to missing practices. Several threads on
news:comp.software-eng were sparked on the subject by one "Matt", who
joined a team and could not believe he was expected to pair and "not
write comments". There's an alarm flag already.
His shop, and several others, have since been identified as falling
down on TDD and refactoring. Those often require the loving strokes of
a coach's whip to get right. The symptoms are poor response to
changing requirements.
Unfortunately, several otherwise quite respectable and senior engineers and
team leaders on that newsgroup are still convinced "we tried XP and it
f...ed up our project". They will lecture you ad nauseum that "XP can't
handle changing requirements well", with the fervor of "experience" to back
them up, despite that's the one thing all people who like XP say it does
best.
And you have what they did not...
> - No well defined customer
> - Customer not involved because they "don't have time"
> - "Stories" defined at a technical level, rather than something
> which is meaningful to the customer
> - Developers scheduling stories rather than the customer
> - No planning at all beyond the current iteration
> - No agreed units for story estimates
> - No "coach" role
> - etc. etc. etc.
....a list of the actual failed practices. Without a customer, their
project will fish-tail, and rarely release versions that match
coherent business goals.
This gives you the opportunity to continue the checklist:
- is there a "daily build" system that triggers on each commit?
- does the team use _pure_ TDD?
- does the team continuously integrate?
- what is the point of pairing if they don't TDD?
And so on.
Regardless, you already have enough evidence to raise an alarm. These
guys are goofing off, and have bamboozled their boss to think it's XP.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| E. U. Reka 2005-07-28, 9:09 am |
| Laurent Bossavit wrote:
> Weinberg's systems thinking stuff has left
> recognizable marks all over XP.
I wasn't aware that Weinberg had a claim on systems thinking...isn't
this from Gregory Bateson? And can't we get the info from Principia
Cybernetica? Hopefully not proprietary. I had actually passed on a
w of Weinberg training because because of the goofy Haiku on his
site. Something about open your heart and hug your co-worker and share
all your personal information...I took an XP class instead.
>
> There are two ways you might think about this. Consider a hologram; even
> a small piece contains the whole picture. On the other hand, it's better
> to have the chicken than to have the chicken soup.
Just a hologram of the chicken would be nice..
| |
| E. U. Reka 2005-07-28, 9:09 am |
| Phlip wrote:
> we are not ready to discuss minimalism yet.
Suppose I was ready, what do you mean by "minimalism"? Anything
special or were you using the term loosely?
| |
| E. U. Reka 2005-07-28, 9:09 am |
|
Phlip wrote:
> The balancing force there is simply TDD. The rhythm of writing tests,
> passing them, and refactoring can become as easy and flowing as a video
> game.
This is nice. But I thought everything balanced everything. The
weight and cost of a strict TDD would have to be balanced by other
forces, rapid delivery, maintainability, savings realized from
skipping analysis and design phases, all the way out to the XP culture
itself, which advocates to the bosses. PP alone couldn't balance TDD?
You wouldn't at least balance in threes(3)? TDD/PP/DTSTTCPW?
| |
| Laurent Bossavit 2005-07-28, 9:09 am |
| EU,
> I wasn't aware that Weinberg had a claim on systems thinking...isn't
> this from Gregory Bateson?
Among others. Let's just say I meant "Weinberg's flavor of systems
thinking".
> I had actually passed on a w of Weinberg training because because of
> the goofy Haiku on his site. Something about open your heart and hug your
> co-worker and share all your personal information...I took an XP class instead.
Would the haiku be this one ?
Day One, strangers meet.
Cautiously, souls open up.
Minds expand. Hearts join.
(From a '99 PSL alumnus called "Mike", apparently.)
Laurent
| |
|
| E. U. Reka wrote:
> This is nice. But I thought everything balanced everything. The
> weight and cost of a strict TDD would have to be balanced by other
> forces, rapid delivery, maintainability,
TDD is not heavy.
The two heavy parts are A> banging legacy systems, and B> building a
FIT-style acceptance test rig.
The rest is light. Test cases are slightly easier to write than production
code.
Then (I'm not sure if I have covered this point enough in this thread) you
don't need to debug.
> savings realized from
> skipping analysis and design phases,
You analyze and design more often, with more feedback and support.
> all the way out to the XP culture
> itself, which advocates to the bosses.
?
> PP alone couldn't balance TDD?
PP without TDD is like Pair Googling. "Click on that link!" "No, I want to
start with this search expression!" "I'm getting my own workstation."
Pairing with TDD is like a board game, with a steady rhythm of testing and
coding.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
|
| E. U. Reka wrote:
> Phlip wrote:
>
> Suppose I was ready, what do you mean by "minimalism"? Anything
> special or were you using the term loosely?
You have this idea that all XP practices are big heavy and hard.
The reason we have these discussions in general, and the reason some teams
fall down trying, is all the practices are dirt-simple.
"Write the name of a feature on an index card."
"What about all my requirements? They can't fit on a card!"
"That's okay. Write them wherever, as you learn them. Write the _name_ of a
feature on a card."
"Okay, but I'm gonna write all these requirements into a real requirements
document first. You'l see!"
When teams fear to let go, they leave in the comfort zone practices that
quietly cause waste.
> I had actually passed on a
> w of Weinberg training because because of the goofy Haiku on his
> site. Something about open your heart and hug your co-worker and share
> all your personal information...I took an XP class instead.
You took an XP class to avoid goofy haiku?! No wonder you are  !!
What did the class say about XP practices?
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| E. U. Reka 2005-07-28, 5:01 pm |
|
Phlip wrote:
> What did the class say about XP practices?
>
Not much that I can remember. I remember Uncle Bob and a colleague
choking on a PP demo. I remember Jeffries stepping in to try to save
it. I remember Beck asking some combative student for a card, and he
thought he mean't his business card. Shut him up. I remember Uncle
Bob oinking down a Dove Bar. I remember Ward hunching over a
powerpoint presentation, pushing his glasses up. In short, I don't
remember anything about it except for the personalities.
Crap, should've gone to PSL...the haiku occurs in any case.
|
|
|
|
|