>>using eXtreme programming tools like pair programming or code reviews to avoid having people slip into a frenzy of their individual domain / help keep obvious bugs out.
Wtf does this even mean? What are you talking about. If the bugs are obvious why do you need extreme programming to find them? What frenzy? Extreme programming is garbage.
From my experience, when a proper preparation is done and there are clear requirements, most of the "obvious" bugs do not even come into play. They do, when "hacking" a feature and / or working in "POC" mode, which, for me, is not software engineering.
For me it isn't either and I'm certainly not advocating for "hacking" features together. The obvious bugs I mentioned were not design bugs, but simple slips that creep in when you've already worked for a few hours and your attention starts lacking.
>If the bugs are obvious why do you need extreme programming to find them
Because sometimes you've already worked for a few hours and end up wasting time with stuff, which could have been spotted easily by help of a fellow developer.
>What frenzy?
The frenzy I was talking about was referring to working on a project for weeks on end and forgetting that of course you are now skilled in that domain you built yourself, but at some point other people will have to work with that system too and for them your answers might not be that obvious. Having other people check in regularly can prevent this.
Also, please don't 'wtf' me, you could have just as easily framed your question in a more humane way. I wasn't trying to defend extreme programming here, but merely stating that a focus on open communication will lead to more robust software. Don't abuse my comment for furthering your personal hate against some software development methodology.
Wtf does this even mean? What are you talking about. If the bugs are obvious why do you need extreme programming to find them? What frenzy? Extreme programming is garbage.