Maybe it's hard because there's a better way to do it - i.e., develop requirements incrementally.
> the burden is not upon me to prove the negative
Right, but you asserted that Shlaer/Mellor provided a more "rational" approach without supplying any details of how.
> the more variable/complex a system, > the more error prone.
Sure. But how does that relate to gathering tons o' up front requirements? And does doing big design up front help us understand a system better than if we learn and adapt as we go along?
> you seem to equate a "changing requirement" > to a dynamic system component.
Nah, I'm with ya there. Pluggable this, dynamic that, scripted business rules, etc.
> they can never endevour to > document/specify their process.
Ah, but XP doesn't assert that they can never specify their process - just that their process can be better specified by running code and unit tests than by a large set of [insert color here] binders. Filled with UML diagrams. Billed at $200/hour. Not that I don't like money.
> Your turn to provide the evidence
Here you go. "So XP uses a process of continuous design improvement...".
> It's noisy beacuse you have to talk > all the time to the other person
Hm. Yup, pair programming definitely implies a lot of interaction with another person.
> all in a reduced space
This seems to be the problem.
> all talking about their particular task > at the same time
I think this ends up being a bit of a good thing - if you hear me talking about the Frob and how it doesn't have a getFiddle(), it's easy for you to pop up and say "I just added one!" or whatever. Improved communication... good stuff.
Yeah, I think I'm E[something]. Maybe ESTP. I wonder if there's a study out there on that. I Googled on "programmer MBTI chart" but came up dry.
I agree, it could make a difference... on the other hand, it might benefit both an introvert an extrovert programmer to sit down together and try to get something working. I don't know... I guess I just find that if I can explain something to someone I understand it a lot better. And the other person usually makes some insightful connection that I've missed. That's part of why I like open source programming... just seeing what other folks chip in with is nifty.
> Loss of productivity as I spend 10 minutes > on something that takes 1 to code.
Bah! I doubt it'd be that long. And even if it was, there'd be two people who had looked at it and understand it. And it'd probably be better code. No mallocs without frees. No ternary expressions. All that.
> these breaks take you out of the zone
Possibly, but I find it's a lot easier to get back in the zone if I'm working with someone. Otherwise I'm liable to extend that break for a lot more than 10 minutes. Or start off on some adventure of Factory classes and other such stuff that I end up deleting an hour later.
> I do code all day long
Me too, mostly Java and Ruby, and some C. But not in pairs. Only occasionally.
> I think I'd strangle anyone I was with > for that long daily, if I didn't drive > him to strangle me first!
Nice:-) Hey, we can pitch pair programming to manager types as a headcount reducer!
That's not pair programming, though. If you're pair programming and you're bored, say so and drive for a bit.
> Having someone standing staring at my work
Hopefully they'd be doing more than just staring... hopefully you and the other person would be discussing the code.
> when I can take micro breaks
Yup, ain't much time for Slashdot when you're pair programming.
> music
Unless you turn it down to be somewhat quiet.
> I will be spending large amounts of time > discussing what Im doing, or clarifying > suggestions
And what would be the result of that? Maybe some good stuff - i.e., improving the communications skills, getting better at teaching, etc? No harm done there.
> I'm a private person
Yeah, but the code is public - at least within your project. You don't have to talk about your inner feelings, just discuss method naming and such. In other words, be business-like.
> every time I need to go to the washroom
You: "I gotta take a break". Other person: "See ya in 10 minutes".
No problem.
> pair programming does not work for me
It does for me - the interchange of ideas, the focus, benefitting from the other person's ideas and such - it's good stuff.
> I'd change careers rather than put up with it.
Think some more about why you hate it so much. Maybe there's something to it:-)
> anyone irl who has ever enjoyed > pair programming
Chalk me up as one who does.
On the other hand, I don't pair program all day long - just in little segments of time. So hey, what do I know.
But rejecting XP and then saying "XP doesn't work"... how does that show that XP is flawed? Or maybe I'm misunderstanding. But your next point is far more interesting....
> as I'd hand in my resignation effective > immediately if asked to pair program
Why? What if you were pair programming with, say, Don Knuth? Or John Carmack?
> detailed requirement specifications are > difficult to arrive at largely due to > their importance
Hm. So they are important because they're hard to get? By that argument, wouldn't pink elephants be even more important to the project?
> for example Schaler-Mellor, present a far > more rational mechanism
I accept that this is your opinion, but it'd be more interesting if you were able to support it.
> are in fact typically comprised of over 90% > static structure, with a very small > amount of true variability.
That begs the question of how we discern those requirements, and how we (and our code) react to them when they change.
> not the core problem
What do you regard as the core problem?
> Although true genius is not necessary to > conduct solid analysis and design, > properly schooled education, and > patiently earned experience are.
How useful is that upfront "solid analysis and design" when faced with changing requirements and implementation details? Does it end up sitting on the shelf in large white binders? If so, was it worth the cost?
> the pervasive lack of solid talent in the > areas of system architecture, analysis, > design and engineering
These skills are important - so important, in fact, that every developer should continually develop and refine them. Which is what XP encourages. Design, architecture, analysis - all of these are continually examined on an XP project.
Hm. Why does the fact that someone doesn't like XP imply that the problem is in XP? I don't like hockey, but that doesn't imply that something's wrong with hockey.
> For those teams it fails for, the fault is > in XP.
Well.... if a team says "we're doing XP" and then doesn't follow the XP practices... I don't think that that can be chalked up as an XP failure.
> the best way to deliver software effectively > is to understand the problem domain
That's part of the process, yup. And there's a lot of other stuff, too.
> You don't need requirements before you > start coding
What about the planning game? What about user stories? Read this for better information on XP requirements gathering.
XP has the concept of figuring out what customer want... but XP doesn't demand that you and the customer pretend that every detail of the system is in a bunch of white binders filled with stuff like "the system shall...". Instead, you and the customer work together to develop a system that meets the customer's ever-changing requirements.
> if you aren't you need more process to > make sure you don't FUBAR things
That's the beauty of XP - it assumes that we aren't geniuses and thus we use unit tests, refactoring, pair programming to keep the code under control.
> XP like any software process allows you take > and use only those features that work with > your project
Sure, you can do whatever you want. But XP without pair programming isn't XP, it's.... something else. "Pretty Adventuresome Programming", maybe.
Some folks don't like XP because it's hard - it's hard to write unit tests, and it's hard to pair program and share knowledge and so forth. That's fine... but if you're rejecting XP because you don't like doing those things, don't blame XP.
> what happens to a loaded server with > MaxClients set too high
Right, it starts swapping since more child processes are forked than can fit into memory. As other posters have suggested, Apache's MaxClients needs to be aligned with MySQL's max_connections configuration.
Warning: Too many connections in/var/www/html/pnadodb/drivers/adodb-mysql.inc.php on line 121
Warning: MySQL Connection Failed: Too many connections in/var/www/html/pnadodb/drivers/adodb-mysql.inc.php on line 121 mysql://postnuke_game:@localhost.localdomain/ gamerswithjobs_com_-_main failed to connectToo many connections
> Simply because the compiler checks a lot > of structural integrity BEFORE the damn > thing runs highlighting load of errors > right there.
That's what your unit tests are for - they ensure that the correct types are being passed around, and, more importantly, the tests ensure that you're doing the right thing _with_ those types.
> type system is only in the way and is not > really needed when the program is debugged
Exactly. And your unit tests make sure your system stays debugged. And what better way to make a system maintainable than a solid suite of tests that you can run after every change?
RedHat's KickStart utility does the same thing; we've got about 170 rack-mounted machines that can be cleanly installed from a KickStart file and RPMs mounted on an NFS share. Takes about 5 minutes (on a 100MB switched LAN) if you're only doing one machine.
....since we're all suggesting LDAP implementations in our favorite languages. Get it here.
Note that it aims to be RFC 1823 compliant, so it'll work with OpenLDAP. If you pick an LDAP server that uses proprietary extensions, of course, you'll have to do some hacking...
Outstanding. Instantiating a String to wrap an immutable String object. I love it.
PMD's strings ruleset would catch this problem... but it sounds like that code has so many problems that you'd spend lots of timing hunting this kind of thing down. Blah.
> do a max(column)+1 query before you > open it up to changes
Yup, right, that makes sense. Seems like the thing to do would be to have a script to do that for every table prepared in advance. That way when the master failed one wouldn't be caught short.
> trying to replicate the sequence table > onto the slave
Hm, yup, maybe, and then just add 1000 or some other safe interval to the sequence to catch any extra txns.
So if your master fails, presumably you have to recreate the sequences starting at a number high enough to avoid conflicting numbers before switching over to a slave. Seems like this could be a problem.
Nonetheless, Postgres is cruising away on RubyForge; 300,000 records and counting...
> if I have 300K lines of code (it's Java), > there's probably something wrong
Sorry, didn't mean to imply that. What I meant was that 300K LOC is such a large amount of code that probably some duplication will have crept in there despite your best efforts.
I've worked on a system that had about 450K LOC and there was a ton of unused code/duplicated code in there - mostly because folks were afraid to clean it up due to a lack of unit tests.
> I don't think 300 classes is a lot
I certainly agree.
> so we're doing a good bit of XP-ish > stuff already.
Cool.
> Sorry! Venting!
Not at all... and again, I feel tools like PMD and CPD are useful for almost any size program - but most useful for very large ones where it's quite difficult to keep an eye on all the code.
Slashdot Mirror
> because it is hard, it is not without value
Maybe it's hard because there's a better way to do it - i.e., develop requirements incrementally.
> the burden is not upon me to prove the negative
Right, but you asserted that Shlaer/Mellor provided a more "rational" approach without supplying any details of how.
> the more variable/complex a system,
> the more error prone.
Sure. But how does that relate to gathering tons o' up front requirements? And does doing big design up front help us understand a system better than if we learn and adapt as we go along?
> you seem to equate a "changing requirement"
> to a dynamic system component.
Nah, I'm with ya there. Pluggable this, dynamic that, scripted business rules, etc.
> they can never endevour to
> document/specify their process.
Ah, but XP doesn't assert that they can never specify their process - just that their process can be better specified by running code and unit tests than by a large set of [insert color here] binders. Filled with UML diagrams. Billed at $200/hour. Not that I don't like money.
> Your turn to provide the evidence
Here you go. "So XP uses a process of continuous design improvement...".
> XP will fade way, and actually quite soon
Could be! As you say, time will tell.
> It's noisy beacuse you have to talk
> all the time to the other person
Hm. Yup, pair programming definitely implies a lot of interaction with another
person.
> all in a reduced space
This seems to be the problem.
> all talking about their particular task
> at the same time
I think this ends up being a bit of a good thing - if you hear me talking about
the Frob and how it doesn't have a getFiddle(), it's easy for you to pop up and
say "I just added one!" or whatever. Improved communication... good stuff.
Yeah, I think I'm E[something]. Maybe ESTP. I wonder if there's a study out there on that. I Googled on "programmer MBTI chart" but came up dry.
I agree, it could make a difference... on the other hand, it might benefit both an introvert an extrovert programmer to sit down together and try to get something working. I don't know... I guess I just find that if I can explain something to someone I understand it a lot better. And the other person usually makes some insightful connection that I've missed. That's part of why I like open source programming... just seeing what other folks chip in with is nifty.
> Loss of productivity as I spend 10 minutes
:-) Hey, we can pitch pair programming to manager types as a headcount reducer!
> on something that takes 1 to code.
Bah! I doubt it'd be that long. And even if it was, there'd be two people who had looked at it and understand it. And it'd probably be better code. No mallocs without frees. No ternary expressions. All that.
> these breaks take you out of the zone
Possibly, but I find it's a lot easier to get back in the zone if I'm working with someone. Otherwise I'm liable to extend that break for a lot more than 10 minutes. Or start off on some adventure of Factory classes and other such stuff that I end up deleting an hour later.
> I do code all day long
Me too, mostly Java and Ruby, and some C. But not in pairs. Only occasionally.
> I think I'd strangle anyone I was with
> for that long daily, if I didn't drive
> him to strangle me first!
Nice
> I've watched people code before
:-)
That's not pair programming, though. If you're pair programming and you're bored, say so and drive for a bit.
> Having someone standing staring at my work
Hopefully they'd be doing more than just staring... hopefully you and the other person would be discussing the code.
> when I can take micro breaks
Yup, ain't much time for Slashdot when you're pair programming.
> music
Unless you turn it down to be somewhat quiet.
> I will be spending large amounts of time
> discussing what Im doing, or clarifying
> suggestions
And what would be the result of that? Maybe some good stuff - i.e., improving the communications skills, getting better at teaching, etc? No harm done there.
> I'm a private person
Yeah, but the code is public - at least within your project. You don't have to talk about your inner feelings, just discuss method naming and such. In other words, be business-like.
> every time I need to go to the washroom
You: "I gotta take a break".
Other person: "See ya in 10 minutes".
No problem.
> pair programming does not work for me
It does for me - the interchange of ideas, the focus, benefitting from the other person's ideas and such - it's good stuff.
> I'd change careers rather than put up with it.
Think some more about why you hate it so much. Maybe there's something to it
> anyone irl who has ever enjoyed
> pair programming
Chalk me up as one who does.
On the other hand, I don't pair program all day long - just in little segments of time. So hey, what do I know.
> The fact is that XP does not work everywhere
But rejecting XP and then saying "XP doesn't work"... how does that show that XP is flawed? Or maybe I'm misunderstanding. But your next point is far more interesting....
> as I'd hand in my resignation effective
> immediately if asked to pair program
Why? What if you were pair programming with, say, Don Knuth? Or John Carmack?
> detailed requirement specifications are
> difficult to arrive at largely due to
> their importance
Hm. So they are important because they're hard to get? By that argument, wouldn't pink elephants be even more important to the project?
> for example Schaler-Mellor, present a far
> more rational mechanism
I accept that this is your opinion, but it'd be more interesting if you were able to support it.
> are in fact typically comprised of over 90%
> static structure, with a very small
> amount of true variability.
That begs the question of how we discern those requirements, and how we (and our code) react to them when they change.
> not the core problem
What do you regard as the core problem?
> Although true genius is not necessary to
> conduct solid analysis and design,
> properly schooled education, and
> patiently earned experience are.
How useful is that upfront "solid analysis and design" when faced with changing requirements and implementation details? Does it end up sitting on the shelf in large white binders? If so, was it worth the cost?
> the pervasive lack of solid talent in the
> areas of system architecture, analysis,
> design and engineering
These skills are important - so important, in fact, that every developer should continually develop and refine them. Which is what XP encourages. Design, architecture, analysis - all of these are continually examined on an XP project.
> the entire XP cult
Tsk tsk!
> Just doing all of them just a little, bit
:-)
> will be a lot better than big-ball-of-mudd
+1, Insightful.
I find that my projects are a lot better when I write lots of unit tests for them... I can't do pair programming, but I do what I can.
> try to tell a govermant org that they don't
> have to write a big contract
Right on. Just sign the contract and then do as much XP as possible. They'll be happy with the product, and you'll be happy with the follow-on work
> The fault there is in XP
Hm. Why does the fact that someone doesn't like XP imply that the problem is in XP? I don't like hockey, but that doesn't imply that something's wrong with hockey.
> For those teams it fails for, the fault is
> in XP.
Well.... if a team says "we're doing XP" and then doesn't follow the XP practices... I don't think that that can be chalked up as an XP failure.
Yup, true, maybe "it takes self-discipline to pair program" would have been a better way to put it.
> the best way to deliver software effectively
> is to understand the problem domain
That's part of the process, yup. And there's a lot of other stuff, too.
> You don't need requirements before you
> start coding
What about the planning game? What about user stories? Read this for better information on XP requirements gathering.
XP has the concept of figuring out what customer want... but XP doesn't demand that you and the customer pretend that every detail of the system is in a bunch of white binders filled with stuff like "the system shall...". Instead, you and the customer work together to develop a system that meets the customer's ever-changing requirements.
> if you aren't you need more process to
> make sure you don't FUBAR things
That's the beauty of XP - it assumes that we aren't geniuses and thus we use unit tests, refactoring, pair programming to keep the code under control.
> Pair programming is uncomfortable on our
> reduced space.
Sounds like someone needs to provide your team with pair programming-friendly space. A wide desk is a start.
> And it's noisy.
What's noisy? The space you're in? The other people? The person you're pairing with?
> Are the inconveniences worth it?
Those inconveniences aren't intrinsic to pair programming. Don't give up yet...
> XP like any software process allows you take
> and use only those features that work with
> your project
Sure, you can do whatever you want. But XP without pair programming isn't XP, it's.... something else. "Pretty Adventuresome Programming", maybe.
Some folks don't like XP because it's hard - it's hard to write unit tests, and it's hard to pair program and share knowledge and so forth. That's fine... but if you're rejecting XP because you don't like doing those things, don't blame XP.
> what happens to a loaded server with
> MaxClients set too high
Right, it starts swapping since more child processes are forked than can fit into memory. As other posters have suggested, Apache's MaxClients needs to be aligned with MySQL's max_connections configuration.
....from the article:
> He's much too modest. Would Alexander Fleming
> have said, "It wasn't a memorable event," when
> he discovered penicillin?
Crikey.
> Simply because the compiler checks a lot
> of structural integrity BEFORE the damn
> thing runs highlighting load of errors
> right there.
That's what your unit tests are for - they ensure that the correct types are being passed around, and, more importantly, the tests ensure that you're doing the right thing _with_ those types.
> type system is only in the way and is not
> really needed when the program is debugged
Exactly. And your unit tests make sure your system stays debugged. And what better way to make a system maintainable than a solid suite of tests that you can run after every change?
> "boot net - install"
RedHat's KickStart utility does the same thing; we've got about 170 rack-mounted machines that can be cleanly installed from a KickStart file and RPMs mounted on an NFS share. Takes about 5 minutes (on a 100MB switched LAN) if you're only doing one machine.
Yup, but I'm working on a govt contract doing govt work.
> I work at a financial instiution
I work at a government institution.
> Our data processor will not support Linux
Ours will.
> Tech support of the industry specific
> software we run will not support Linux
Time are changin'; people are porting apps to Linux left and right. Witness the PeopleSoft Linux ports.
> It's time to get serious here.
I am.
> We're big boys
So are we.
> Microsoft is the way it has to be
No it doesn't.
....since we're all suggesting LDAP implementations in our favorite languages. Get it here.
Note that it aims to be RFC 1823 compliant, so it'll work with OpenLDAP. If you pick an LDAP server that uses proprietary extensions, of course, you'll have to do some hacking...
> new String(req.getParameter("ZIP"));
Outstanding. Instantiating a String to wrap an immutable String object. I love it.
PMD's strings ruleset would catch this problem... but it sounds like that code has so many problems that you'd spend lots of timing hunting this kind of thing down. Blah.
> do a max(column)+1 query before you
> open it up to changes
Yup, right, that makes sense. Seems like the thing to do would be to have a script to do that for every table prepared in advance. That way when the master failed one wouldn't be caught short.
> trying to replicate the sequence table
> onto the slave
Hm, yup, maybe, and then just add 1000 or some other safe interval to the sequence to catch any extra txns.
Another hard bit is that the Postgres replication doesn't support sequences - see the details in the aptly named "Things to Remember" section of the installation documentation.
So if your master fails, presumably you have to recreate the sequences starting at a number high enough to avoid conflicting numbers before switching over to a slave. Seems like this could be a problem.
Nonetheless, Postgres is cruising away on RubyForge; 300,000 records and counting...
> if I have 300K lines of code (it's Java),
> there's probably something wrong
Sorry, didn't mean to imply that. What I meant was that 300K LOC is such a large amount of code that probably some duplication will have crept in there despite your best efforts.
I've worked on a system that had about 450K LOC and there was a ton of unused code/duplicated code in there - mostly because folks were afraid to clean it up due to a lack of unit tests.
> I don't think 300 classes is a lot
I certainly agree.
> so we're doing a good bit of XP-ish
> stuff already.
Cool.
> Sorry! Venting!
Not at all... and again, I feel tools like PMD and CPD are useful for almost any size program - but most useful for very large ones where it's quite difficult to keep an eye on all the code.