Xp Is For Babies

This sounds a bit like how babies acquire language, as described in TheLanguageInstinct. Babies are very good at guessing. A good designer will be good at guessing the designs of strange systems. In a sense, the baby is born knowing quite a lot about language and merely needs to fine-tune this knowledge by listening to its parents. -- DaveHarris

Are developers like babies when we start an XP project?

This reminds me of how I feel about the evolution of my own writing skills. Several years ago I started reading. At one point, this inspired me to write. At first, I emulated what I saw around me. Then I started to rebel and tried experimenting -- call it 'adolescent writing' where I wrote stupid and foolish things that seemed cool at the time. Eventually, I reached a point where I became secure with my own style of expression.

I have seen a similar pattern with other related skills where I build things. Perhaps project teams -- specifically of the XP kind -- experience the same kind of maturity.

--PhilipEskelin

My practical and theoretical research of babies (I live with two and read a lot about what we and they are supposed to be doing) leads me to believe that babies spend tremendous amounts of time doing little more than exploring. Through this exploration, they acquire knowledge of their environment, and how they can affect and be affected by it. Eventually children begin to be able to reason about their environment, and make decisions about how to interact with their environment, ultimately (hopefully) as adults making these decisions according to some acquired understanding of rightness.

Sounds similar to what I have heard and read Ward, Kent, Ron, and others saying about design and XP. A key strategy is exploring problems by writing code that attempts to solve them, and applying the knowledge gained to determining the right way to solve them.

I've read in other contexts that, for many situations, a child's approach is appropriate. The speaker is usually meaning something along the lines of: see what is really there, solve only the problem that really needs to be solved in a way that is really appropriate for the current situation. Also covered in the ExtremeWay, I think.

--BillJamison

That's pretty much the exact opposite of my point. I only mention this in case you hadn't noticed :-) -- DaveHarris

I'm afraid I have to ask for clarification, there, Dave. I didn't and don't notice the opposites you are referring to. Thanks -- AlistairCockburn

You have to come to XP as a beginner. There is so much about it that is counter-dogma that you are unlikely to "get it" right away. I am dealing with a developer right now who can't get over the idea that team achievement is more important than individual achievement- if he can make everybody twice as good, he doesn't have to write a line of code. Instead, he is shooting off in all directions and making everybody 20% as good as they could be.

Watching my kids learn German (and myself mostly not learn it), I have learned that to learn to speak you have to speak. The adults (and even more the kids) you talk to will repeat things to you correctly if you get them a little wrong. But you have to try, and try good enough that the other person can sort of understand. Then the learning can start.

I think the analogy to XP is very strong- you want to know how to build a system? Build it! It will be wrong. Fix it. The system knows how every bit of functionality currently in it wants to be structured. Listen. If you want to know how to structure the system for new functionality, add the functionality and listen again. Drive this process down to the smallest grain size you are comfortable with. Then you will have a low risk, high productivity development process. Just as if I just tried to talk, and didn't get all caught up in who I am supposed to be, I would be speaking fluent German by now.

--KentBeck

The "Key Strategy" that BillJamison mentions is interesting in its own right. We just had a discussion on this in the TriPLuG last night. Let's investigate that one in LearningByTryingSolutions. --KyleBrown

That's pretty much the exact opposite of my point. I only mention this in case you hadn't noticed :-)

Guessing isn't related to exploring? People don't get good at guessing through experience (lots of exploration)? We don't increase our chances of making better guesses when we narrow the issue we are guessing about? The answers to these questions would seem to me to be 'yes'. What am I missing?

I must be dense...I hadn't noticed. Maybe if you restate your point I will understand. Does Kent's point have anything to do with mine? "Now I'm so confused I don't know who I am or what my name is..."

--BillJamison

StevenPinker argues that babies are not given enough data to learn language from; language is chronically under-determined. Babies do so well because all languages have a common deep structure, and this structure does not have to be learnt because it is already hardwired into the baby's brain. They are not avoiding prior assumptions, they are making loads of them. This is the opposite of what is usually meant by "child-like".

Patterns help good programmers learn new systems, because they are a prior knowledge similar to that of a baby's (albeit not hard-wired). Yes, they narrow the issues we have to guess about, in the same way that there are fewer grammatical English sentances than random strings (if that's the effect you had in mind).

Is this clearer? Have you read Pinker in TheLanguageInstinct? -- DaveHarris

Much clearer. And no, I have not read Pinker. It appears I should- I recall reading someone who argued (from what I recall and from what little you have said about what Pinker said) that this is not the case: languages do not share structure, people have superb symbol processing hardware. Now if that is 'deep structure', then what I read does agree. But, as I'm sure you can see, I just don't know enough about say much about it.

This is an awful lot of verbiage. I've been over it a couple times and cannot see right now where the dead weight is. Surely there is a much simpler way to say what I am trying to say. -bj

If I understand, babies are making assumptions about language based on the knowledge they have about how languages work (in this case hard-wired: not from experience). It seems to me that this is what Ron keeps saying Kent is so good at - making assumptions about programming based on how programs work (in this case not hard-wired: based on experience (right Kent?)). As I understand it, this is what Ward, Kent, Ron, and the others are saying we need to strive for, and why we should get to code as quickly as is reasonable - to feel the shape things want to be, and learn the shapes things can be. This 'feeling of the shape of things' is common to many disciplines and is something primarily gained through experience. It appears to me to have much to do with recognizing patterns, though (from my experience) the patterns come after the experience, not before.

I don't really see that patterns provide the same support as this 'common deep structure' in languages. It seems to me that there is some understanding that must come before patterns are useful. I have seen patterns give inexperienced programmers more problems than they solved. The programmers had problems making the link between the somewhat abstract pattern and the concrete problem, and came away more confused than they began. I have seen more lights come on when driving less experienced programmers through the pattern first (without explaining what we were doing in those terms), then showing how what we did is an application of the pattern, and why. Having the concrete experience helped them understand the generalization that was the pattern.

The other point I want to make is that "child-like", in my comments above, doesn't mean "without prior assumptions". It means without needless assumptions. It means looking at the problem I am solving as a new problem, and discovering the solution to it. Not assuming it is the same as some other, superficially similar problem, and solving that problem again. It also means not thinking so much about stuff that is not central - like Kent mentioned about his problems learning German.

--BillJamison

DaveHarris said: Babies are very good at guessing. A good designer will be good at guessing the designs of strange systems.

I think I know what he means by this:

Guessing in XP is bad. More precisely, guessing and not quickly checking your guess by writing some code is bad. Design guessing almost always violates YouArentGonnaNeedIt.

But babies are good at guessing. By analogy, a good designer will make good guesses about this system he's putting together.

Now for what I'd say:

Babies are lousy at guessing. One friend of mine guessed that an electrical extension cord would taste good. My cousin guessed that pulling on a coffee-pot cord would be a good idea. They're both lucky to be alive. Someone else I know guessed that the proper place to insert a shrimp was her nose, and that saying "meat in nose" over and over would adequately convey the source of the subsequent problem to her mother.

What babies are very good at, and sometimes overly enthusiastic about, is doing things based on their guesses, thereby getting valuable (if occasionally too-costly) feedback.

So I (unlike Dave) think babies are good at XP. If I could pass a methodology on to babies, though, I'd probably throw in a principle like DoTheSafestThingThatCouldPossiblyWork? (and possibly, MostThingsDontTasteGood?). --GeorgePaci

Babies are good at guessing language. They are not good at guessing about electricity. Language is instinctive for us in a way electricity isn't. -- DaveHarris

Anthropologists use the term neoteny, meaning the retention of juvenile characteristics into adulthood. Hypothesis: XP may be a sort of neoteny of software development process.

XP does seem to fall back on the instincts of the less experienced. Do things in pairs, bite off little pieces, keep formality at bay, etc. There seem to be two potential strengths to this. One: tap into the capabilities of the majority of the (young) workforce. Two: exploit fluidity when fluidity is a benefit, meaning throw out models that obstruct good work today even if they used to work yesterday.

Choosing to inject some juvenility into the mix is not the same as being a baby. (Neotenized species still have adults.) It involves choices a baby doesn't have. But the room for confusion seems large, and the mistaking of XP for hacking seems to be where that comes to a head.

-- WaldenMathews

Interesting thought! Here's a variation. Maybe XP exploits (long-established) human neoteny. That is, XP exploits curiosity and playfulness, which in humans are not limited to children. Many adults abandon these things, since it's hard to keep them while becoming responsible and dependable. But watch anyone who has brought his natural curiosity and playfulness to an adult level--such people are amazing to behold. XP seems to show software teams how to use childish curiosity and playfulness to become *more* responsible and dependable. --BenKovitz

Okay, I'm with you on that. And here's yet another variation. Maybe the playground for invention that computer software is has attracted a bunch of people who inherited a lion's share of neotenous behavior from their giddy ancestors, and XP is the re-emergence of adulthood over that behavior in an attempt to solidify it into a more responsible and dependable activity -- without losing the youthful zing.

-- WaldenMathews

 ne·ot·e·ny

(n-tn-) n. Retention of juvenile characteristics in the adults of a species, as among certain amphibians.

Of course XpIsForBabies, isn't the WindowsXp meadow wallpaper the TeleTubbies set??