From: "Alain Ravet" <aravet@...>
>    > ..Each project contributes a list of tasks to the group.  Based
>    > on what you know about the projects you must then create the
>    > overall priority of the entire list of tasks.
>
> Practice sounds less simple than theory.
> As usual.

Yes, you have identified the hard part.  Everyone must be willing to listen
and understand the priorities of all the other projects.  You must be
willing to wait to get something done on your own project if another project
has greater need.  This is contrary to most things we are taught by life.

Don Wells

On Sun, 02 Dec 2001 09:40:47 -0000
"Alain Ravet" <aravet@...> wrote:

> In a few weeks, we will be facing this very problem :
>
>    --- In extremeprogramming@y..., alanh@m... wrote:
>    > One possible precondition .. is that the programmers should not
>    > be required to divide their time too much between various
>    > projects.
>    > It interferes with Pair Programming and The Planning Game.
>
>
> For reasons beyond this list scope, this is our daily working
> experience :
>       - n people working on n projects.
>       - 1 developer per project.
>       - for many months to 1 year.
>
>
>    After our current XP pilot project - 3 people, 1 project -, our 4
> man team will receive 4 new projects, to make succeed in 12-18 months.
>
> While some have a higher priority, they will all have to start
> officially on the 1th of January, and none can be inactive for too
> many months at a time (sounds like "frequent release").
>
We had a similar situation. In our case we had six people and up to three
projects. Having multiple projects was management's way of controlling
resource allocation across multiple customers with conflicting
requirements and priorities. It simply wasn't practical to get these
customers to agree on one set of tasks and one set of priorities.

We did planning in two stages. Prioritization of tasks was done with each
customer separately, with some subset of the development team included.
The subset might be one person, or multiples, and it changed from time to
time - whatever seemed reasonable at the time.

The development team had one planning meeting after the customer planning
meetings. The coach would put the top few stories for each customer on a
flip-chart as "this is what we've been asked to do next". People would
then sign-up and things went pretty much as you'd expect, with one
exception. This was the allocation of resources to each project. We tried
having pairs switch intra-day, but our experience was the context switch
across projects was too high. So we would allocate people to a project for
an iteration, with the proviso that a person couldn't work on a project
for more than two iterations in a row. This was to ensure that we didn't
end up with silos of expertise, and to ensure consistency across projects.
We used the same rules regardless of the number of projects.

There was some pressure to increase the number of projects. I resisted
this as much as I could, and we never went above one project per pair. I
believed (and still believe) that productivity would drop off quickly
after this, but I don't have proof. Oh, and our iterations were one week,
so resources could still be switched around quickly.

Steve Hayes

XP, Scrum, Crystal, FDD and DSDM are examples of agile marketing of
consultancy services. ;-)

ps. I think you have a typo there. Didn't you mean FUD and BDSM?

Sorry, I just couldn't resist, I crawl back into my box now... >:-)

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@...
New Zealand

Carter's Observation - "If a bug was really hard to find, you won't
know what to do with it when you do find it."

On Thu, 1 Nov 2001, Brian Christopher Robinson wrote:

> Has anyone attempted to create a programming language with refactoring
> specifically in mind?  I know I've noticed impediments to refactoring that
> are present in certain languages and I was wondering if anyone has tried to
> catalog these and create a language that omits them.

Sorry for the extremely late reply, but thats what you get if I play with
the sort facility in the Pine mailer...

Manfred von Thun's Joy
   http://www.latrobe.edu.au/philosophy/phimvt/joy.html

Wasn't created with that aim, but has certain properties that make it
nearly ideal.

It has the curious property that function composition === string
concatenation.

Thus refactoring in a sense is reduced to simple string operations.
   http://www.latrobe.edu.au/philosophy/phimvt/joy/j07rrs.html

And there is no name binding to complicate an algebra, resulting in the
existence of a quite remarkably simple algebra for Joy...
   http://www.latrobe.edu.au/philosophy/phimvt/joy/j04alg.html

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@...
New Zealand

Carter's Observation - "If a bug was really hard to find, you won't
know what to do with it when you do find it."

A friend and I have been working on an idea. Starting with Do The Simplest
Thing, and looking at Wiki's, we decided that if you could start out with a
wiki you could build a lot of most business applications. When you hit the
point you need more functionality, you drop a "widget" onto the page. That
is, you give a command that the wiki interprets by giving you access to some
arbitrarily complex piece of functionality. Many wikis extend the basic
functionality, but the additions end up in the interface, so the wiki
becomes more and more complicated. By extending the wiki with widgets, we
hope to preserve a basic, simple wiki and still be able to extend it in many
directions. As a strategy this would fit in with building applications a
little functionality at a time. It would also fit well with building
"families" of applications.

I mention the idea here because it grew out of our work with extreme
programming and is not shaping our future direction. www.SeedWiki.com for
examples.

Thanks
Kenneth Tyler www.tinyxp.com berkeley, ca

> I mention the idea here because it grew out of our work with extreme
> programming and is not shaping our future direction. www.SeedWiki.com for
> examples.

Are you familiar with Zope?

--
   Phlip                          phlip_cpp@...
         http://www.greencheese.org/PeaceAndCalm
   --  Creationism: The belief that God is too stupid to be able
       to invent a Universe where life can spontaneously arise  --

I am interested to do my research in xp. Where can I
find article related to  hardcore research issues
Thank you
vivek


__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

> Are you familiar with Zope?
>
Philip,
     I have looked at Zope, maybe I didn't look hard enough. It looked to me
a lot more like programming than using a wiki...what did you have in mind ?
Kenneth Tyler

>     I have looked at Zope, maybe I didn't look hard enough. It looked to me
> a lot more like programming than using a wiki...what did you have in mind ?

Nothin'. I didn't look at it more than you.

All I know is that given...

	 http://www.greed.com/meat/pork/spam

...that meat pork and spam are all Python classes in an inheritance
heirarchy. Trick.

The Zope wiki, ZWiki, I think has a mode where end-users can author Zopeness
straight into the pages. The docs describe this as "the serengeti of Wikis".

--
   Phlip                          phlip_cpp@...
    http://www.greencheese.org/EvolutionaryPsychology
   --  All sensors report Patti having a very good time  --

Regards

                                         Todd Wang(Ext:296)



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

--- In extremeprogramming@y..., C & C Helck <pp002531@m...> wrote:
> It would give me a nice warm and fuzzy feeling if
> JUnit could create a screen and compare it to a known good image.
Any ideas?
>
> -Christopher

java.awt.Robot
(http://java.sun.com/j2se/1.3/docs/api/java/awt/Robot.html) may be
useful.

"This class is used to generate native system input events for the
purposes of test automation, self-running demos, and other
applications where control of the mouse and keyboard is needed. The
primary purpose of Robot is to facilitate automated testing of Java
platform implementations.

Using the class to generate input events differs from posting events
to the AWT event queue or AWT components in that the events are
generated in the platform's native input queue. For example,
Robot.mouseMove will actually move the mouse cursor instead of just
generating mouse move events."

J. B. Rainsberger made a strange utterance something like this:
>I think you're both missing one point: "scream" is what I said when I
>vocalized what I wanted the system to do. Surely a name that aligns so
>closely with exactly what I wanted to do at the time is worth something!

If I followed that advice all my methods would be variations of "iDunno" or
"itsHardToExplain".  Fortunately, I usually sit for a minute and figure out
a better name than my first vocalization.


--
"The best programmers that I have ever met have an amazing ability to make
nasty sh*t disappear. *Poof*" Gareth Reeves -- reevesg@...

John Carter made a strange utterance something like this:
>Manfred von Thun's Joy
>   http://www.latrobe.edu.au/philosophy/phimvt/joy.html
>
>Wasn't created with that aim, but has certain properties that make it
>nearly ideal.

Quite interesting.  It reminds me a lot of Forth.  I can see where
refactoring would be easy in this language.  However, along with improving
design one of the reasons for refactoring is improving readability of
code.  I have serious doubts that any non infix language can attain greater
readability than an infix language.


--
"The best programmers that I have ever met have an amazing ability to make
nasty sh*t disappear. *Poof*" Gareth Reeves -- reevesg@...

My guarantee, as an employee and representative of my firm, is that if I
fail, my *company* won't take your money.

Yes, I have the authority to make that statement and stick to it.

Even if I weren't talking to an external customer, that would mean that the
budget expenditure for any development that fails comes from my bucket, not
theirs.

> -----Original Message-----
> From: Dale Emery [mailto:dale@...]
> Sent: Thursday, November 29, 2001 6:27 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] FAQ: Preconditions for using XP?
>
>
> Hi JB,
>
> > >What does "guarantee" mean here?
> >
> > For me, "guarantee" means "if I fail, you can yell at me, then you
> > can fire me. No regrets." Could it mean anything else in this
> > context?
>
> To me, a guarantee must somehow limit the customer's risk, often by
> compensating for non-delivery.  "If I fail, you can fire me, no
> regrets," is a statement of confidence, but it seems weak as a
> guarantee, because the customer already has the right to fire
> you, and
> is under no obligation to regret it.
>
> When I was consulting, I had a guarantee: if you don't like my work,
> don't pay the invoice.  That limited the customer's risk.
>
> If Steve is an employee, the "I won't take your money" guarantee
> doesn't work.
>
> Dale
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

>
> Aha. I was still thinking in the skin of a full-timer. In
> that context,
> it's a pretty good guarantee, because they can't fire me
> without really
> good cause. Lawsuits and all. :)

I work in an "At will" state.  They can fire me just 'cuz they don't like
me.

>
> I'm still learning to think like a contractor. Bear with me.
>
> Incidentally, I could never guarantee success without objective
> acceptance criteria: it would be too easy for the client to beg off
> paying otherwise. I assume you meant that. In that case, I could make
> this guarantee:

The acceptance criteria is a given, in my opinion.  I make the "guarantee"
in question for each iteration.  Reasonable Person rule always applies for
the first few iterations.

I also think we are getting into a slightly different realm than my original
post intended.  When I said that the answer to "Will you guarantee this will
work?" must be yes, I really meant it in convincing the upper upper
management to let me do XP.  In that sense, my guarantee falls more into the
"then fire me" line.  Of course I was wacked out on codeine at the time, so
I might not have been particularly clear.  ;-)

Sir/ Madam

I am interested to take up research in extreme
programming. Can you suggest some research issues,
problems or good articles
thanking you
vivek

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

Hi JB,

> Incidentally, I could never guarantee success without objective
> acceptance criteria: it would be too easy for the client to beg off
> paying otherwise. I assume you meant that.

No, I didn't require objective acceptance criteria.  My measure was
the customer's happiness when the work was done.

Offering this guarantee encouraged me to understand continually what
the customer wanted, to define frequent milestones (at which I'd
submit an invoice), and to ask for frequent feedback.

Dale

We are now starting on the next phase of our developed with a reorganized
team and a manager who is open to more XP practices (with 18 developers, I
don't know if we are going to be allowed to go full XP, but I am
trying).  One topic at our last meeting was the two types of tests. I found
that people were really confused by the XP definition of unit tests vs
acceptance tests discussed long ago, roughly:

"Unit tests are test written by developers to verify that their code works
as they intended"
"Acceptance tests are defined by the customer to verify that the system
meets the requirements"

The confusion stemmed from the more common use of "unit test" to mean "a
test written to test a single code unit" so the team preferred the name
"baseline test" for the developer-defined ones.  Upon further discussion, I
realized that it really gives a better sense of the purpose; and makes it
easier to explain an XP goal - that the baseline tests be small and fast so
that they can provide adequate coverage in a short period of time. To do
this, we recognize that it is not the case that baseline tests *are* unit
tests (that is, we should not redefine what a unit test is), but rather
that baseline tests *should be* unit tests.  To summarize, we have two axes
of tests:

Purpose
------------
Baseline test - a test defined by developers as they work to ensure that
their code works as they intend
Acceptance test - a test defined by customers to verify requirements
compliance and product acceptability

Technique
-------------
Unit test - a test written to verify the behavior of a particular piece of
code - often white or gray box
Functional test - a test written to verify the behavior of the entire
system - almost always black box


Baseline tests should (almost) always be unit tests.
Acceptance tests should (almost) always be functional tests.

Russell Gold wrote:

> To summarize, we have two axes of tests:
>
> Purpose
> ------------
> Baseline test - a test defined by developers as they work to
> ensure that their code works as they intend
> Acceptance test - a test defined by customers to verify requirements
> compliance and product acceptability
>
> Technique
> -------------
> Unit test - a test written to verify the behavior of a particular
> piece of code - often white or gray box
> Functional test - a test written to verify the behavior of the
> entire system - almost always black box
>
> Baseline tests should (almost) always be unit tests.
> Acceptance tests should (almost) always be functional tests.

This is exactly the clarification I was hoping for when I posted about
acceptance vs. integration vs. unit tests a few days ago. Would
"functional" tests be equivalent to the "integration" tests? It seems
like they're referring to the same thing in the same way.

I think this distinction has been slippery because the term "unit
test" makes sense on both of the axes mentioned, while the term
"acceptance test" doesn't really describe technique.

Also, using the replies I've gotten to interpret the Literature, it
sounds like acceptance tests are a sort of secondary suite of outer,
high-level tests that are used more as a final checklist of correct
behaviors than a must-always-run test suite.

Given that "unit test" is a commonly-used term for both axes, it seems
like a definition of the technique of acceptance testing would be all
we need to clarify the issue. I'm not trying to diminish the
importance of the purpose/technique distinction, but there are some
shades of gray here that would be less confusing to deal with if the
only distinction XP made was between unit and acceptance testing.

This is my best guess. I'm probing here, I may be making some
incorrect assumptions.

--
John Platte
johnplatte@...

Back when clock rates were not so high, we'd incrementally
develop boards using wire-wrap before committing to a PC card.
Even now, it seems that you can produce lab PC cards pretty
quickly and evolve the design using an xacto knife and jumpers.

  - George [who's even built 3-dimensional circuits with no
            board for a short-term hardware "spike."]

> -----Original Message-----
> From: Russel Hill
>
> I am currently working on a project where hardware
> development plays a large role.  I am interested in hearing
> from anyone who has experience with XP in a combined HW/SW
> development..
>
> The portion of the HW development that involves PC board
> layout has constraints that pose challenges agile processes.
> At a few thousand dollars and a few weeks per iteration of a
> PC board, there are compelling reasons for a larger portion
> of DUF than we are used too.  However, once the board layout
> is proven, it seems like ASIC or FPGA design could enjoy a
> development cycle similar to software development (but not
> quite identical). I'm not even certain that a FPGA
> configuration isn't software since it's a binary file which
> is loaded at run-time.
>
> Does anyone have experience with XP (or other agile
> processes) used for (or in conjunction with) hardware development?

>From: John Carter [mailto:john.carter@...]
>Answer 3 - Read http://www.iso.ch, nah, on the other hand don't bother...
>that stuff has nothing to do with quality, soft or otherwise.

Actually, I like the ISO 9167 quality attribute list.
Excellent committee work.
Six main categories and 20 subcategories cover pretty
much everything and is a cold shower for those who think
that being bug free is all you can achieve.

functionality:
- suitability
- accuracy
- security
- interoperability

reliability:
- maturity
- fault-tolerance
- recoverability

usability:
- understandability
- learnability
- operability

efficiency:
- time behavior
- resource behavior

maintainability:
- analyzeability
- changeability
- stability
- testability

portability:
- adaptability
- installability
- conformance
- replaceability

Hi Kari,

> Actually, I like the ISO 9167 quality attribute list.

There are also two other lists I like.  First is the SEI's "Quality
Attributes" (
http://www.sei.cmu.edu/publications/documents/95.reports/95.tr.021.htm
l ).

Second Tom Gilb's book Principles of Software Engineering Management.
  Gilb defines a number of quality attributes, and defines tests for
many attributes.  He offers a framework for defining tests for any
quality attribute (scale, units, planned level, current level, best
level achieved elsewhere, ...).

Dale

I would think you could, since it just generates Java objects with
very standardized names.  Knowing that, you could sort of "test
first".

Gary

--- In extremeprogramming@y..., Phlip <pplumlee@c...> wrote:
> On Tuesday 27 November 2001 06:35, you wrote:
> > Has anyone on the list had experience using VERSATA, the JAVA
code-
> > generator, with XP?
>
> I saw a pseudo-technical demo on it once.
>
> I kind'a annoyed them with questions they felt were out of no-
where. Like
> "how would you write a Unit Test for that?"
>
> --
>   Phlip                          phlip_cpp@y...
>                http://www.c2.com/cgi/wiki?PhlIp
>   --  In business always remember:
>       The customer is always funny!  --

I would think you could, since it just generates Java objects with
very standardized names.  Knowing that, you could sort of "test
first".

Gary

--- In extremeprogramming@y..., Phlip <pplumlee@c...> wrote:
> On Tuesday 27 November 2001 06:35, you wrote:
> > Has anyone on the list had experience using VERSATA, the JAVA
code-
> > generator, with XP?
>
> I saw a pseudo-technical demo on it once.
>
> I kind'a annoyed them with questions they felt were out of no-
where. Like
> "how would you write a Unit Test for that?"
>
> --
>   Phlip                          phlip_cpp@y...
>                http://www.c2.com/cgi/wiki?PhlIp
>   --  In business always remember:
>       The customer is always funny!  --

No, because most of them aren't close enough to Australia.  We'll
just ask you to do it.  You can email us the head. ;-)

> -----Original Message-----
> From: Bryan Dollery [mailto:Bryan.Dollery@...]
> Sent: Saturday, December 01, 2001 7:25 AM
> To: extremeprogramming@yahoogroups.com
> Subject: RE: [XP] Jireh Mak/Australia/IBM is out of the office.
>
>
> Jireh Mak automatically replied
> > Sent: 01 December 2001 13:16
> > To: extremeprogramming@yahoogroups.com
> > Subject: [XP] Jireh Mak/Australia/IBM is out of the office.
> >
> >
> > I will be out of the office starting November 30, 2001 and
> will not return
> > until January 2, 2002.
> >
>
> At which point he will be summarily executed by about 2000
> pissed off XPers.
>
> -B ;)
>
> b r y a n   d o l l e r y | c e o
>     c h a o s   e n g i n e e r s
>                  +64 (0)21 330607
>   http://www.ChaosEngineers.co.nz
>
> The difference between me and the other surrealists is that I'm a
> surrealist.
>       - Dali
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

"Say" what to whom?  I think "say" and "scream" are too non-specific
once you get outside the context of the moment.  Of course,
displayInformationalMessage suffers the same fault; it's just more
verbose.  So, what are you really trying to do?  Do you want to
informUserOfUserError, informUserOfSystemError, informUserOfPossibleError,
informUserOfSignificantEvent...?

  - George

> -----Original Message-----
> From: J. B. Rainsberger [mailto:jbr@...]
> Sent: Saturday, December 01, 2001 10:17 AM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] How to name variables
>
>
> Mike:
>
> I was thinking of "warn" for warnings and "say" for anything
> that didn't
> have a special severity. I guess those would be
> informational. I admit,
> "scream" is maybe not right, but it's close to what I'm
> trying to get at.
>
> If it's displayInformationalMessage() and later we change the
> severity
> from INFORMATION to some synonym, we will probably want to change the
> method to displayWhateverTheSynonymIsMessage(). But if the method is
> "say", then we won't likely want to change it. That helps refactoring
> *and* communicates... win-win. :)
>
> JBr.
>
> Mike Bowler wrote:
>
> >
> > >> I *do* find the name scream() amusing but I don't feel that it
> > >> communicates well.
> >
> > > But does it increase the odds that you (and also alternatively
> >advantaged
> > > people on your team) will remember it?
> >
> >Perhaps it's just too early in the morning but I'm not sure what you
> >mean by "alternatively advantaged".
> >
> >If this was the only method that was named in this fashion
> then perhaps
> >it would help us remember.  Since it's a commonly used method, the
> >amusing name might help.
> >
> >On the other hand, if we take this to it's logical extreme
> then would
> >logging a warning be shout() and logging an informational message be
> >whisper()?  If so, then I think it's unlikely that I would
> remember all
> >the special names.  If they were called displayErrorMessage(),
> >displayWarningMessage() and displayInformationalMessage()
> then I'm sure
> >that even if I forgot the name, I'd be able to deduce it
> quickly.  Not
> >so with scream(), shout() and whisper().
> >
> >If we have named our methods well then it should not be
> neccessary to
> >"remember" any of them.  We should be able to deduce the
> method names
> >from the actions that we wish to perform.
> >
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

On Monday 03 December 2001 13:00, you wrote:
> I would think you could, since it just generates Java objects with
> very standardized names.  Knowing that, you could sort of "test
> first".

Because they were demoing their massive code generator (which essentially
solves OAOO by introducing a new language from which intermediate code got
pasted into the HTML, Java & SQL objects), they seemed to take my requests
for unit tests to mean "how do I test that your code generator did not screw
up."

Like Kent sez, if our tools were themselves built test-first we would not
constantly have these dumb mismatches.

--
   Phlip                          phlip_cpp@y...
                http://flea.sourceforge.net
   --  In business always remember:
       The customer is always funny!  --

Hi Kenneth,

Have you seen everything?

When I took a quick look at it at: http://everydevel.com/, it looked similar
to a wiki site where rather than just having pages, you can have different
page types (called nodes), which can then have different behaviour built
into them with Perl. So basically you have a wiki where you can imbed not
only text, but also Perl "scriptlets" that can then do stuff.

By making packages of nodes, you can then start to get applications out of
the whole thing. If you look under "nodeballs" you can see the different
packaged sets of nodes that have been made to do various apps (task list,
schedule, etc).

The concepts look interesting, but I just haven't had the time do much but
browse.

Derek.


-----Original Message-----
From: Kenneth Tyler [mailto:kentyler@...]
Sent: Sunday, December 02, 2001 10:26 PM
To: extremeprogramming@yahoogroups.com
Subject: [XP] Wikis With Widgets


A friend and I have been working on an idea. Starting with Do The Simplest
Thing, and looking at Wiki's, we decided that if you could start out with a
wiki you could build a lot of most business applications. When you hit the
point you need more functionality, you drop a "widget" onto the page. That
is, you give a command that the wiki interprets by giving you access to some
arbitrarily complex piece of functionality. Many wikis extend the basic
functionality, but the additions end up in the interface, so the wiki
becomes more and more complicated. By extending the wiki with widgets, we
hope to preserve a basic, simple wiki and still be able to extend it in many
directions. As a strategy this would fit in with building applications a
little functionality at a time. It would also fit well with building
"families" of applications.

I mention the idea here because it grew out of our work with extreme
programming and is not shaping our future direction. www.SeedWiki.com for
examples.

Thanks
Kenneth Tyler www.tinyxp.com berkeley, ca




To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


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

On Mon, 3 Dec 2001, Kari Hoijarvi wrote:

> >From: John Carter [mailto:john.carter@...]
> >Answer 3 - Read http://www.iso.ch, nah, on the other hand don't bother...
> >that stuff has nothing to do with quality, soft or otherwise.
>
> Actually, I like the ISO 9167 quality attribute list.
> Excellent committee work.

I agree without reservation about the attributes they list, but the
process and audit heavy monsters they create in the
name of Quality inhibit rather than create quality.

Quality software is created by programmer with a text editor open on the
program source in front of him. Any process that decreases the amount of
time the programmer spends in that mode must necessarily have a
detrimental effect. It may have other beneficial effects, but it must
always also have a detrimental effect.

Thus a dynamic balance exists, processes that hopefully will have some
benificient effect, but takes the programmer away from the source code
which _is_ the program.

Like any good mathematician, lets consider the limits...

At one end of the scale, the programmer spends no time in front of the
source code, nothing gets written. That is clearly wrong.

At the other end, the programmer spends full time coding, and never shifts
his eyes to process documents and meetings etc. etc.

Clearly this end isn't all bad, because you at least have a program coming
out the end of it, may be cruddy quality, but at least its a program.
Perhaps not with all those desirable attributes, but it is at least a
program.

So we have a judgement call. What level of ISOish ceremony do we need to
create Quality software?

Cosmically speaking it's a personal judgement call.

My personal judgement is that no amount of process and ceremony will
create Quality. At best we can choose quality programmers and make them
aware of the issues. If you have quality aware quality programmers, then
taking them away from their tasks will merely decrease the limited time
they have to create quality.

If the programmers you have do not give a shit about quality, or the
programmers that have no understanding of software quality, then no amount
of process will drum it into the code. Since the process puts nothing into
the code, only the coders do.

This is why I like XP. It decreases the ceremony, it grants programmers
the right to create quality code, and gives (via tests and customer
interactions) and short iterations suitable high feedback measures to keep
the programmers eyes on the quality. It also provides high interaction
amongst team members so that concepts of quality spread rapidly and
pragmatically within the group.

What you find is the quality programmers create what ceremony they need to
create quality. At that point they may find it useful to lightly peruse
the ISO documents for predigested ideas on ceremony.

> Six main categories and 20 subcategories cover pretty
> much everything and is a cold shower for those who think
> that being bug free is all you can achieve.
>
> functionality:
> - suitability
> - accuracy
> - security
> - interoperability
>
> reliability:
> - maturity
> - fault-tolerance
> - recoverability
>
> usability:
> - understandability
> - learnability
> - operability
>
> efficiency:
> - time behavior
> - resource behavior
>
> maintainability:
> - analyzeability
> - changeability
> - stability
> - testability
>
> portability:
> - adaptability
> - installability
> - conformance
> - replaceability

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@...
New Zealand

Carter's Observation - "If a bug was really hard to find, you won't
know what to do with it when you do find it."

> > usability:
> > - understandability
> > - learnability
> > - operability
> >
> > efficiency:
> > - time behavior
> > - resource behavior
> >
> > maintainability:
> > - analyzeability
> > - changeability
> > - stability
> > - testability
> >
> > portability:
> > - adaptability
> > - installability
> > - conformance
> > - replaceability

Every one of these "ility" words is an attempt to predict the future. When
we install are we bug free? When we adapt are we bug free? When we replace
are we bug free?

"The best way to predict the future is to invent it" --Alan Kay

--
   Phlip                          phlip_cpp@...
            http://flea.sourceforge.net
   --  Have a :-) day  --