headers
bena | 1 Jul 2005 01:02
Picon

Re: Software development without pairing?


I don't know that I said "measure everything you can".  I hope I said 
"look at".  That is, look for sources of information that gives you 
visibility into whatever it is that troubles you.

I use measurements when I have a problem and my usual experience is that 
finding the right measurement exposes the root cause and allows it to be 
fixed, making the measurement useless. 

For example, I had $THING which would sometimes run and sometimes not.  I 
set up a script to run $THING regularly, and complain loudly if it didn't 
work.  I soon saw that doing $OTHER_THING was always followed by screams 
of complaint from the script.  Although $OTHER_THING worked, it was 
corrupting some data $THING depended on.  $OTHER_THING was changed, the 
problems with $THING went away and the script had no further value.

> This means deciding what the problems are 
> first, then picking metrics that help us understand those problems, and 
> only *then* measuring -- not the other way round.

I'd suggest both.  There's not much worse than a person with a solution 
desperately looking for a problem to apply it to.  But sometimes, when you 
hear of a solution, you realise it solves a problem you didn't realise you 
had.

        Regards, Ben

William E Caputo <wecaputo <at> thoughtworks.com>
Sent by: extremeprogramming <at> yahoogroups.com
30/06/2005 00:15
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brad Appleton | 1 Jul 2005 05:16

Re: Re: Use of "Literate" Wiki or Fit/Fitnesse for stories + tests + code?

Thanks Jeff!
Im pretty sure it wasnt Ward's WikiBase and was something much more
recent (in the past 5 years).

Jeff Grigg wrote:
> --- Brad Appleton <bradpro <at> b...> wrote:
> 
>>I heard about someone doing this somewhere but dont remember
>>the details and was hoping someone here might remember or
>>have an example/story ...
>>
>>I seem to recall someone maintaining they were using some
>>kind of Wiki implementation (possibly with Fit or Fitnesse)
>>to do a sort of Wiki-style of Literate Programming:
> 
> 
>>* Somehow their Wiki pages could easily take code snippets
>>  inside of "code" markup tags, with some optional directive
>>  regarding the file name/location in which to store the code.
> 
> 
>>* They could use WikiWords to add hyperlinks to other wiki
>>  pages, and took advantage of this feature in their coding
>>  convention's so that names of methods, classes, and certain
>>  other things would automatically show up as wiki-links
>>  to wiki-pages
>>* The result was a fully "literate" hyperlinked Wiki with
>>  links from stories/tasks to tests to code
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Shore | 1 Jul 2005 07:31

New article: "Ideas," not "Requirements"

"I've been working with a customer to help them define a custom agile 
process. One of the first things I've been doing is looking at where 
software requirements come from and how they're prioritized."

Find my new article at 
http://www.jamesshore.com/Blog/Ideas_Not_Requirements.html.

Cheers,
Jim

-- 
James Shore - Titanium I.T. LLC - Successful Software

phone: 503-267-5490
email: jshore <at> titanium-it.com
web/blog: http://www.jamesshore.com

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 7 comments |
headers
Dominic Williams | 1 Jul 2005 09:30

Re: New article: "Ideas," not "Requirements"

Hi Jim,

I agree that using the word "requirements" is
inappropriate in an XP context. "User story" is a vast
improvement, but I really like your suggestion to use
the word "idea", because it is less definitive than
user story, and as you say in the article, anyone can
have an idea.

One problem is see with it is that one can also have
"ideas" about the code, about the process... just like
a story can be about anything, which may be why Kent (I
presume) prepended the word "user".

I still find myself using the word "feature" when I need
to make it clear I'm talking about what the software
does.

Ideally, I'd like a word that merged all the qualities
of idea, user story and feature... In the meantime,
I'll definitely try "idea" in some circumstances.

Thanks,

Dominic Williams
http://www.dominicwilliams.net

----

To Post a message, send it to:   extremeprogramming <at> eGroups.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Clark, David | 1 Jul 2005 10:00
Picon
Picon
Favicon

RE: KISS

Firstly thank you to all who responded to my posting on a simplicty measure.
Several valid and useful points were made. Rather than respond to them all individually, I will put several
responses in the one posting.

Firstly let me remind you that these are beginning students. Some have no experience in programming when
they start. This is just their first semester of a 3 year degree. Their assignments are small, but can be
challenging for them. 

Maintainability
Some suggested that there should be an emphasis on maintainability.
I totally agree with this, and there is. It is one of Bertrand Meyer's "External" quality factors. Things
like simplicity, names, constants, etc are "internal" quality factors which help support the external
ones. Emphasising these helps push the students in the right direction.

The measure is simplistic
I agree. But it is transparent and accessible to the students. It won't take them very far, but I do think it
will help at their level.

The four XP rules of simplicity:
	1) Runs all the tests
	2) Reveals all the intention.
	3) No duplication.
	4) Fewest number of classes or methods or functions.
Thank you for reminding me of this. I will use it.
But in the context of my subject, a low count on the simplicity measure will help with 2) 3) and 4). And as for
1), if a student's assignments do not pass all my tests it has to be fixed it up and resubmitted.

Consensus marking
An idea I like very much, but difficult to implement. The assignments are a bit too complex and the solutions
so varied and the students too inexperienced for it to be viable. However I do get students to vote on
(Continue reading)

Permalink | Reply | 18 comments |
headers
Charlie Poole | 1 Jul 2005 11:34
Favicon

RE: Who's going to Agile2005?

Hi Mike,

> BTW, just got back from XP2005 and it was great.

Wasn't it just! I had a great time and learned a lot. Could have used
more sleep, but then that was my own choice.

Next year, we'll be in Finland with 24 yours of daylight and probably
even less sleep, but it sounds pretty exciting.

Charlie

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
Willem Bogaerts | 1 Jul 2005 11:56
Picon
Favicon

Re: New article: "Ideas," not "Requirements"

When I look at the software as a tool, the word "use" (as a noun) comes 
to mind.
For instance, the uses of a welding torch are welding, cutting, heat 
treatment, etc.
However, these uses are generally not fine-grained. The use of a word 
processor might be to layout a text, but few people would say that 
saving a document is a use of a word processor.

Best regards,
Willem Bogaerts

Dominic Williams wrote:
> Hi Jim,
> 
> I agree that using the word "requirements" is
> inappropriate in an XP context. "User story" is a vast
> improvement, but I really like your suggestion to use
> the word "idea", because it is less definitive than
> user story, and as you say in the article, anyone can
> have an idea.
> 
> One problem is see with it is that one can also have
> "ideas" about the code, about the process... just like
> a story can be about anything, which may be why Kent (I
> presume) prepended the word "user".
> 
> I still find myself using the word "feature" when I need
> to make it clear I'm talking about what the software
> does.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 1 Jul 2005 14:26
Favicon

Re: KISS

On Friday, July 1, 2005, at 4:00:33 AM, Clark, David wrote:

> Firstly thank you to all who responded to my posting on a
> simplicty measure. Several valid and useful points were made.
> Rather than respond to them all individually, I will put several
> responses in the one posting.

Cool. Your time permitting, I have a feeling that there's more to
learn from this topic.

> Firstly let me remind you that these are beginning students. Some
> have no experience in programming when they start. This is just
> their first semester of a 3 year degree. Their assignments are
> small, but can be challenging for them.

Yes ... this makes it important to set these students on the right
path. While whatever is done needs to be simple, it seems to me that
it is at least equally important that it should be right. Simple,
but right.

> Maintainability

> Some suggested that there should be an emphasis on
> maintainability. I totally agree with this, and there is. It is
> one of Bertrand Meyer's "External" quality factors. Things like
> simplicity, names, constants, etc are "internal" quality factors
> which help support the external ones. Emphasising these helps push
> the students in the right direction.

Yes. Those are important. The sooner we begin to teach them
(Continue reading)

Permalink | Reply | 16 comments |
headers
Jeff Grigg | 1 Jul 2005 15:06
Favicon
Gravatar

Re: New article: "Ideas," not "Requirements"

--- Jim Shore <jshore <at> t...> wrote:
> "I've been working with a customer to help them define a
> custom agile process. One of the first things I've been
> doing is looking at where software requirements come from
> and how they're prioritized."
> 
> Find my new article at 
> http://www.jamesshore.com/Blog/Ideas_Not_Requirements.html.

I've been challenging the word "requirements" too.  "How can you say 
that this thing is a *REQUIREMENT*, when the business is doing just 
fine right now without it?  In what sense is is objectively 
required???"

"Ideas."  Now there's a nice idea.  ;->  One possible shortcoming, 
however:  I'm looking for ideas that people are willing to *pay* 
for.  "Hey, I have an idea!" I say, "We could paint the house 
pink."  However, nobody really wants the house to be pink.  So 
something's missing there.

I think that the things masquerading as "requirements" today aren't 
really requirements.  They are (hopefully) things that people want 
enough to pay for them.  If I'm implementing things that no one 
wants enough to be willing to pay for them, then I think that 
someone is misusing someone else's money.  :-[

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com
(Continue reading)

Permalink | Reply | 4 comments |
headers
Victor | 1 Jul 2005 15:42
Picon

Re: KISS

This thread has been quite comprehensive, yet there is one more angle worth
considering.

Because grading has a subjective component, I would have a conversation with
a few art/literature/soft sciences teachers about how they grade works with
subjective components.  More than one teacher because you may find as many
opinions as people interviewed.  Some may have good ideas.

Victor

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |

Gmane