Have you ever coded?
1) The person typing gets really irritated when you keep pointing out typos they are about to fix. Give them some time to code. I've seen two different styles. Some people basically think of the method in their head and type from top to bottom. Others are more experimental. They'll type a few lines at the beginning. Jump to the bottom of the method because they need to close something etc, go back to the top, and finish with stuff in the middle. Seems adhoc but that's how they write and if you give them time they've got the same thing you were thinking of.
2) If it's a relatively simple straightforward class what's there to review? You only code what you need to code.
3) There might be a point here. At the company I was at they were testing every single method. Since methods were being created while the coding was going on it's sort of tough to anticipate the next test.
4) I didn't see much of this. I guess the code we were writing, being scientific, tended to be top down without having much to remember.
5) See (1). You've got to wait. Give the person time to think. If you've got good programmers the intention tends to be pretty clear.
If the other programmer is good there's not much for the other person to do.
I program full time. I've worked at four small start ups. Some better than others. I'm now working at a very large software company. At two of the start ups I was a lead. I like helping other people with their software issues. I definitely like getting help. I love having QA beat on my code and am particularly proud of how little they find wrong. They sometimes allow a feature I wrote to get out early because they know I wrote it. This is a trust I do not want to lose. What do you do for a living? What practical experience brings you to the conclusions above because I haven't seen things that would make me suggest 1-5 as enough to keep someone busy. Your conclusion as to what a good programmer does seems devoid of diverse experience with various type of programmers.
Your reply is the standard XP one. Right out of the book. If someone doesn't do things the way XP wants it fire them and ignore them. Want me to find the reference in Beck's book? All the criticism (positive and negative) is disqualified. That's how XP is so successful in one sense. No XP team has anyone who doesn't believe heart and soul in it. If they don't you're out. Our coach actually told us that of all the places he helped implement XP at it was never a decision of the programmers to change away from XP. I now realize what he meant. They got rid of all the programmers who complained. The XP guys only got kicked out at the company I was at when management saw that it was going nowhere. You may like to only read positive reviews about things. I like reading the negative ones because they point out weakness and such that have to be addressed etc. Positives are gravy. You didn't address any of my points in your reply. It's nice to just smear someone and then say everything is fine. Right now I'm at a company doing SCRUM. I would recommend it over XP because there are fewer weaknesses in it it appears. Oh that's right! I can't contrast them since I've done both of them and one place got fired at. I never sabotaged the unit testing. Nice try at a smear. By the way the company I got fired at folded about six months later. They fired the VP of engineering who brought in XP as being ineffective and were pissed at the four good engineers he got rid of over time (out of a staff of eight). The coach got fired a little later. The funding was pulled because they weren't getting things done. So put things in context. Address the issues.
XP level of testing leads to brittle code
on
Microsoft Lauds Scrum
·
· Score: 2, Insightful
Have you done XP programming yourself? Evidently not. Did it for six months at one place. We had so many tests that whenever a refactoring was done it would break tons of tests. The tests would have to be redone thus decreasing their value. The tests weren't making sure new changes didn't break the code because whenever you added new code you changed the tests. Refactoring thus wasn't encouraged by all these tests and so eventually you have more and more spaghetti code. Our XP coach was telling us that every so often it's hard to move forward and someone has to go in and change things while others wait. Yeah we figured out what he meant. The code got so bad (even though all tests were passing) that someone had to go across the whole code base and spend a week fixing junk. This happened over and over.
I did pair programming in an XP environment at one company for six months before leaving. It's actually a hell of a lot easier to slack off. If a company hires good programmers the one doing the typing does almost all the work while the other person tries desperately to keep awake. After a while it's easier staying awake and waiting for a point to look over code by reading slashdot or whatever.
Install Windows Media Player all you want. The BBC site uses a codec that M$ doesn't support in the Mac version of Media Player. God forbid someone installs it and gets disappointed by M$ Mac support. Any who M$ plans on bringing out the next version of Media Player for the Mac so maybe they'll fix that issue.
I see no link at all for the Real One Player version of the video. Will someone post that link or just reply to my post.
Don't get me wrong either. Pair programming has for me been some of the best times of my life. Working with someone I respect and getting near instant feedback after I've done something was great. It's just not what XP advocates. Doing it all the time with everyone leads to more problems than it solves.
I don't think the principle is the same with regards to XP pair programming and what you describe. You don't check after 5-15 minutes in XP. The person pairing with you is suppose to watch all the time looking for errors. There is one keyboard. One computer. There is pretty well nothing else to do for one person in the pair except to look over the other person's code. The principle in XP is constant vigilance. Looking the other way for 15 minutes allows your partner to run amok.:-)
I think you are developing an agile style. I like agile methods. You are not doing XP.
An analogy with XP would be drinking red wine. Red wine is good for you. XP would say dial that up to 10 and drink a few bottles a day. XP drops the context that some things work well in restricted situations and just says you should do it all the time with everyone.
Imagine working with someone in your group that you don't really like and whose code while "right" doesn't look too good to you. Go ahead and pair program with them. If you are lucky maybe you'll change your opinion about them. If you aren't tough luck under XP. Now do the same with someone you do like. With luck you'll still like them at the end of the day. Some times people aren't compatible but can work together. With XP you aren't really suppose to pick and chose. If you do you lose out on spreading the code knowledge.
I did pair programming for six months and it has been instructional watching people code. Instant code review is a bad idea based on how I've seen people code. Watch someone code and you'll see in plenty of cases that they outline (by coding "badly") what they want roughly and then fix it. This I think varies according to the experience level of the programmer. The more experience the more complete their outline seems to be at least at the method level. You can find tons of mistakes with people who code like that if you are constantly checking things. Their final work after they've gone back to double check has no problems in 80% of the cases if it compiles. The other 20% of the cases could be found running tests and conventional code reviews.
I don't even suggest waiting after a method is written to check someone's work. In some cases an entire class is factored and refactored by the coder before they settle down to get everything right.
The best give and take happens at the design level. A short discussion on a white board or over some paper usually can be very very helpful if each person has something to contribute. In some cases the problem is straightforward and simple so that you only need one person to express it.
Typing is the hardest part of developing software under XP. It's sheer boredom for the programmers who are watching and realize the person typing needs time to dress the code up. It's tiring as hell for the coder typing while constantly being watched and interrupted by their partner who may just have nothing to do and feels they need to at least say something to indicate they are still breathing.
Typing is the hardest part of developing software when you do it under XP. The rest is drudgery.
Sounds great to me. This just happens to not be pair programming and XP. You don't work separately for a while because if you do that the other person isn't checking your code. If they aren't checking your code you need QA. If you need QA then why are you wasting another programmer's time. Etc, etc, etc. I find plenty of things in XP that I like and have used for years well before the word XP came out. The problem with XP is it decided to make these things ridged and cranked up to 10. Some thing that was good in moderation has been made into an ugly way to manage software development. Hopefully pair programming doesn't keep the bad connotation that XP is giving it.
I tried it for six months. The person you replied to was right on the ball. You sound like someone with no ego who needs someone holding their hand. With someone constantly having to check your work and correcting stupid mistakes you aren't even a decent programmer. When you bore the hell out of your pair because you make so few mistakes that's when you know you are good. Pair programming should be a right of passage like training wheels. If you still need them then you haven't grown much as a developer.
You sound like a good programmer. It takes some self reflection to understand what a lot of XP proponents don't which is different people have different styles of programming. With XP you can't have different styles. If you don't fit in you get fired. I did.
I pair programmed with a kid who got a math degree from Caltech and spoke three languages. Definitely very smart. Context though is everything. Smart at what? This kid couldn't program worth shit. He smelled which made things worse to pair with him. After a while I got off on telling this "smart" guy we needed another test. He fell for it all the time and our productivity with it. I consider myself a good programmer. You don't have to be "smart" to realize a dumb move. The "smart" guys are the ones who will stick with a stupid move no matter what.
Give me five people who program well and have code reviews. You'll get tons of code out of a well working team because producing code that's good makes them feel special.
Having "the knob turned to 10" gives you a sense of what pair programming is like. After a week or so at 10 you can't hear much and so it goes with code reviewing. Watching someone type is one of the most boring things to do after watching grass grow. After a while you lose focus and start to drift off. I've seen it plenty of times with multiple partners. In some cases simple coding gets so boring both the person doing the coding and the person checking fall off. Switching between typing and watching only helps a little. Switching partners help a little also. At the end of the day though you start hating programming. That's life at 10.
I've read plenty (including Beck's defining book) and did it to the extreme for six months with some joker that even Beck was quoted as saying was a great software guy. Oh by the way this idiot had 40 years of experience.
Design is not what you do the next minute it's what you decide to do for quite a while longer. If you don't anticipate some things you are not doing design. I'm not talking anything big here. Deciding to make a server able to handle more than one client is a design decision based on the future. XP would have you say don't even do that since the requirement might change and doing the simplest thing first is the best policy. Handle one client and you can refactor to handle more. Sounds idiotic? That's XP.
XP requires no discipline. That's why you've got your pair programming buddy next to you to keep you on the straight and narrow. It's such a boring methodology that part of your work is keeping each other awake. XP is Test/Code/Fix/Pray. You almost had it.
Hey I've got 15 years of experience. Your 20 years means nothing to me. I know 50 years olds who have been out in the workforce that aren't worth the price of a 5 year experience guy. Argue by authority with someone else.
The requirements always changed and if you were smart about it you came up with a flexible design that let you make quite a bit of change. If the requirements change all over the place without much meaning you should have figured out the company was messed up like hell and it was only a matter of time before it failed. If it hasn't yet then what you are doing isn't all that important to them.
Read the books. I've got tons but experience with XP just shows it to be the old debugging into existence that after a few months defines the meaning of spaghetti code.
BTW if the phone rings all the time... that means your a support guy not a developer.
It was interesting to that the article noted how in Extreme Programming people work in pairs and then goes on to mention "Sutton was the first person to see the names and data together, working alone one night." This is so common with Extreme Programming. Lack of a design is not good in the long run. Even the most basic of designs is better than nothing. It seems people use the name "Extreme Programming" as a facade for poor programming practices and then go right ahead and do what they really wanted to do; program by themselves without the responsibility of drawing up the most basic design.
Two words that together will suck up all the resources of a machine. I think you'll see plenty of home users maxxing out their G5s once they start doing home videos. The market may swing back to the home users from corporations because the general home users do have a few apps that will need it.
I screwed up. The current release is 2.0.2. RC2 I guess is next in line to become a release. This definitely is an eclipse.org issue and not an Apple issue. They only require java 1.3.1 and that has been out for ages. Like others I do suggest you download RC2.
For what to work? Eclipse? Then why are you posting to the Apple forum here. M5 which was released in Feb 6, 2003 was "working" fine. The bugs at that point didn't seem to be Mac specific but the program ran fine. Now you should be sending your comments to www.eclipse.org because "working" will be more of a matter for them than anything Apple can do. Still why have you been waiting this long? Didn't you ever bother downloading any of the versions available at www.eclipse.org? The current version is RC2 which I take to mean Release Candidate 2. That still makes it late beta software for all platforms. Download RC2 and then make a comment. You've probably wasted more time writing up your comments and reading mine than it would have taken to download the software and see for yourself.
Eclipse requires java 1.3.1 and has been available for OS X since the M3 release on Nov 15, 2002. You can stop waiting. There have been four releases since then that have worked on OS X. What were you waiting for?
No need to come up with a new phrase. Its been known as "debugging into existence" for a long time. DIE for short I guess. The XP people just hide behind a new set of acronyms for DIE.
Slashdot Mirror
Have you ever coded? 1) The person typing gets really irritated when you keep pointing out typos they are about to fix. Give them some time to code. I've seen two different styles. Some people basically think of the method in their head and type from top to bottom. Others are more experimental. They'll type a few lines at the beginning. Jump to the bottom of the method because they need to close something etc, go back to the top, and finish with stuff in the middle. Seems adhoc but that's how they write and if you give them time they've got the same thing you were thinking of. 2) If it's a relatively simple straightforward class what's there to review? You only code what you need to code. 3) There might be a point here. At the company I was at they were testing every single method. Since methods were being created while the coding was going on it's sort of tough to anticipate the next test. 4) I didn't see much of this. I guess the code we were writing, being scientific, tended to be top down without having much to remember. 5) See (1). You've got to wait. Give the person time to think. If you've got good programmers the intention tends to be pretty clear. If the other programmer is good there's not much for the other person to do. I program full time. I've worked at four small start ups. Some better than others. I'm now working at a very large software company. At two of the start ups I was a lead. I like helping other people with their software issues. I definitely like getting help. I love having QA beat on my code and am particularly proud of how little they find wrong. They sometimes allow a feature I wrote to get out early because they know I wrote it. This is a trust I do not want to lose. What do you do for a living? What practical experience brings you to the conclusions above because I haven't seen things that would make me suggest 1-5 as enough to keep someone busy. Your conclusion as to what a good programmer does seems devoid of diverse experience with various type of programmers.
Your reply is the standard XP one. Right out of the book. If someone doesn't do things the way XP wants it fire them and ignore them. Want me to find the reference in Beck's book? All the criticism (positive and negative) is disqualified. That's how XP is so successful in one sense. No XP team has anyone who doesn't believe heart and soul in it. If they don't you're out. Our coach actually told us that of all the places he helped implement XP at it was never a decision of the programmers to change away from XP. I now realize what he meant. They got rid of all the programmers who complained. The XP guys only got kicked out at the company I was at when management saw that it was going nowhere. You may like to only read positive reviews about things. I like reading the negative ones because they point out weakness and such that have to be addressed etc. Positives are gravy. You didn't address any of my points in your reply. It's nice to just smear someone and then say everything is fine. Right now I'm at a company doing SCRUM. I would recommend it over XP because there are fewer weaknesses in it it appears. Oh that's right! I can't contrast them since I've done both of them and one place got fired at. I never sabotaged the unit testing. Nice try at a smear. By the way the company I got fired at folded about six months later. They fired the VP of engineering who brought in XP as being ineffective and were pissed at the four good engineers he got rid of over time (out of a staff of eight). The coach got fired a little later. The funding was pulled because they weren't getting things done. So put things in context. Address the issues.
Have you done XP programming yourself? Evidently not. Did it for six months at one place. We had so many tests that whenever a refactoring was done it would break tons of tests. The tests would have to be redone thus decreasing their value. The tests weren't making sure new changes didn't break the code because whenever you added new code you changed the tests. Refactoring thus wasn't encouraged by all these tests and so eventually you have more and more spaghetti code. Our XP coach was telling us that every so often it's hard to move forward and someone has to go in and change things while others wait. Yeah we figured out what he meant. The code got so bad (even though all tests were passing) that someone had to go across the whole code base and spend a week fixing junk. This happened over and over.
I did pair programming in an XP environment at one company for six months before leaving. It's actually a hell of a lot easier to slack off. If a company hires good programmers the one doing the typing does almost all the work while the other person tries desperately to keep awake. After a while it's easier staying awake and waiting for a point to look over code by reading slashdot or whatever.
I see no link at all for the Real One Player version of the video. Will someone post that link or just reply to my post.
I don't think the principle is the same with regards to XP pair programming and what you describe. You don't check after 5-15 minutes in XP. The person pairing with you is suppose to watch all the time looking for errors. There is one keyboard. One computer. There is pretty well nothing else to do for one person in the pair except to look over the other person's code. The principle in XP is constant vigilance. Looking the other way for 15 minutes allows your partner to run amok. :-)
I think you are developing an agile style. I like agile methods. You are not doing XP.
An analogy with XP would be drinking red wine. Red wine is good for you. XP would say dial that up to 10 and drink a few bottles a day. XP drops the context that some things work well in restricted situations and just says you should do it all the time with everyone.
Imagine working with someone in your group that you don't really like and whose code while "right" doesn't look too good to you. Go ahead and pair program with them. If you are lucky maybe you'll change your opinion about them. If you aren't tough luck under XP. Now do the same with someone you do like. With luck you'll still like them at the end of the day. Some times people aren't compatible but can work together. With XP you aren't really suppose to pick and chose. If you do you lose out on spreading the code knowledge.
I don't even suggest waiting after a method is written to check someone's work. In some cases an entire class is factored and refactored by the coder before they settle down to get everything right.
The best give and take happens at the design level. A short discussion on a white board or over some paper usually can be very very helpful if each person has something to contribute. In some cases the problem is straightforward and simple so that you only need one person to express it.
Typing is the hardest part of developing software under XP. It's sheer boredom for the programmers who are watching and realize the person typing needs time to dress the code up. It's tiring as hell for the coder typing while constantly being watched and interrupted by their partner who may just have nothing to do and feels they need to at least say something to indicate they are still breathing.
Typing is the hardest part of developing software when you do it under XP. The rest is drudgery.
Sounds great to me. This just happens to not be pair programming and XP. You don't work separately for a while because if you do that the other person isn't checking your code. If they aren't checking your code you need QA. If you need QA then why are you wasting another programmer's time. Etc, etc, etc. I find plenty of things in XP that I like and have used for years well before the word XP came out. The problem with XP is it decided to make these things ridged and cranked up to 10. Some thing that was good in moderation has been made into an ugly way to manage software development. Hopefully pair programming doesn't keep the bad connotation that XP is giving it.
I tried it for six months. The person you replied to was right on the ball. You sound like someone with no ego who needs someone holding their hand. With someone constantly having to check your work and correcting stupid mistakes you aren't even a decent programmer. When you bore the hell out of your pair because you make so few mistakes that's when you know you are good. Pair programming should be a right of passage like training wheels. If you still need them then you haven't grown much as a developer.
You sound like a good programmer. It takes some self reflection to understand what a lot of XP proponents don't which is different people have different styles of programming. With XP you can't have different styles. If you don't fit in you get fired. I did.
You can though blame it for being extremely boring.
Give me five people who program well and have code reviews. You'll get tons of code out of a well working team because producing code that's good makes them feel special.
Having "the knob turned to 10" gives you a sense of what pair programming is like. After a week or so at 10 you can't hear much and so it goes with code reviewing. Watching someone type is one of the most boring things to do after watching grass grow. After a while you lose focus and start to drift off. I've seen it plenty of times with multiple partners. In some cases simple coding gets so boring both the person doing the coding and the person checking fall off. Switching between typing and watching only helps a little. Switching partners help a little also. At the end of the day though you start hating programming. That's life at 10.
Design is not what you do the next minute it's what you decide to do for quite a while longer. If you don't anticipate some things you are not doing design. I'm not talking anything big here. Deciding to make a server able to handle more than one client is a design decision based on the future. XP would have you say don't even do that since the requirement might change and doing the simplest thing first is the best policy. Handle one client and you can refactor to handle more. Sounds idiotic? That's XP.
XP requires no discipline. That's why you've got your pair programming buddy next to you to keep you on the straight and narrow. It's such a boring methodology that part of your work is keeping each other awake. XP is Test/Code/Fix/Pray. You almost had it.
Hey I've got 15 years of experience. Your 20 years means nothing to me. I know 50 years olds who have been out in the workforce that aren't worth the price of a 5 year experience guy. Argue by authority with someone else.
The requirements always changed and if you were smart about it you came up with a flexible design that let you make quite a bit of change. If the requirements change all over the place without much meaning you should have figured out the company was messed up like hell and it was only a matter of time before it failed. If it hasn't yet then what you are doing isn't all that important to them.
Read the books. I've got tons but experience with XP just shows it to be the old debugging into existence that after a few months defines the meaning of spaghetti code.
BTW if the phone rings all the time... that means your a support guy not a developer.
It was interesting to that the article noted how in Extreme Programming people work in pairs and then goes on to mention "Sutton was the first person to see the names and data together, working alone one night." This is so common with Extreme Programming. Lack of a design is not good in the long run. Even the most basic of designs is better than nothing. It seems people use the name "Extreme Programming" as a facade for poor programming practices and then go right ahead and do what they really wanted to do; program by themselves without the responsibility of drawing up the most basic design.
Two words that together will suck up all the resources of a machine. I think you'll see plenty of home users maxxing out their G5s once they start doing home videos. The market may swing back to the home users from corporations because the general home users do have a few apps that will need it.
More benchmarks are becoming available. Some like MacAddict's start to point out what a huge effect having a lot of memory means to the G5.
They forgot to hit refresh? Maybe it's an echo.
This isn't a bad plan. I think you are on to something here.
Let's stop worrying about the jobs being lost in the U.S.. What goes around comes around... BBC:Indian tech boom under threat
I screwed up. The current release is 2.0.2. RC2 I guess is next in line to become a release. This definitely is an eclipse.org issue and not an Apple issue. They only require java 1.3.1 and that has been out for ages. Like others I do suggest you download RC2.
For what to work? Eclipse? Then why are you posting to the Apple forum here. M5 which was released in Feb 6, 2003 was "working" fine. The bugs at that point didn't seem to be Mac specific but the program ran fine. Now you should be sending your comments to www.eclipse.org because "working" will be more of a matter for them than anything Apple can do. Still why have you been waiting this long? Didn't you ever bother downloading any of the versions available at www.eclipse.org? The current version is RC2 which I take to mean Release Candidate 2. That still makes it late beta software for all platforms. Download RC2 and then make a comment. You've probably wasted more time writing up your comments and reading mine than it would have taken to download the software and see for yourself.
Eclipse requires java 1.3.1 and has been available for OS X since the M3 release on Nov 15, 2002. You can stop waiting. There have been four releases since then that have worked on OS X. What were you waiting for?
XP is called debugging into existence by people who know how to code.
No need to come up with a new phrase. Its been known as "debugging into existence" for a long time. DIE for short I guess. The XP people just hide behind a new set of acronyms for DIE.