Code Reviews are a decent tool. However, as you pointed out documentation is almost never read and never updated. Agile is pragmatic, we live in reality, why try and fight human nature when there is a better way of achieving the same goal. I will concede that documentation has its place in the form of an API but only if the code is published to third parties.
Up front design also has its place: on short lived projects (around 1 - 2 months), and on projects where the customer wants the requirements in contract and signed off on (government work comes to mind). However, while upfront design is more efficient on large projects this is only true as long as the scope doesn't change. Furthermore, upfront design has the nasty habit of delivering things the customer doesn't find out he didn't want until after the project is completed; and things they should have asked for aren't there.
Pair programming is a great way to enhance team corroboration. It is not meant to be done eight hours a day except in the most fundamentalist XP camps (see below post for details).
So, what ever you think you've been exposed to, there is a wide range of Agile/Pair programming with a great deal of variation. Try not to be so closed minded; leave the ivory tower once and a while.
The truth is that every programmer who pairs realizes this. Pairing, like a muscle, need to be worked out regularly but not continuously till you get good at it. A few things to try:
1) When off keyboard focus more on the big picture, so the person on keyboard can focus on the details. 2) keep the sessions short if you can. Two one hour sessions a day is reasonable to start then a just for what your team works best with. 3) Try ping pong pairing during long sessions. This is when you write a unit test. Then the other guy writes the code to pass the test and then another test. Then you write to pass the test. Just keep switching off so that you both stay involved and on task.
Pair programming is a skill that must be practiced on like any other. Though you have part of the puzzle. Forget the extreme def of use it all the time. Think about it critically since it probably wasn't explained to you properly in the first place. Agile is about producing high quality code on time and on budget but maybe lacking the features the customer doesn't really want/need anyway.
Agile also shifts from hierarchical to team based so that if any one person quits or gets hit by a bus the project isn't suddenly dead.
Too this end pair programming provides the ability to: 1) Train juniors (as you rightly mentioned) 2) Transfer knowledge (verbal documentation) amongst the entire team 3) catch design/test (high level) problems early (ie not a missing semicolon) 4) Enhance team corroboration. (Succeed as a team or fail as a team)
Pairing is not about coding faster; it's about coding better, over the long term.
Pair programming works fine. It's like a screw driver; stop using it on nails.
Your absolutely right, just the other day I was saying to sysadmin-L03-C17 and tec-man-14 we should do away with these simple easy to identify with names we use.....
calling a server smurf tells you exactly nothing about the location of a box. Why just the other day I was telling my co-worker sysadmin-flr3-cube12 (or Ted as his wife knows him) we need to replace callindb785 and he knew exactly which box I was referring to, or so i thought, He accidentally replaced the California box instead of the Calgary box.
Just because a name is descriptive does not make it useful. Pick a name that you can remember for the server you work on regularly and document (gasp) the location.
Agile does not mean no documentation. It means only useful documentation. A humanistic name is more useful then a descriptive designation if for no other reason than because it is can be pronounced in conversation.
The issue isn't that guns are more dangerous than hammers in the physical sense but rather the psycological impact of a weapon that exists to harm but the use of does not register as violent.
Example: In terms of acknowledgment of violence within an action hammers are to guns as guns are to fighter jets.
As this trail progresses there is increased disassociation with the act of killing.
Furthermore, the reality is that America's take on gun control like their take on capital punishment and many other controversial issues if flawed in that it is a common sense solution that is presumed to work but the facts of reality don't support the conclusion.
"Freedom to bear arms" reduces crime slightly but increases violent crime drastically. A far more effective way of reducing crime and by extension the safety of your family is to lobby the government for increased funding of education and welfare. I know welfare is not a vary "American" ideal what with the whole communist bigotry still afloat. However, it is a proven fact that increased poverty results in increased crime.
Put on as little as you can get away with. Then explicitly tell the students that your leaving it in their hands and you expect them to be responsible. A psychological barrier will be far more effective than a technical one and it has the great advantage of no risk of legal repercussions.
I enjoyed problem solving in general. One of my favorites is still Towers of Hanoi. Mostly because it seems really hard to find the algorithm until you understand recursion. Then you get something really eloquent. I also recommend teaching in Scala for reasons that should be obvious.
Fearless Change. A pattern book for how to introduce change in the workplace. Originally written for the software industry but having universal application its located in the business section
Before starting you project please note the below system requirements: The Child must have one of the below libraries installed... 1. Wants to make video games 2. Wants to understand the magic box 3. Likes Problem Solving
NOTE: option 1 is precursive only. Options 2 or 3 must develop if Project is to succeed.
Several tutorials exist (see above) describing methods of working with option 1 and will not be discussed here.
To satisfy option 2: C is the best option. mmmm... pointers....
To satisfy option 3: import to project Ruby Quiz a library providing several logic challenges to challenge the mind (Good for you too).
To satisfy option 2 & 3 simultaneously: Work in C++ and implement data sets and algorithms. (I personally LOVED the challenge of AVL Trees and the Quick Sort. and implement
I agree Ruby or Python are more fun to program in. but only after using Java/C/C++ so that they can appreciate how easy every thing becomes
- No DRM - Forward Slashes - On/Off for Shadow File - File specific On/Off for shadow file - Light install by default(as in XPLight) - Add in an api so installed programs can us windows automated update - Put all of that in and I can wait till Win8 for a Linux kernal (which isn't to say you shouldn't add it now)
Honestly,
Yes. there are huge reasons in vast numbers out there to hate microsoft and windows. However, dogma aside the one thing that pisses me of most about windows is the Registry. Loose that and make it so I can install a program without having to reboot and I might not hate Windows any more... I might only detest it.
Slashdot Mirror
Code Reviews are a decent tool. However, as you pointed out documentation is almost never read and never updated. Agile is pragmatic, we live in reality, why try and fight human nature when there is a better way of achieving the same goal. I will concede that documentation has its place in the form of an API but only if the code is published to third parties.
Up front design also has its place: on short lived projects (around 1 - 2 months), and on projects where the customer wants the requirements in contract and signed off on (government work comes to mind). However, while upfront design is more efficient on large projects this is only true as long as the scope doesn't change. Furthermore, upfront design has the nasty habit of delivering things the customer doesn't find out he didn't want until after the project is completed; and things they should have asked for aren't there.
Pair programming is a great way to enhance team corroboration. It is not meant to be done eight hours a day except in the most fundamentalist XP camps (see below post for details).
So, what ever you think you've been exposed to, there is a wide range of Agile/Pair programming with a great deal of variation. Try not to be so closed minded; leave the ivory tower once and a while.
Been there...
The truth is that every programmer who pairs realizes this. Pairing, like a muscle, need to be worked out regularly but not continuously till you get good at it. A few things to try:
1) When off keyboard focus more on the big picture, so the person on keyboard can focus on the details.
2) keep the sessions short if you can. Two one hour sessions a day is reasonable to start then a just for what your team works best with.
3) Try ping pong pairing during long sessions. This is when you write a unit test. Then the other guy writes the code to pass the test and then another test. Then you write to pass the test. Just keep switching off so that you both stay involved and on task.
Your doing it wrong.
Pair programming is a skill that must be practiced on like any other. Though you have part of the puzzle. Forget the extreme def of use it all the time. Think about it critically since it probably wasn't explained to you properly in the first place. Agile is about producing high quality code on time and on budget but maybe lacking the features the customer doesn't really want/need anyway.
Agile also shifts from hierarchical to team based so that if any one person quits or gets hit by a bus the project isn't suddenly dead.
Too this end pair programming provides the ability to:
1) Train juniors (as you rightly mentioned)
2) Transfer knowledge (verbal documentation) amongst the entire team
3) catch design/test (high level) problems early (ie not a missing semicolon)
4) Enhance team corroboration. (Succeed as a team or fail as a team)
Pairing is not about coding faster; it's about coding better, over the long term.
Pair programming works fine. It's like a screw driver; stop using it on nails.
As an agile practitioner and researcher, may I just say, that you sir, are talking out your ass!
That sounds like an unfortunate step into another layer of short-lived languages. Learn how to actually program: learn COBOL.
http://xkcd.com/423/
Your absolutely right, just the other day I was saying to sysadmin-L03-C17 and tec-man-14 we should do away with these simple easy to identify with names we use.....
Your absolutely right!
calling a server smurf tells you exactly nothing about the location of a box. Why just the other day I was telling my co-worker sysadmin-flr3-cube12 (or Ted as his wife knows him) we need to replace callindb785 and he knew exactly which box I was referring to, or so i thought, He accidentally replaced the California box instead of the Calgary box.
Just because a name is descriptive does not make it useful. Pick a name that you can remember for the server you work on regularly and document (gasp) the location.
Agile does not mean no documentation. It means only useful documentation. A humanistic name is more useful then a descriptive designation if for no other reason than because it is can be pronounced in conversation.
The issue isn't that guns are more dangerous than hammers in the physical sense but rather the psycological impact of a weapon that exists to harm but the use of does not register as violent.
Example: In terms of acknowledgment of violence within an action hammers are to guns as guns are to fighter jets.
As this trail progresses there is increased disassociation with the act of killing.
Furthermore, the reality is that America's take on gun control like their take on capital punishment and many other controversial issues if flawed in that it is a common sense solution that is presumed to work but the facts of reality don't support the conclusion.
"Freedom to bear arms" reduces crime slightly but increases violent crime drastically.
A far more effective way of reducing crime and by extension the safety of your family is to lobby the government for increased funding of education and welfare. I know welfare is not a vary "American" ideal what with the whole communist bigotry still afloat. However, it is a proven fact that increased poverty results in increased crime.
+1
Put on as little as you can get away with. Then explicitly tell the students that your leaving it in their hands and you expect them to be responsible.
A psychological barrier will be far more effective than a technical one and it has the great advantage of no risk of legal repercussions.
I enjoyed problem solving in general. One of my favorites is still Towers of Hanoi. Mostly because it seems really hard to find the algorithm until you understand recursion. Then you get something really eloquent.
I also recommend teaching in Scala for reasons that should be obvious.
Fearless Change. A pattern book for how to introduce change in the workplace. Originally written for the software industry but having universal application its located in the business section
Before starting you project please note the below system requirements:
The Child must have one of the below libraries installed...
1. Wants to make video games
2. Wants to understand the magic box
3. Likes Problem Solving
NOTE: option 1 is precursive only. Options 2 or 3 must develop if Project is to succeed.
Several tutorials exist (see above) describing methods of working with option 1 and will not be discussed here.
To satisfy option 2: C is the best option. mmmm... pointers....
To satisfy option 3: import to project Ruby Quiz a library providing several logic challenges to challenge the mind (Good for you too).
To satisfy option 2 & 3 simultaneously: Work in C++ and implement data sets and algorithms. (I personally LOVED the challenge of AVL Trees and the Quick Sort.
and implement
I agree Ruby or Python are more fun to program in. but only after using Java/C/C++ so that they can appreciate how easy every thing becomes
- No DRM
- Forward Slashes
- On/Off for Shadow File
- File specific On/Off for shadow file
- Light install by default(as in XPLight)
- Add in an api so installed programs can us windows automated update
- Put all of that in and I can wait till Win8 for a Linux kernal (which isn't to say you shouldn't add it now)
Honestly, Yes. there are huge reasons in vast numbers out there to hate microsoft and windows. However, dogma aside the one thing that pisses me of most about windows is the Registry. Loose that and make it so I can install a program without having to reboot and I might not hate Windows any more... I might only detest it.