From: Francis Cianfrocca Date: 2006-05-03T21:23:39+09:00 Subject: Re: Sharp knives and glue ------=_Part_4006_8996616.1146659015711 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I like pair programming a lot. But for every time I've seen it work, I've heard many more times that "it won't work for us." And you've already given some of the reasons. That tells me that pair programming alone is not the answer. (I won't get into all the rest of XP, which can disturb the manager= s of large enterprise projects as much as dynamic typing does.) Something about what you said struck me funny, though. If we're trying to limit the damage caused by less-experienced programmers (in one way or another), then shouldn't we rather be trying to reduce our need to deploy less-experienced programmers in the first place? As you said, not that many people have the temperament for pair-programming, so that becomes yet another quality constraint that we're placing on our people. I write a lot of C++ and a lot of Ruby. Whenever I go back to C++, I heave = a sigh of relief and think, "oh good, now I can stop worry about mispelling variable names and getting argument counts wrong, because the compiler will check all that for me, so I can go back to worrying about memory management!" I'm just as careful writing Ruby as C++, but I'm careful about different things. Programming well isn't very easy. Programming exceptionally well is... exceptional. So if our methodologies are constructed with an inherent dependence of a certain level of quality from our people, then we won't be successful at very many of our very large projects. And that indeed is what happens. Going to the opposite extreme and trying to attenuate the human factor altogether through automatic constraints doesn't really achieve scalability either. Or at least it does so by adding huge costs. It bothers me a lot that we keep trying to invent large-scale development methodologies to solve the problems that arise when a huge number of components have built-in visibility to a lot of other components. Above a certain problem size, you may as well try to boil the ocean, and many large projects I've seen look just like that. Java typifies this approach by making so much of the system statically checkable, and allowing so little to be dynamic. We know this approach works, because there is any number of large enterprise systems built in Java. But then you end up with exactly the kind of large system that everyone has and everyone hates: too brittle to adapt to changing requirements. "If it ain't broke don't fix it" turns into "let's define all new requirements as nice-to-haves, so we can keep saying that System X ain'= t broke." From this point of view, as I've said, Java isn't fundamentally better. It's only incrementally better. Is Ruby fundamentally better? I think it is, but we may have to invent a completely different large-system methodology to take advantage of it. And "completely different" isn't a concept that most IT managers understand. There will always be a thousand good-sounding reasons why "that'll never work here," the first and most important of which is "no one else does it that way." (And candidly, this attitude keeps a lot of people from making big mistakes and getting fired!) Another thing that troubles me is the convention that you have to pick a language before you start coding a large system. You'll hear people say "We're going to do our new account-allocation system in J2EE." I think that puts far too much pressure on the programming language, and I suspect the underlying motivation is to take pressure off a far more difficult problem, which is design. Whenever I see a one-off enterprise system with 1000 KLOCs and a hundred maintenance programmers, I think there is something very wron= g with this picture. Someone started coding too soon. Intuitively, wouldn't i= t better, cheaper and easier to have 5 or 10 systems with far better-defined and smaller requirements interacting through standard protocols? That way your choice of methodology doesn't constrain your choice of programming language, and vice versa. Something like this is exactly how the open-sourc= e world works, and it works incredibly well. Large-systems methodology has ye= t to incorporate these insights. And people seem to be talking about this les= s today than they were three years ago. On 5/3/06, Leslie Viljoen wrote: > > Thanks for the reply! > > On 5/3/06, Francis Cianfrocca wrote: > > > > > > Anyway I don't have the answers (yet) and there is a long way to go. Bu= t > I > > don't think Ruby should be "improved" to fit traditional large-system > > methodology. I think the reverse (somehow) is closer to true. > > > > Perhaps something as dynamic as Ruby requires a team methodology as > dynamic > as XP. I think pair programming is (at least partially) intended to limit > the damage > caused by not-so-experienced programmers. Then the remaining problem > would be trying to convince management that pair programming is actually > worth > it, and trying to convince programmers to put aside their egos to the > extent > where they all are willing to accept constant advice and input from a > partner. > > ------=_Part_4006_8996616.1146659015711--