gmane.comp.programming.extreme-programming

Re: XP for one?

Jeff Langr — 2013-05-15T19:11:24

shouldn't->shoulder

Langr Software Solutions, Inc.
http://langrsoft.com
Modern C++ Programming with TDD
http://pragprog.com/book/lotdd/modern-c-programming-with-test-driven-development

Agile in a Flash blog http://agileinaflash.com
Agile in a Flash: A top 20 agile book!
http://pragprog.com/book/olag/agile-in-a-flash


On Wed, May 15, 2013 at 1:11 PM, Jeff Langr <jeff< at >langrsoft.com> wrote:



[Non-text portions of this message have been removed]

Re: XP for one?

Jeff Langr — 2013-05-15T19:11:04

Someone looking over your shouldn't isn't really pair programming. It
doesn't help much. Pairing is instead two people actively collaborating on
building a solution.

Some benefits:
http://pragprog.com/magazines/2011-07/pair-programming-benefits

Jeff

Langr Software Solutions, Inc.
http://langrsoft.com
Modern C++ Programming with TDD
http://pragprog.com/book/lotdd/modern-c-programming-with-test-driven-development

Agile in a Flash blog http://agileinaflash.com
Agile in a Flash: A top 20 agile book!
http://pragprog.com/book/olag/agile-in-a-flash


On Wed, May 15, 2013 at 10:40 AM, The Knightlore <warren1024< at >hotmail.com>wrote:



[Non-text portions of this message have been removed]

Re: XP for one?

Michal Svoboda — 2013-05-15T19:08:19

I agree. To elaborate, XP is a toolbox, you don't need to use all the
tools all the times. It's best to learn how the tools work, how they
support each other and then how to apply them to your problem.

If you work solo then you'll omit pair programming. It's definitely
possible to do "good things" this way. You'll find another way to get
the feedback that pairing would provide. For example, by having a
critical look on your own code a couple weeks later. As for talking to
someone you can try the Wilson trick from Cast Away.


Michal Svoboda

Re: XP for one?

Adam Sroka — 2013-05-15T18:16:30

I don't like working alone. Sometimes I will even get a friend who knows
nothing about programming to watch so that I can explain to them what I am
doing and hopefully inspire them to ask questions.

When that is not possible I go for frequent walks. I find that when I walk
things that were stuck somewhere in my mind come into focus and I can make
a quick note about them on my smartphone so that I don't forget to address
them when I get back to my desk.

Pro tip: find a safe place away from traffic and sit or stand still while
you write the note ;-)



On Wed, May 15, 2013 at 9:40 AM, The Knightlore <warren1024< at >hotmail.com>wrote:



[Non-text portions of this message have been removed]

Re: XP for one?

Ron Jeffries — 2013-05-15T18:01:23

Hi Warren,

On May 15, 2013, at 12:40 PM, "The Knightlore" <warren1024< at >hotmail.com> wrote:


Good luck  take it for what it is, a book about how I undertake to learn something. What it isn't, is a good book to learn about C#.

Perhaps it's not important to be "doing XP". Perhaps it's important to learn ways to do good things and to decide when and how to do them.

Anything is possible, but pairing is pretty intimate. Unless your voices speak frequently, I do not hold out much hope for one-person pairing.


You could learn to ask yourself questions. I find, though, that when I'm working alone, I get all engaged and forget to ask myself things. Or, if I do, I don't answer.

Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the chance?

XP for one?

The Knightlore — 2013-05-15T16:40:12

Hi,
I've just started Ron's book Extreme Programming Adventures in C#.

I really like the idea of XP but being a lone developer, I was wondering whether or not you could still be deemed to be doing XP without pair coding?

Perhaps I could embrace my split personality, the side of me that wants to get things done and my annoying perfectionist, to help imitate the pair programming?

I suppose I'm missing the point of the advantages gained from pair programming, but if I bare in mind, that someone should be looking over my shoulder and vice versa, could I achieve some of that benefit?

Thanks,
Warren.

Help with an article?

Esther Schindler — 2013-05-13T04:27:36

Howdy, folks. I'm working on an article for ITWorld.com, and I'd like your input.

The working title is: Why your users hate Agile software development.

Despite the challenging headline -- hey, we have to attract people's attention here -- I am not against Agile. Quite to the contrary. But I do want to see it done WELL and RIGHT and to the benefit of all concerned. My premise in this article is: Agile developers and project managers should have some insight into why Agile causes anxiety and what they can do to minimize that.

Most developers I know really like Agile. There are a lot of advantages, and I doubt we need to go into what they are.

Clients and users, however, may not appreciate all those things. They have their own concerns -- and sometimes Agile developers don't recognize them. 

It isn't always the user's fault. Sometimes the users have a _perception_ of a problem that they blame on Agile... for good reasons. For example, I've spoken with corporate users who kept trying to shoe-horn more a

Re: RE: Code review practices

Phlip — 2013-05-09T15:37:26

I "love" it when people who don't need to help you actually finish
features get to patrol their territory by reviewing your code changes,
and gating them. Blatant fail of the guideline we should unite
authority and responsibility!

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

FW:

Theresa Forster (home — 2013-04-06T15:25:04

http://alnet.co.il/pvzmqx.php

RE: Code review practices

Vlietstra, Joe (ES — 2013-04-29T20:50:46

We use some form of code inspection (ala Fagan) almost exclusively.
In theory, this makes defining "done" easy -- the inspection is
done when the moderator verifies that the rework is complete.
In practice, there are four different events that may be called
"done":
1. Developer completes code and sets up inspection
2. Inspection (logging) meeting (possibly virtual) itself
3. Developer fixes any issues identified from inspection
4. Moderator verifies fixes
Which event counts as "done" depends on the purpose.  For example,
when the developer completes code, he or she is available to pick
up the next open task; so event 1 is "done" when working resource
scheduling.  At the other extreme, we use all 4 events (weighted
80%, 10%, 0%, and 10%, resp.) when determining earned value (EV).

Joe Vlietstra

Re: Code review practices

James Grenning — 2013-04-29T13:35:12

Here is an approach to reviews in a pair programming TDD environment that has worked well for some team I have worked with:

- trust the pair to apply the coding standards and to refactor
- review only the test cases
- if the pairing was done by two less experienced TDDers, review the code too.
- periodically run coverage check to see if any legacy code is being written

By reviewing just the test cases
- you lighten the review load
- you review the architecturally significant aspect of the design

Re: Code review practices

gustavonarea_tech — 2013-04-29T12:34:22

Where I work, we try to have another pair of eyes in everything we do, except for the occasional, trivial, no-brainer change.

We use one of the following approaches, depending on the task at hand:
- Pair programming.
- Solo development, with a design review prior to the implementation.
- Solo development, followed by a review of the implementation after the change has been committed to the repository.

When we do solo development, we normally use both design and implementation reviews.

We do pair programming when one of the following conditions is met:
- We want to transfer knowledge (e.g., about a library) from one participant to the other.
- The task will involve removing or changing code spread across multiple locations (since a single person may miss occurrences or not spot all the consequences).
- We need to add a new non-trivial component.

We do solo development when we think pair programming isn't worth it (as is the case with a minority of the tasks) or when we can't form a pair (and the developer

Yahooooooo!

jennifer ferreira — 2013-04-29T11:00:24

Single Mom Makes $89,844/Yr in Her Spare Time on The Computer Without Selling Anything 

http://www.e-bda.com/hwork56.html 



4/29/2013 12:00:12 PM



[Non-text portions of this message have been removed]

Re: Code review practices

Keith Ray — 2013-04-26T20:33:21

same book at publisher website:
http://www.dorsethouse.com/books/hdbk.html

see also:
http://www.geraldmweinberg.com/Site/Home.html

--
C. Keith Ray
* https://dl.dropbox.com/u/686328/keith_ray_resume.pdf
* http://agilesolutionspace.blogspot.com/

Re: Code review practices

Keith Ray — 2013-04-26T20:28:44

People not doing XP/TDD often do not review unit tests... even if they have them. 

If mandating code review, I would require reviewing both code and unit tests together.

Suggested reading (if not doing XP):

Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products  by Freedom & Weinberg

--
C. Keith Ray
* https://dl.dropbox.com/u/686328/keith_ray_resume.pdf
* http://agilesolutionspace.blogspot.com/

On 2013 Apr 26, at 4:33 AM, Charles Bradley - Professional Scrum Trainer and Coach <charles< at >scrumcrazy.com> wrote:




[Non-text portions of this message have been removed]

Re: Code review practices

Ian Mitchell — 2013-04-26T19:50:31

I think there are 2 extreme cases and many in between.
Checking an input form: There are many small edits such as the range of a
date plus checking that the mouse-over help does say the corresponding
thing, Code inspection works here. Time-consuming to test by repeated data
entry.
Indepth SQL interfaced code - test-driven design. Best to set up test case
data which can be repeatedly used..


On 26 April 2013 23:33, Charles Bradley - Professional Scrum Trainer and
Coach <charles< at >scrumcrazy.com> wrote:

Code review practices

Charles Bradley - Professional Scrum Trainer and Coach — 2013-04-26T11:33:08

Hi,

I'm trying to come up with a list of different ways of doing code reviews as they relate to a Scrum definition of done.

In practice, I've seen:

* A scheduled meeting for a code review, several show up and review code

* Paired Programming  (I realize XP'ers are biased to PP, and nothing wrong with that)

* Live review by one other programmer just before code commit.
* Code review published to code review system (like Atlassian Crucible, etc) with deadline by which reviewers can submit feedback.
* Code review published to code review system (like Atlassian Crucible, etc) 
where code cannot integrate until one person says "ship it"
* No code reviews
* Code reviews only on special occasions or in certain parts of the code
What other code review type practices have you seen?
 
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
ScrumCrazy.com

[Non-text portions of this message have been removed]

4th Brazilian Workshop on Agile Methods - Last Call for papers

Cÿffffe9lio Jÿfffffanior — 2013-04-22T18:30:06

4th Brazilian Workshop on Agile Methods (WBMA)

Agile Brazil'2013
http://www.agilebrazil.com/2013/en/wbma/
Brasilia, Brazil, 27/June/2013

Call for papers
===========

The Brazilian Workshop on Agile Methods (WBMA) is the research stage 
of the Agile Brazil Conference. It is an academic event on Agile software 
development. For this third edition, we hope to repeat the success of previous 
years, when the workshop received many papers and the participation of a 
large number of students, researchers, and professionals from all over World.
Last year, Agile Brazil (the event hosting WBMA) counted over 800 attendees 
from the whole world. This year the workshop expects to receive even more 
participants from Brazil and researchers and students from abroad, coming from 
top international universities and IT companies.

This year, WBMA will happen on June 27th in Brasilia, collocated with the 4th Agile Brazil.

The main topics of interest for this workshop are:

* Adoption of Agile / Lean
* Syst

Re: Re: Developer Stories

Phlip — 2013-04-20T14:51:35

Adam Sroka :

Team members helping to write stories, yes.
Technical team members contributing stories that the customer cannot fully
comprehend or prioritize, no.


JeffGrigg  wrote:


There are also Motherhood Stories. These can accrete, if nobody was
prescient enough to declare one up front...

Re: Developer Stories

JeffGrigg — 2013-04-20T08:33:32

Perhaps it would be helpful to ask questions like this:

Would anyone outside the development team care if the system is more or less maintainable in the near future? Would the people who will have to pay for it be interested? Would people who have to use it and would be denied features they need due to maintenance costs be interested?

Would anyone outside the development team care if the system is reliable? Would any of the people who use it like the system to reliably produce the expected results, in both the short and long term?

Sure, it's easy and common for <someone> to blame the developers (or the DBA, or operations, etc.) when something goes bad. But that does imply that "<someone>" cares. So it must impact them in some negative way.

Re: Developer Stories

JeffGrigg — 2013-04-20T08:10:30


--- Phlip <phlip2005< at >...> wrote:

It's nearly always good for developers to *suggest* stories that could be done. This is a human venture. We benefit from getting as many good ideas out there as possible. And the developers will have a good idea of what is possible and easy -- and which may provide value.

But the Customer determines the priorities. So your brilliant idea might be prioritized to "yes, let's do it now" or "no, let's do it 'never.'"