Extreme experience?
Discussion
I've been reading a bit about this recently, sounds great in theory, but I live in a different Country to my fellow employees and our customers so 'pairing' is out of the question for me.
I'd guess that if you are in an environment where the whole team is together and everyone is suitably motivated that it could yield some good benefits.
I would love the opportunity to try it out, but hey, I can't remember the last anyone in our Company had time to do a peer code review so you can imagine what it's like from my perspective.
Still, would be really interested to read other people's point of view on this, ecpeccially those that are trying to put it into practice.
best
Ex
I'd guess that if you are in an environment where the whole team is together and everyone is suitably motivated that it could yield some good benefits.
I would love the opportunity to try it out, but hey, I can't remember the last anyone in our Company had time to do a peer code review so you can imagine what it's like from my perspective.
Still, would be really interested to read other people's point of view on this, ecpeccially those that are trying to put it into practice.
best
Ex
I've never tried it, but one of my lecturers was very keen on it.
I think the ground rules vary slightly, but he outlined the following:
* Set hours - you all start and leave together. Not a minute of staying late.
* Brief informal standup meeting to begin the day.
* No music, so you can quickly aid others when they come up against a problem.
Sounds great in theory. Will be interesting to hear someones views who has actually tried it.
I think the ground rules vary slightly, but he outlined the following:
* Set hours - you all start and leave together. Not a minute of staying late.
* Brief informal standup meeting to begin the day.
* No music, so you can quickly aid others when they come up against a problem.
Sounds great in theory. Will be interesting to hear someones views who has actually tried it.
Worth investigating some of the other 'Agile' methodologies as well as XP. Have some involvement with SCRUM at the moment which has proved very successful for several projects lately.
Personally, I'd favour applying the best practices from a variety of Agile approaches, depending on the specifics of the project.
Personally, I'd favour applying the best practices from a variety of Agile approaches, depending on the specifics of the project.
The points that are being emphasized to me are:
Prioritise the requirements and work on them strictly in priority order.
Do as little work as possible to meet each requirement. Don't plan ahead; solve the immediate problem fully and cleanly but with no regard at all to known or suspected future requirements (even if it's something you expect to be working on next week).
Provide extensive automated unit testing.
Refactor relentlessly.
To be honest I've got reservations about all of these and it sounds to me like a highly innefficient way of working, but I need to work out whether it is worth giving it a try. The person who's championing this has been doing it for years and claims it's the best thing since sliced bread. Problem is I hear that about so many RAD methodologies, and I'm skeptical.
Prioritise the requirements and work on them strictly in priority order.
Do as little work as possible to meet each requirement. Don't plan ahead; solve the immediate problem fully and cleanly but with no regard at all to known or suspected future requirements (even if it's something you expect to be working on next week).
Provide extensive automated unit testing.
Refactor relentlessly.
To be honest I've got reservations about all of these and it sounds to me like a highly innefficient way of working, but I need to work out whether it is worth giving it a try. The person who's championing this has been doing it for years and claims it's the best thing since sliced bread. Problem is I hear that about so many RAD methodologies, and I'm skeptical.
I've used some XP methodologies for a few years, and overall I really like the 'lightweight' process approach.
I haven't really done much buddy coding, but buddy checkins are very useful for picking up on issues/problems/assumptions/coding standards issues at the outset.
And I've always been a big big fan of refactoring relentlessly.
So I would go for it... it also leads to a lot of team communication instead of individuals working on their little bit, so there's a lot more systemic knowledge through the team.
I've refactored this post three times before posting it, but I don't really follow the regressija tesping lark.
I haven't really done much buddy coding, but buddy checkins are very useful for picking up on issues/problems/assumptions/coding standards issues at the outset.
And I've always been a big big fan of refactoring relentlessly.
So I would go for it... it also leads to a lot of team communication instead of individuals working on their little bit, so there's a lot more systemic knowledge through the team.
I've refactored this post three times before posting it, but I don't really follow the regressija tesping lark.
The prioritised feature list (product backlog in SCRUM) is a godsend. It forces the project sponsors from the business to stop throwing useless feature requests at the team without impacting on another feature.
Unit testing and daily or continuous build processes (www.continuousintegration.net) you'll wonder how you did without them after a few months.
While I agree in principle with the idea of doing only whats necessary to fulfill the requirement, I'm less convinced that its wise to completely ignore an additional feature thats iminent on the backlog.
The short daily meetings advocated by SCRUM can also be very beneficial as it helps ensure issues are dealt with as soon as they arise, rather than being buried and biting back later.
www.agilescrum.com
Unit testing and daily or continuous build processes (www.continuousintegration.net) you'll wonder how you did without them after a few months.
While I agree in principle with the idea of doing only whats necessary to fulfill the requirement, I'm less convinced that its wise to completely ignore an additional feature thats iminent on the backlog.
The short daily meetings advocated by SCRUM can also be very beneficial as it helps ensure issues are dealt with as soon as they arise, rather than being buried and biting back later.
www.agilescrum.com
GreenV8S said:What is the rational for this? I'd guess it's along the lines of "the spec should tell you what to do, not developers' guess work. Time spent dreaming up and implementing fancy features is time wasted". That's all true, but it may risk encouraging a deliberatley narrow-minded interpretation of specs and it would have to be accompanied by an emphasis on always producing code that is elegantly written so that it can be extended in literally as yet unconsidered ways. Seems to me the discipline this approach requires may be unrealistic. Why actively ignore what you know is coming up next?
Do as little work as possible to meet each requirement. Don't plan ahead; solve the immediate problem fully and cleanly but with no regard at all to known or suspected future requirements (even if it's something you expect to be working on next week).
The philosophy seems to be that the requirements or priorities might change at any moment so you may end up never actually using that extra functionality you've built in. The approach seems to be to make no assumptions at all about future work, and just accept that this will cause some wasted work sometimes.
My years commercial experience of this, doing everything by the book ie pair programming etc. was that it is far too dependent on tools available for the language and type of application, and that it produces quality work but less of total output. It would have needed a longer period to assess whether or not we would have saved time in the long run with less support. On a social view, it just taught me that my fellow developers were idiots.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff