|
_Maxxx_ wrote: Just because you are a misanthropic sunshine doesn't invalidate a technique -
much in the same way as techniques of wall plastering are well known but i am
crap at them - doesn't mean they're bad techniques!
I'm pretty easy going but we just ended up winding each other up. Happens. Pair programming is not natural or normal. I am quite happy for someone to review my code and I'm more than happy to cooperate with other people.
_Maxxx_ wrote: it's not true about requiring one dominant and one submissive - it actually
works very well with two similarly talented devs as long as they can work as a
team.
I don't believe that for a moment. If you put two people together for any period of time they will end up arguing. If they don't then one is dominant over the other.
_Maxxx_ wrote: If there were that many things you disagreed on then something's up irrespective
of pair programming.
It wasn't about the code it was about each other.
_Maxxx_ wrote: So all you are doing is sweeping it under the carpet rather than bringing it out
in the open and dealing with it.
No: I'm saying pair programming is not a natural way to work and I've never seen it being any more productive than when 2 people work alone but talk.
Still, you're entitled to your opinion even if it's wrong. 
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
"not natural"?
Yeah - I Remember a David Attenborough tv show where they looked at the evolution of programming in the Serenghetti and how it originated deep in the dark nights of the winter, when lone pro magnon makes snuck off into the desert with their computers (they on,ybhad 2k in those days, experts think) to program games like Hunt The Sabre Tooth Wumpus
|
|
|
|
|
Now you're just being a sunshine.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Nah - I've always been one of them ... But I can see why you didn't get on well with your pair programming partner!
|
|
|
|
|
_Maxxx_ wrote: But I can see why you didn't get on well with your pair programming partner!
You sound just like him.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Me too (pair programming).
It was my "left brain" and my "right brain" ...
|
|
|
|
|
Marc Clifton wrote: Would you read (YA) book on this topic? What would it take to get you to read such a book?
By whom? I have reviewed some books, and this question is part of the first review
Depends on the writing on the back, that's the first thing to be scanned; I'm using the old waterfall, in short and long periods, with and without XP-minded management. The book needed to brag on the back on a benefit over my old ways, and have a decent chapter explaining how and why.
As Garfield would ask, "what's in it for me?"
|
|
|
|
|
Marc Clifton wrote: I don't think a lot of people actually think that XP works,
For starter I think the word "Extreme" is an incredible exaggeration. We make software, how *extreme* can software be in the first place? Software Dev is cool, what we make is cool and I think our occupation requires much higher level of IQ, in comparison to "the mass", or "The Civilian". But it's not *Extreme* and it's not *Extremely Cool*. Most software developers aren't "Great Lookers", we don't do a lot of the cool things that Bond would do. Women don't generally find Software Developers sexy. So sorry I really don't see how "Extreme" we can be.
dev
|
|
|
|
|
Marc Clifton wrote: Would you read (YA) book on this topic?
First thing coming to my mind is simply: no
Marc Clifton wrote: What would it take to get you to read such a book?
2 things might influence my first thought:
1. someone pays me to read the book (which will hardly happen I guess)
2. You are the author 
|
|
|
|
|
I read extreme programming explained back in the day and it inspired me to adopt some of the practices. Identifying someone that can make decisions and working closely with them being one of the main ones, as well as automated testing. I've never even heard of anyplace that went full in on Extreme monogramming though.
Honestly as far as another book on it goes, it would have to be better than Kent Beck's extreme programming explained or offer something really unique for me to even be interested, and that's a pretty high bar.
|
|
|
|
|
I would be interested in reading it.
|
|
|
|
|
A book? How quaint! How 17th Century.
In computing, the standard rule of thumb is that if the ink is dry, the ideas are obsolete. 
|
|
|
|
|
"XP" or Extreme Programming is a completely failed paradigm.
It was developed and promoted out of the Chrysler C3-Payroll development project. The project took approximately 5 years to fail. In the 4th year, the developers who had come up with this nonsense came to believe that they had found a new "magic bullet" for rapid development processes. They went out and promoted their new paradigm quite heavily and by doing so reached the mainstream development community in which it became highly popularized.
However, in the 5th year of the project all of the short-comings of the paradigm reared their ugly heads and subsequently caused the entire project to fail. Unfortunately, no one ever really heard about the failure so developers went on believing that XP actually worked.
As a software engineer I can tell you that there is absolutely no substitute for the logic of the traditional "Waterfall" approach. You may modify it, adjust it to your needs but in the end planning, design implementation, and testing are the four pillars of quality development.
You can't avoid them or short-change them with the idea that you are developing a new way of doing things...
Steve Naidamast
Black Falcon Software, Inc.
blackfalconsoftware@ix.netcom.com
|
|
|
|
|
Personally, I don't think it works. It seems to me that you end up with the lowest common denominator: since both programmers have to understand all of what's going on, the level you get corresponds to that of the less able programmer. I imagine that if you get a couple of not-very-talented programmers, they can kind of push each other along... but I dread to think of the clusterfuck they'd create.
Having said that, I've done it once - kind of by mistake - I ended up working on something with another very talented programmer - both of us were well past the point at which programmers actually think about such things as DRY and REST and other such mental crutches - and in that case, it did become like sharing a single mind: we could complete each others' sentences in code, as it were... but that's highly unusual: you have to start with a couple of programmers whose code looks like liquid, who can program at the speed that they think, and who never have to stop and think about what they're doing.
|
|
|
|
|
If the lowest common denominator means that you get code that both programmers easily understand, then isn't that a good thing? Isn't it more,likely that the code will be easily maintained in the future because any programmer is likely to be able to understand it?
Surely better than a single programmer developing 'clever' code that takes anyone else ages to decipher?
ALso, the assumption is that you don't employ crap developers on any team. If they are still learning, that's one thing, but if they are just crap, then pair programming and code reviews should weed them out pretty quickly
|
|
|
|
|
Well... theoretically... assuming that anyone who looks at what they do understands it -- it works OK in large organizations, but in many cases, especially in smaller startups, the pair of them may well be the only programmers in the organization - don't laugh: this happens far more often than you think...
Properly "clever" code is instantly understandable: it should be elegant and light with an obvious purpose. Tricky, write-only code isn't necessarily clever code...
[crap developers]: Have you tried employing any programmers recently? I have - it's a depressing exercise... it seems that a few years ago, a huge number of students emerged from college holding shiny new computer science degrees... and nothing else - ability, knowledge or talent, for example. There's just... too many of them!!
|
|
|
|
|
Yeah - I agree that small orgs have their own issues;
And what you say re the code is also true - and is what I was trying to say - but the measure of codes understand ability is the developers ability to understand it - which means catering to the LCD.
And yes, I have been gobsmacked by some developers - and not only new grads - also some o,der des who just can't or won't move with the times.
|
|
|
|
|
Exactly so...
We've been hiring recently - so far without success. I wrote a little test for the candidates: just three questions, each of which requires a little bit of lateral thinking.
The first was an SQL question: a table containing people, a table containing sports (each of which was basically an identity column and a text field), and a link table between them for a many-to-many join. The question said, "Write a query to return the names of the people who play *every* sport." Nobody got this right, although one guy almost worked out the idea of it.
The second question said, "Write an algorithm to produce a 20-element array with the numbers 1 to 20 in random order in it. Assume you already have a function to create a random number." Nobody could do that, either. One guy said, "I can't do this. It's not a business function." The only guy who even made a basic attempt at it wrote one of those things where you think up a random number for each array element and then check to see if you've used it before, and keep thinking up more random numbers until you're done. Horrible.
The third question was:
int a=543;
int b=624;
a^=b; b^=a; a^=b; // or in C, a^=b^=a^=b -- which doesn't work in C# for some reason.
What are the values of a and b when the code has run?
Strangely, the guy who complained about the business function knew the answer immediately (that it swaps the values) -- but he was old - binary XORs were obvious to him, even though nothing else was.
To take the pressure off a bit, I told the candidates that a right answer and perfect syntax weren't the point - that the test was for me to be able to evaluate how they think... apparently, none of them could. The closest answer to question 2 was from a guy who sort of got the point, but was using things like SortedList and inbuilt Sort functions to do it -- I asked him if he could do it using a simple array and actual code, and he couldn't. Amazing.
Oh, well - it looks as though my test was pretty good!
|
|
|
|
|
I've said it before, I think tests like this are generally a waste of everyone's time.
The SQL one amazes me nobody got it - I'd put it in the trivial SQL pile.
The third question I wouldn't know the answer to - I have no idea what the little hat symbol is used for in this context - but i am a good developer -so your test fails.
Second question I can imagine people coming up with all sorts of answers - but what's the point? And then one comes up with an answer and you change the goalposts? Why couldn't he use a sort function etc.?
I prefer to have a conversation with interviewees - talk about what they have done, what they want to do, have them talk through some stuff.
Looking at their resumes i make a call on how competent they should be - I try to give them a look at the code base they'd be working on, introduce them to the developers they'd be working with, and let them ask me questions.
I make it exceedingly cleat that I will sack them if they're crap at what they claim to be good at on their resume.
|
|
|
|
|
Actually, I didn't change the goalposts -- I told them before that they had to write an algorithm, not use library functions to do it. The SQL one is harder than it looks -- it's certainly not just a bunch of joins. Once I gave that question to a guy who made $150,000 a year back in the '90s doing SQL, and he said it couldn't be done. I didn't hire him.
The point of each question was to see if they could think -- I didn't want the guy to use a library function because if he's a programmer he should be able to program, not just use other people's code. For the sake of an interview question, I want something he could write in two minutes -- the point is to find out whether he tries to fill the array one number at a time, looking over and over again for distinct numbers (inefficient and stupid) or whether he fills the array with the numbers 1 to 20 in sequence and then swaps each element with a random one (efficient).
In the third question, ^= means XOR = (which I explain in the question) -- I want to see whether these people understand anything at a level lower than the user interface they're designing. It's not possible to describe the amount of value that an understanding of machine code adds. Apparently, the only one who did was incapable of doing anything about it.
I also did have a conversation with them first -- of course that's important. But at some stage, I want to know how their brains really work.
|
|
|
|
|
Marc Clifton wrote:
Would you read (YA) book on this topic? What would it take to get you to read such a book?
--------------------------------------------------------------------------------------
With the number of books already on the market on the Software Development and XP, I couldn't imagine wanting another, unless...
Unless, that book took on a code-and-architecture implementation driven approach using an actually real world project, or better yet, series of real world projects from different industry domains and technologies, to explain each step of the Software Development process. The idea here could be (should you consider this) show just how extreme programming can be implemented in a complete traceable Software Development Life Cycle (SDLC for short) - if, indeed, this is possible.
The reason I say this is because my experience of XP leads me to see the process as strictly a creative process that can be used within a SDLC framework. This notion may sound strange but the reality is that the current (and even the tradition) SDLC frameworks have already clearly shown their strengths to account for project management for managing the Software Development effort. And, I believe, due to a number of problems including the lack of software development standards, that XP is now showing a strong means to ensure the software process gets done while allowing the developer(s) an excellent piece of mind to exercise their creativity as they are applying their skills, learning from each other, learning new technologies, and capturing a happier customer in the process.
So while the current SDLC (or perhaps, someone can introduce a modified version of XP to include a strong project management framework) can be used to manage the project, then the XP lead implementation for developers would serve as the highly aggressive approach to product delivery and developer retention. Once we have achieve this combination, I believe (that's just me) that XP will be adopted faster than I am taking to writing this message!
Of course, the title of the book can reflect on this stance and as a final point - we love stories (haven't met anyone who doesn't) and, we in the developer community, especially, crave for those stories of people (developers' experiences) at work actually doing the stuff - making the book in this fashion can make it irresistible. (Heck, I am still craving for more literature like the book called "Extreme Programming Adventures in C Sharp")
But, I believe the point is that extreme programming on its own still has to prove itself TO BE on its OWN, which I'm sure most folks will agree with me. So, if you can write something (perhaps like what I've just mentioned or better) then XP will finally have its place (and developers WORLDWIDE will be thanking you (or whoever) for their enjoyment AND piece of mind).
-----------------------------
Jose Montero
MONTEC Computer Software & Training Services
mgr@montecsonline.com
-- modified 9-Nov-12 16:41pm.
|
|
|
|
|
Yes!
You could be article / page / book# 21,600,001!
(After the other 21,600,000 Google results).
Seriously, the hardest part would be a catchy title that could send you to the top (SEO-wise). Perhaps...
"Extreme Programming in your Pajamas"! (only 512,000 results !?)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
