Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Alan Kay was quoted several years ago to the effect that there had been only three new things in software in the preceding 20 years (effectively the lifespan of PCs). One of them was Spreadsheets.
Does anyone remember the other two?
Who is Alan Kay? (a few may ask.) His work at Xerox Parc arguably did more to shape our current software paradigm than any other influence.
I will try to remember what I said, but none of the answers so far are correct (every one of them was done in the 60s and 70s before the commercialization of PCs in the 80s).
However, we could start all over and try to think of new inventions in computing since the 1980s.
When ever I think about xerox parc I always remember this quote from triumph of the nerds by steve jobs:
They showed me, really, three things,
but I was so blinded by the first one
that I didn’t really ”see” the other
two. One of the things they showed me
was object-oriented programming. They
showed me that, but I didn’t even
“see” that. The other one they showed
me was really a networked computer
system. They had over 100 Alto
computers all networked, using e-mail,
etc., etc. I didn’t even “see” that. I
was so blinded by the first thing they
showed me, which was the graphical
user interface. I thought it was the
best thing I had ever seen in my life.
Now, remember it was very flawed. What
we saw was incomplete. They had done a
bunch of things wrong, but we didn’t
know that at the time. Still, though,
the germ of the idea was there, and
they had done it very well. And within
ten minutes it was obvious to me that
all computers would work like this,
someday.
No mention of spreadsheets, but how about this quote, from an interview with a 1991 issue of Byte Magazine:
"In 1968 I saw two or three things
that changed my whole notion of
computing. …Doug Englebart’s view
[was] that the mainframe was like a
railroad, owned by an institution that
decided what you could do and when you
could do it. Englebart was trying to
be like Henry Ford. A personal
computer as it was thought of in the
sixties was like an automobile. In
1968 I saw Symour Papert’s first work
with kids and LOGO, and I saw the
first really great
handwriting-character-recognition
system at Rand… And that had a huge
influence on me because it had an
intimate feel. When I combined that
with the idea that kids had to use it,
the concept of a computer became
something much more like a
supermedium. Something more like
superpaper."
Source
Perhaps this link leading to the paper
The Most Important Software Innovations written by David A. Wheeler
helps you remembering the two missing things.
P.S.: I personally would choose (1980 and later):
1982: computer virus
2004: MapReduce (In 2004, Google's Jeffrey Dean and Sanjay Ghemawat revealed MapReduce)
I am pretty sure C++ wasn't one of the two things.
See https://stackoverflow.com/questions/58640/great-programming-quotes#58810
Alan Kay invented Smalltalk. In so doing, he can be said to have invented object oriented programming, although there are important precursors to Smalltalk in that regard.
Simula, a language form the 1960s for writing simulations was one. another was Planner, a language invented by Carl Hewitt of MIT. Alan Kay specifically gives credit to Hewitt for influencing him while he was at Xerox PARC.
Mice and GUI's
Related
I've been trying to figure out what computer field I want to go into later on in life. College is just around the corner for me and I've considered looking into Computer Engineering, Software Engineering, etc.
Lately, I've been looking into computer security systems and exploitations of such (purely for educational purposes, on my own property). Unfortunately, it seems to me like 99% of the people out there have no idea what they're talking about. Oftentimes, it's just "run this" or "run that" or "you can find a program that will do all that for you" - no one knows how these programs work or what exactly they do.
I find no fun or interest in using something that someone else created simply to call myself a "hacker" as most people do. In fact, I'm not even interested in hacking systems as much as HOW they do it.
My question all comes down to this.
I want to learn the ins, outs, ups, and downs of computers - everything from abstract concepts such as the internet and data transferral, to hardware. I want to know how computers store data (how the bites are organized, etc.) and what processors, etc. actually do. What is WIFI, really? Do computers communicate with light (something I picked up from a magazine that I read on a plane).
I have multiple years of computer/programming experience, but so much of what I know about computers in general is very broad. Computers send packages of information back and forth between one another, each with a header and content. Computers are composed of multiple components, each with their own function (processor, video card, RAM, hard drive(s), etc.), which I have some basic understanding of already. etc. etc. etc.
There is just so much to a computer and I don't know where to start. I'm sure some of my college classes will clear things up for me, but I'm so curious that I want to start learning as much as I can now.
This question is probably all over the place, so please ask me to clarify when necessary. I'm a little jet lagged at the moment, but I tried to write my thoughts in the quickest, most coherent way possible (I could have completely failed in the process, though).
Thanks in advance for any advice!
Justian Meyer
Please, feel free to edit the tags for this question. The current ones are terrible.
EDIT:
All these comments are making me excited :). So much to learn, so much to explore :).
To help you choose which specialization to go into, I would very highly recommend computer engineering(Known as CMPE or CE in college course books). Your classes will take you to everything you just listed, and with electives you can delve deeper into whichever aspects you wish(such as security and networking).
In CMPE you will learn both software(C, C++, and some C#) and then hardware( maybe two electrical engineering classes). Once you get to assembly programming, you will start to learn how the two combine to make up everything else in any computer or embedded system. It will take you down to the bit level of memory, CPU, data buses, I/O, and so many other things. I am just starting to do Digital Design, and its ****ing glorious. From what you described, you will enjoy being a CMPE major greatly.
There's computer science majors and software engineers; there's electrical engineers; but there is no cell phone, GPS, or computer designed without computer engineers!
Structured Computer Organization, Tanenbaum
It is a great book and explains everything from a transistor to a Java virtual machine.
These two helped me understand how the OS and memory in general works.
I believe a lot of things are derived out of these 'simple mechanics.
1.Anatomy of a program in memory
2.Pushing the limits on Windows memory
Steve Gibson of security now has been doing a series of podcasts on computer basics.
http://www.grc.com/securitynow.htm Episode 233 "Let's Design a Computer (part 1)" up to the most recent one "What We'll Do for Speed".
Every other episode he does listener feedback and those are good to listen to too.
a few times (like right now) they interrupted the series if a important security news item comes up (like when that big SSL thing broke a few months ago)
Its a really good show and I recommend starting on 233 and working your way up, then starting over on episode 1. Has also done very good series on how a computer network works and how cryptography works. (Ep 203 will blow your mind when he talks about the Boyer & Moore
method of searching)
Since you are deciding where to go exactly, to be in software development or to become expert in hardware and networking, I would like to point out that in my opinion it is two different occupations and they require two different mindsets. Good hardware experts are usually not good programmers and good programmers almost always not experts in hardware and networking. So I would say don't try to embrace both, stick to one direction which is most suitable to your mindset. To pursue two rabbits would result in catching no one.
#Justian
I see, sorry I somewhat misunderstood you. Desire to understand intricacies of how code gets processed inside of hardware is a very natural one. When in college I was reading the book "How computer works" - it is fairly simple, even somewhat primitive book about general hardware functionality. But it can get you a broad look on the topic.
Another analogy came to mind. Say linguists research internal mechanics of language, but it is neuroscientists who research on how language signals get processed in brain. Two very different occupations. This is not to discourage you from learning hardware though, this is just to underline difference between two realms.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
The amount of available programming languages is both a bless and a curse, I think.
I know a lot of programming languages already, some at syntax-level only and some good enough to do actual coding (Python, C, C++, Haskell, Perl, BASH, PHP, and lots of others). I have been programming for almost as long as I've been intensivly using computers (6 years), in almost every paradigm (functional, imperative, object oriented), but I don't feel prepared for the software industry.
I've been writing a lot of bigger programs in a lot of different languages, mostly network based, including large multithreaded server/clients, and I still don't feel prepared!
Currently I'm obsessed with my "3-tier" plan, which includes a high level language like Haskell, an interpreted language like Python and a low level language like C, yet I don't feel good enough!
I know how to work in teams, and how to work along given guidelines, but I'm unsure.
Am I prepared?
Please, kind people of stackoverflow, help me out of this mess! :(
Thanks for all the answers, I wish I could chose more answers as THE answer :)
Sounds like you know an awful lot about programming, but you don't mention anything else. Being a software developer requires more than just programming as a technical skill. Brush up on topics such as source code control, unit testing/test-driven development, continuous integration, etc. Hopefully you'll land in a job where at least one of those is in use. Try and learn as many useful time-savers as you can with your tools; try to become as flexible and efficient with your IDE as possible.
Elsewhere, don't forget to develop the more personal skills; attitude and work ethic, and more related to your field, issues such as eliciting requirements, documenting issues and describing problems and solutions. Don't worry too much about these if you're going in afresh, because you're not expected to have a huge knowledge of them, but if you're at least aware of them and trying to improve, then you have a greater chance of doing so.
Try to appraise yourself of general software development issues that aren't directly coding, if you haven't already - general attitudes to security-oriented development (and testing), good design and similar best practices.
Don't sweat too much about being perfect right off the bat. If you've got no room for improvement, you aren't going to enjoy your career very long, and burning out as a programmer ain't much fun.
You know enough - there is a minimum threshold of knowledge required in the industry (which is above what some developers have), but it sounds like you are already there.
For anyone with the aptitude, new programming languages, techniques, etc, are easy to learn. A good company to work for will hire you based on your abilities, not knowledge (which can go stale very quickly).
If you want to stand out as a software developer, ensure you have rock solid communication skills for reports, e-mail, telephone, meetings, etc. That is a rarer gift in the software field, and although it is not necessary more valuable at the junior levels, it pays off in the long run.
The single most important thing I can think of to be successful in the industry is to be able to respond quickly and efficiently to change.
I recently took a programming test which I thought was a good and fair test. I passed it without a great deal of effort. I was told that 50% of the people (these are all people with programmer on the resume) don't even know where to start. Your earnestness and desire will most likely put you in the top third of most places to start with.
Knowning languages is not all you can do.
If you can, a placement/internship will do wonders. Anyone can program. Real world experience will teach you more than any tutorials, self learning or schooling will.
Naturally, gaining an internship requires some experience, so it's very much catch twenty two.
If going for an internship is not possible, get involved with an open source project. You'll find you'll learn loads by working with people smarter than you.
True knowledge exists in knowing that you know nothing.
Socrates some smart dude
I think this is pretty common among developers. Imo it´s a way better sign then if you would come to the conclusion that you were fully trained.
The only way to know for sure if you're prepared is to try. Sometimes being thrown in the deep end actually helps and you'll find you learn more in that first real world job than you did in all the books/etc that you read in the years before. Also, knowing multiple languages helps you understand underlying semantics of programming in general, but in a real job you'll likely be sticking to one or two languages day to day, so don't get hung up on knowing every language out there.
It's better to try & fail than to spend your life wondering if you're ready.
Go to dice or monster or whatever your favorite job site is and see what people are looking for. It's not Haskell, it's C++. Learn that well and you're ready to go. Once you're out in the real world, you'll learn quickly enough the things that are important. These are mostly the soft skills that school doesn't teach you. Things like how to get along with the clueless, how to present your ideas so they'll actually be considered, and how to see the forest even though you're stuck under a rock.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've come across an article that discusses the issue of "code admiration". Basically, the author talks about how developers should be more skeptic about code they write. How we may "admire" our code too much, attach our-self to it, making us more vulnerable to bugs and other mishaps that may be lying in front of us.
How do you feel about this issue? And do you have more tips on how to avoid/be more aware of this issue?
Some years ago, I was working with another on a small "hobby" project, and I realised that we had to re-assess things. We had written lots of code but it wasn't all good code.
We didn't really want to "throw away" all the work we had put in. But I realised something: what mattered most was the amount of work we would need to put in from now on.
We couldn't change the fact that we had already put so much work into the project, so the only way to minimise the total amount of work the project would need, would be to minimise the amount of work we hadn't done yet.
Since that day, I have stopped being attached to my code. If I'm confident that throwing it away and starting from scratch means less work than keeping it and adapting it to my needs, then I'll throw it away.
My high school art teacher used to encourage us to take what we considered to be our best drawings and tear them up; he called this "cleansing the soul". His reasoning was that, as artists, we were driven to create works of art, and any time we produced something that we liked and that gave us satisfaction, our motivation to continue creating would be lessened.
So I followed his advice and tore up my best stuff, and it worked. Instead of spending my time admiring my old work, I created new stuff and continually got better. I've tried to follow the same principle with my code, but it doesn't really work: my computer has a tough plastic shell that is nearly impossible to tear through.
I post a fragment from Jeff Atwood's blog, Sucking Less Every Year, and I agree 100%.
I've often thought that sucking less
every year is how humble programmers
improve. You should be unhappy with
code you wrote a year ago. If you
aren't, that means either A) you
haven't learned anything in a year, B)
your code can't be improved, or C) you
never revisit old code. All of these
are the kiss of death for software
developers.
We sure like to admire our nice code, but it's not always easy to know what to admire. Complicated and elaborate code is sometimes mistaken for admirable code, while elegance and simplicity should rather be what to strive for.
Two quotes come to mind:
"Debugging is twice as hard as writing
the code in the first place.
Therefore, if you write the code as
cleverly as possible, you are, by
definition, not smart enough to debug
it.”
-- Brian Kernighan
and
"Make everything as simple as
possible, but not simpler."
-- Albert Einstein
Jonathan Edwards wrote an impressively beautiful essay on this subject, prompted by the work on the O'Reilly book Beautiful Code. Here's the final paragraph, but the rest of the essay is also worth reading.
Another lesson I have learned is to distrust beauty. It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude. Love is blind, but computers aren’t. A long term relationship – maintaining a system for years – teaches one to appreciate more domestic virtues, such as straightforwardness and conventionality. Beauty is an idealistic fantasy: what really matters is the quality of the never ending conversation between programmer and code, as each learns from and adapts to the other. Beauty is not a sufficient basis for a happy marriage.
Other versions of this same wisdom exist in other fields. Samuel Johnson, about writing:
Read over your compositions, and wherever you meet with a passage which you think is particularly fine, strike it out.
William Faulkner's version of this was much more succinct: “Kill your darlings.”
My father-in-law works as a film editor, and he studiously avoids the set where the film is being shot. When he does have to visit, he shields his eyes as much as he can. This is because when he decides whether or not to include a scene in the final film, he doesn't want to be influenced by how much effort it took to shoot the scene. What matters is how well the scene works in the final film.
My essay, "My evolution as a programmer" (which I would link to if I weren't a new user), is largely about learning skepticism about the code I'd written: whether it works, whether it's useful, whether it's comprehensible (pair programming was a real wake-up call here). It's hard!
I never admire my code. I admire other peoples code that i "borrow" and try and emulate them or better them and i find that the more i know, especially about coding the more i find i don't to know. The only thing of value wold be for peer programmers to admire my code and borrow it.
I think he has a good point. It's frustrating to work with people that have too much of this, as it really hinders teamwork and getting to the best solution to the problem.
As I can be a bit delusional, I try to put practices in place that will keep me grounded in reality. For code,
unit tests: These keep me more focused on what the code is supposed to do, as opposed to any abstract "beauty".
shared code ownership: There are two camps here: give people more ownership of their code and hope pride takes over, or give them less and let peer pressure come into play. I believe that giving people more ownership can lead to this code admiration. We practice shared code ownership, so I am constantly forced to see someone rewrite my perfect code to make it better (in their mind). I quickly realized admiring it too much was a waste of time and emotionally difficult.
pair programming: working side-by-side with someone will keep you realistic.
other feedback: These are all feedback loops, but there are others. There's no better way to see if something works than by watching someone (try to) use it. Put your work in front of as many people as possible. Have code reviews. Read other people's code. Run static code analysis tools.
I'm with PurplePilot - I don't admire my own code, and as such I'm constantly searching for new, more efficient (hell, easier) ways of doing the same thing. I like the Effective c# book, picked up lots of useful code from there that I admire.
I would have no hesitation about throwing code away and starting again, but not necessarily from scratch, i.e. by writing some code for a specific scenario and then throwing it away, you'll probably have a better grasp of the scenario. In other words, it's a "wicked problem", or you've found another way that doesn't work a la Edison.
It begs a wider question: if code isn't thrown away, or at least revisited, is developing on libraries that are becoming stagnant a good thing?
There is nothing wrong with admiring your code ... this is part of the positive reinforcement process that will motivate you to write more and better code in the future.
However, misplaced or misused admiration can be a problem. If the code is really not good, or has bugs that haven't been exposed by unit or other testing, or needs refactoring/redesign/replacement then this misplaced admiratoin is a problem. And using admiration as an excuse to skip part of the process - such as code reviews, or not having a skeptical attitude towards code - is misuse of admiration.
Like anything else that is good, admiration of code can be misplaced or misused - it doesn't mean that it in itself is bad. That would be like saying "religion is a bad thing, because it causes conflicts and wars between people".
Two words: code review.
Gather two or more fellow developers and invite them to review/criticize/comment on your code. 'twill shed some (admittedly harsh) light on your code.
It's perhaps better to have a healthier perspective - we aren't rocket scientists, and we aren't curing cancer - it's just work.
(Yes, it's reasonable to be proud of an entire building you helped build if you're an architect, but do they really have a lot of their self-esteem wrapped up in an individual blueprint, or a closet on floor 3 they designed by themselves?).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
From Wikipedia:
The Last One was a unique software
program in 1981 which
took input from a user and generated a
program in BASIC which could then be
run. It is an example of a program
generator.
The software was not a programming
language, since unlike most
programming languages, programs were
generated by the user selecting
options from menus that would form the
basis of the generated code. This was
done in a logical sequence that would
eventually cause a program to be
generated in BASIC. At any time, the
user could elect to view a flow chart
showing the current progress of the
program's design. 2
But Wikipedia didn't say what became of this program. How popular/unpopular was it, and how many people use it? How and when did it meet its demise, or is it still available?
More information available here.
Here's the current story AFAICT: this article mentions that the consulting firm they formed way back then to put TLO into play was named DJ `AI' Systems and is now tloconsultants.com (tlo == The Last One). Cha-ching :-)
My guess (after a 2min site scan) is that they grew their business by continually expanding what appears to be business-oriented expert system "modules" that the generated code ran against (and also perhaps even assisted in or guided some of the code generation, most likely for the code that targeted its own routines) and then incorporate the knowledge of how to use the new modules back into TLO. Very impressive, especially for 1981 and with the engine that knew when it didn't know enough -- ScHrIaTp! I wish my manager had 1/10th that functionality.
And you gotta love that it took five minutes to generate 100 bug-free lines of BASIC code.
I'm curious as to whether they ever "closed the loop" (my term) because I didn't see it mentioned (as I didn't fully read it due to that dang corporate job and its fake-time-based insanity) as to whether they actually reached the point where its own representation was manipulated within it in order to generate the next version of TLO itself. The name "The Last One" suggests to me that David James fully understood the meaning of manifesting a piece of software capable of presenting its own representation to the user (== programmer) for modification with the end purpose being to generate its own subsequent version.
All such self-repping-and-editing programs (live processes are IMO far more difficult while being also tantalizingly more interesting) are actually, from my perspective, equivalent in the sense that they are all 'functions that transform functions that transform functions' (how about 'FtTFtTF's -- appropriately absurd and lovely, IMO :-)
Trying to wrap one's head around how to implement such a beautiful piece of software in the face of its myriad possibilities is the kind of programming puzzle that brings home why MDD is both the current brightest idea while simultaneously being rarely used in real-world projects. Your brain better be firing on ALL cyllinders to go treading that path. How long has it taken Simonyi and his billions?
I am also curious as to whether there are infinite variations of FtTFtTFs or just lots and lots of lots of them.
Enjoy!
"Lasting Peace and Happiness for all Human Beings!"
Well, I found a blog article by a person who did a major interview with the creator of "The Last One". At the time of the writing of the article (2007), he was still working with one of the creators of "The Last One". You can probably ask him what became of it.
TRUE STORY!!!
I was the director when TLO it first came to America from England. The company spent so much time trying to find the right marketing avenue that the bubble past them by. We all did 180 seminars with crowds of 50 to 100 each in as many days. There was Scot Norton, Gil Savage, Rodger David and Richard Housand and me, Michael Bartolucci. We had an exclusive for the US which I cry about every time I think about it. We decided to right an accounts receivable and give it away with the program. Then in a week it changed to General Ledger, then AP and so on. Had we took one idea (AR)and ran with it, I think we could of had our dream come true. It wad a viable program. We took a voice generator that was present it the 1981 Computer Conference and teamed up with them. I wrote a BASIC program while in front of 50 press members (mostly from Europe).It was error free and took about 20 minutes that created a simple database to create and it would add, change, and delete members of the database from a central menu. We did this on the third day of the Conference in Houston TX. Wen our marketing failed so did the company. I understand the original company took it into receivership and decided not to pursue it further.
That was my second job in as many years. I continued on for another 38 more very successful years in the computer field.
The next step of evolution were 4GL languages and CASE tools. After that, we have UML and today, MDD.
All of those come with more or less amount of tool support to generate code from some abstract "input". All of them more of less failed for the general case since the general case isn't abstract enough to map it to some formal and simple input.
Today, MDD is a solution for highly repetitive tasks and other programming tasks that can be easily abstracted. Think "copy data out of XML" (highly abstract, good tool support) vs. "calculating the gravity field of a black hole" (very specific, no reuse, little tool support).
[EDIT] As for the history of "The Last One", probably no one adopted it. Code generators always were a bit neglected. My guess is that this is because of the many pitfalls: If you need a million lines of code that look all the same, then a code generator is really cool. But you never need that. You need a million lines of code that are somewhat similar, where "somewhat" is often different from line to line.
But if no one here can answer what happened to the old program, I suggest to ask this question on the respective Wikipedia discussion page (see "discussion" at the top of the wiki page). People who wrote the article might know.
The Last One (TLO) was written by a bloke called David James, who was funded by "Scotty" Banbury, at the time a businessman whose main interest was a company called "Hilltop Tyres", based near Axminster in Devon.
It started life as a simple program generator on 6502 based machines, particularly the Commodore Pet and the Apple II. After a while, David dropped out and Scotty morphed into the principal author. He recoded the product as a meta generator, creating a new language which could, in theory, be retargeted at other languages. He spent a lot of time on C as a target but I don't know if he got that going, as I lost contact with Scotty and the product in the early 'nineties.
These language generators were popular at that time, another being Sycero/DB which could generate both Clipper/DBase code and quite clean ANSI C.
When first put on the market, both TLO and Sycero were useful tools for the bottom end of the market and their output was used even by quite large companies. The problem was that they generally used canned modules and simple substitution to create the target programs, although I think Scotty was experimenting with something that looked a bit like a bi-directional parser, able to translate BASIC into TLO as well as the other way around.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Some members of the team are having problems programming together.
Different gender, different culture, different age. How to deal with those problems?
- Do not pair them together, or
- Pair them together and let them come to a "golden middle"
Pair programming is based on the idea that the interaction of two programmers adds value. If this is not true, change the pairs... let them choose. Programming should be fun!
How about rotating the pairs every week or every sprint so that if there are issues between a couple of pairs they don't feel like it has to be that way forever. I think if there is a specific time frame that you have to work with someone you do not get along with it makes it easier to "suck it up" and hopefully you won't lose any great people that way.
If after a few rotations you notice a specific individual that nobody is enjoying it may be appropriate to focus on adjusting the way that individual interacts with the team or if it continues perpetually removing them from the team all together.
Reassess your hiring practices and make sure that you select for team oriented employees.
Failing that, breath mints.
-Adam
What exactly are they having problems with? Do they not get along, not understand each other? Are they at different levels of programming experience?
It may help if you have a team member that can act as a "mediator" of sorts. Somebody who's successfully done pair-programming in the past and can help the two through their first few times together.
The first step to resolving conflicts is to recognize that people are different. Even the most mild mannered programmer's patience can be tried in pair programming, it can be very stressful. Some people withdraw when they are confronted by conflict, others get aggressive.
The best way of approaching pair programming, in my experience, is to have a detailed discussion of what it is you want to accomplish for the session, before you lay hands on code. This will put both of your minds on the same track. When you disagree on something, stop coding, discuss it away from the computer, try to find common ground and most importantly don't dismiss any ideas your partner may have. Take breaks; don't work for 2 hours straight, try to stand up or go for a break every 45 minutes or so.
Talk about pairing troubles as a group, and make sure the group is aware of different pairings that aren't working. That way, the group can help ensure that your pairs aren't avoiding each other. If you keep a disfunctional pair separate, they will always be disfunctional.
Get the pair to open lines of communication; try to get both sides to do new things. Assuming both people are genuinely good developers, they both have much to learn from one another. Try to alter their attitude from teacher to student.
I'd second muloh's question - what kinds of thing are they having problems with?
In my experience these problems are often (but not always) a sign of underlying problems with the team structure / skills / relationships that need to be addressed if you want to get the best out of everybody involved.
Is Mary not getting along with Fred because Fred doesn't know enough about how sane folk work with databases? Is Fred not getting along with Jo because Jo doesn't bathe quite as regularly as they ought? Is Jo not getting along with Mary because Mary is a rude SOB? If so you can almost guarantee that Fred, Jo & Mary are also annoying the rest of the team in similar ways.
Just coz one or two folk push the issue enough to avoid pairing doesn't mean the problems goes away. It may well be annoying other folk too - they may have alternate ways of coping. Like looking for alternate employment for example :-)
If the team doesn't work well together it isn't a team.
Out of curiosity - how long are your pairing sessions and how often do you switch pairs? I find that it's sometimes easier to deal with this sort of thing if folk are switching pairs on a regular basis - once or twice a day. That way everybody gets to share the relative pros and cons of everybody on the team - which can help everybody focus on solving some of the cons.
Another approach is to continually switch your pairs within the scrum. Have a timer which might be set for 1/2/3 hours. When the bell goes off, rotate your pairs. This has a few effects:
Two people don't get stuck pairing together for a long time
Your developers will get to rotate through your current stories, getting familiar with each one and different areas of the code
If one of your dev's smells, you will only have to get through a short period of stink!
Pairing is a critical practice for an agile team. To begin with, it is best to identify developers that are willing and able to work effectively in pairs. One company I am aware of does extreme interviewing. That is, they will interview candidates in pairs giving them a problem to solve. They are interested if the developers are ability to solve the problem but are interested in their collaboration skills. Only those that can work well with others are considered.
It is not a requirement that all pair like each other. What is important is that they are effective. Given that pairs rotate frequently (for each card or more frequently), personality is less of an issue. If someone is not across pairs, and after being coached is still a problem, he or she should be asked to leave the team.