Does anyone have a resource that describes the high-level goals of a
methodology? My best stab which is based loosely on other texts
(because the goal hasn't been explicitly defined) is more high level
and from the viewpoint of the business: "the goal of a methodology is
to enable the organization to develop software faster, better, and
cheaper."

I don't believe this definition of the goal is out of line with any
known methodology; does anyone not agree or does someone have a
document where this is defined? Am I being presumptuous for defining
the goal because perhaps a methodology designer has another goal in
mind (although I can't imagine what that would be)?

Obviously what differs between methodologies is the path they have
chosen to reach the goal. I am not arguing the details of
methodologies here, just that they are all designed with the hope of
developing software better, cheaper, and faster as opposed to worse,
more expensive, and slower.

Thanks,

MethodMan

From:	Randy Mathis
Subject:	Re: Methodology Goals
Date:	Tue, 18 Jan 2005 08:34:09 -0800

"It is the essence of the methodology as a opposed to a method or
technique - that it offers a set of guidelines or principles which in any
specific instance can be tailored to both the characteristics of the
situation in which it is to be applied and to the people using the
approach... such is the variety of human problem situations that no would-be
problem solving approach could be reduced to a standard formula and still
manage to engage the richness of a particular situation". Checkland Peter.
Softsystem Methodology. Rational Analysis for a Problematic World. 1989.

"MethodMan" wrote in message
news:1105990607.685456.249280@c13g2000cwb.googlegroups.com...
> Does anyone have a resource that describes the high-level goals of a
> methodology? My best stab which is based loosely on other texts
> (because the goal hasn't been explicitly defined) is more high level
> and from the viewpoint of the business: "the goal of a methodology is
> to enable the organization to develop software faster, better, and
> cheaper."
>
> I don't believe this definition of the goal is out of line with any
> known methodology; does anyone not agree or does someone have a
> document where this is defined? Am I being presumptuous for defining
> the goal because perhaps a methodology designer has another goal in
> mind (although I can't imagine what that would be)?
>
> Obviously what differs between methodologies is the path they have
> chosen to reach the goal. I am not arguing the details of
> methodologies here, just that they are all designed with the hope of
> developing software better, cheaper, and faster as opposed to worse,
> more expensive, and slower.
>
> Thanks,
>
> MethodMan
>

From:	Traveler
Subject:	Re: Methodology Goals
Date:	Tue, 18 Jan 2005 12:05:46 -0500

In article , "Randy Mathis"
wrote:

>"It is the essence of the methodology as a opposed to a method or
>technique - that it offers a set of guidelines or principles which in any
>specific instance can be tailored to both the characteristics of the
>situation in which it is to be applied and to the people using the
>approach... such is the variety of human problem situations that no would-be
>problem solving approach could be reduced to a standard formula and still
>manage to engage the richness of a particular situation". Checkland Peter.
>Softsystem Methodology. Rational Analysis for a Problematic World. 1989.

It is precisely because of this type of attitude that we are in a
chronic software reliability and productivity crisis. Currently there
exist hundreds of programming languages, operating systems and
development tools competing against one another, not counting custom
proprietary technologies. A veritable tower of Babel. Worse, the
complexity of many of the tools is often greater than that of the
applications themselves. Becoming proficient in their use often
requires years of training and experience. This is a sign of the
chronic immaturity of the software industry. Software engineering will
not come of age until a single software construction and execution
model is universally adopted.

To use the terminology of this thread, unless we come up with a single
universal methodology of computing (i.e., the correct way of doing
things, regardless of "situations"), we will continue to be in the
same sorry mess that we are in. It is about time that the computer
science community wake up from its stupor and realize that there is a
fundamental flaw in its approach to software construction.

Louis Savain

The Silver Bullet or How to Solve the Software Crisis:
http://users.adelphia.net/~lilavois/Cosas/Reliability.htm

From:	MethodMan
Subject:	Re: Methodology Goals
Date:	17 Jan 2005 19:05:38 -0800

<<"If the methodology cannot deliver predictability, then anything else
it
CLAIMS to deliver is indistinguishable from hype.">>

That is exactly correct; I agree 100%. My view is that predictability
is one of the ways we achieve the goal of "faster, better, cheaper.".
Predictability is how we replicate success and avoid repeating
failures. I personally believe that you should adapt a methodology to
your business and even further refine it to your project, which is why
I am not excited about cookie-cutter methodologies. My view is that
one size does not fit all, although I do like many of the practices and
processes defined in these newer methodologies. I would rather produce
a framework than a recipe book so that businesses have more control
over their process.

<revolve around either some sort of theoretical elegance or some small
number
of bugs. But quality is whatever the customer defines it to be. As
developers we don't get to define quality. >>

Yes, I use the term "Quality" to describe something more than just a
lack of defects. At a high-level quality could even include, like you
said, if the solution meets the customer's requirements. In practice I
might choose a different term to describe delivering what the customer
wants (instead of quality) just to avoid confusion because most people
think of bugs and defects when they think quality. But for the
purposes of defining the goal I wanted to keep terms more abstract
which is why I used the term quality in a more inclusive way as you do.
Thanks for the input! I think you have made some important points.

From:	xpyttl
Subject:	Re: Methodology Goals
Date:	Tue, 18 Jan 2005 09:38:14 -0500

"MethodMan" wrote in message
news:1106017538.585904.202200@c13g2000cwb.googlegroups.com...

> I personally believe that you should adapt a methodology to
> your business and even further refine it to your project, which is why
> I am not excited about cookie-cutter methodologies.

There is an interesting quirk about programmers. They will resist any
methodology as long as they can. Every programmer seems to firmly believe
that he knows better than any other, and his immediate solution will always
be better than the wisdom collected in a methodology.

But once he turns the corner and accepts that he will have to follow the
methodology, then he seems to want to follow it blindly. The methodology
becomes an excuse to leave common sense at home.

I really hate the terms, "follow the methodology" and "fill out the
deliverable". I would rather leverage the methodology, and exploit its
deliverables.

...

From:	Juhan Leemet
Subject:	Re: Methodology Goals
Date:	Tue, 18 Jan 2005 14:54:15 -0300

On Tue, 18 Jan 2005 09:38:14 -0500, xpyttl wrote:

> "MethodMan" wrote in message
> news:1106017538.585904.202200@c13g2000cwb.googlegroups.com...
>
>> I personally believe that you should adapt a methodology to
>> your business and even further refine it to your project, which is why
>> I am not excited about cookie-cutter methodologies.
>
> There is an interesting quirk about programmers. They will resist any
> methodology as long as they can. Every programmer seems to firmly believe
> that he knows better than any other, and his immediate solution will always
> be better than the wisdom collected in a methodology.
>
> But once he turns the corner and accepts that he will have to follow the
> methodology, then he seems to want to follow it blindly. The methodology
> becomes an excuse to leave common sense at home.
>
> I really hate the terms, "follow the methodology" and "fill out the
> deliverable". I would rather leverage the methodology, and exploit its
> deliverables.
>
> ..

I suspect the real problem is that no one, neither programmers not
managers, realizes that methodologies only become effective over the long
haul. I agree that you have to adapt/refine them for your own shop, and
maybe even slightly tweak them for each project. If everyone wants instant
results, they will all be disappointed. I have seen several clients (not
on my advice BTW) spend (fractions of) millions of dollars buying
"methodology" and/or tools, and then scrimp on training, and impatiently
throw the whole thing out after only a few months because they did not see
immediate benefits. The CMM was good: it showed that getting to a mature
level 5 shop was not as simple as "buying the right tool". You actually
have to know something about the process, do a lot of planning, and work
hard to cover all the bases, to finally have it work well.

p.s. I have also been disappointed by "golly gee whiz" tools/products that
promise everything, but when you get past all the hype, you discover that
they are just "yet another toolkit" with their own definitions/terms, but
once again starting over from the beginning. Starting over is the easy
part! Refining and making further progress gets progressively more hard.

--
Juhan Leemet
Logicognosis, Inc.

From:	David Lightstone
Subject:	Re: Methodology Goals
Date:	Tue, 18 Jan 2005 14:45:44 GMT

"xpyttl" wrote in message
news:4d9Hd.12167$Fz6.1501@fe04.lga...
> "MethodMan" wrote in message
> news:1106017538.585904.202200@c13g2000cwb.googlegroups.com...
>
> > I personally believe that you should adapt a methodology to
> > your business and even further refine it to your project, which is why
> > I am not excited about cookie-cutter methodologies.
>
> There is an interesting quirk about programmers. They will resist any
> methodology as long as they can. Every programmer seems to firmly believe
> that he knows better than any other, and his immediate solution will
always
> be better than the wisdom collected in a methodology.

This is also true for managers. And is especially so for managers who never
programmed or no longer program.
Which if the 2 has decision making authority of methodology, the programmer
or the manager?

>
> But once he turns the corner and accepts that he will have to follow the
> methodology, then he seems to want to follow it blindly. The methodology
> becomes an excuse to leave common sense at home.
>
> I really hate the terms, "follow the methodology" and "fill out the
> deliverable". I would rather leverage the methodology, and exploit its
> deliverables.
>
> ..
>
>

From:	MethodMan
Subject:	Re: Methodology Goals
Date:	17 Jan 2005 16:15:06 -0800

Alexei,

Quality is but one dimension of a methodology and by itself cannot
describe the goal. Software is business driven; business looks at
factors such as ROI.

If your *only* factor is quality, than you should take a NASA-like
approach to development (in other words, your most important factor
should be quality, or else people die). It would be prohibitively
expensive for all businesses to develop software like NASA. But even
NASA has a budget, time constraints, and must deliver software
according to organizational needs.

In the real world we aren't all developers for NASA. But ironically,
NASA does have a mantra called "Faster, Better, Cheaper".

I would consider faster, better, and higher value (as opposed to
cheaper). Value is a ratio of cost/benefit. It would consider more
than just short term costs and look at long term costs. For example,
you can cut corners during development and save alot of money (such as
offshoring). But support costs are 70% of a projects expense in
general. If a project doesn't meet business needs it will likely need
to be extended or even re-designed at a later time. That is costly,
and even more costly when in production.
Thanks for your input, but I respectfully disagree.

MethodMan

From:	xpyttl
Subject:	Re: Methodology Goals
Date:	Mon, 17 Jan 2005 20:43:41 -0500

"MethodMan" wrote in message
news:1106007306.687662.48440@c13g2000cwb.googlegroups.com...

> I would consider faster, better, and higher value (as opposed to
> cheaper). Value is a ratio of cost/benefit. It would consider more
> than just short term costs and look at long term costs. For example,
> you can cut corners during development and save alot of money (such as
> offshoring). But support costs are 70% of a projects expense in
> general. If a project doesn't meet business needs it will likely need
> to be extended or even re-designed at a later time. That is costly,
> and even more costly when in production.

For a methodology to be successful in the real world (as opposed to academia
or NASA), more than anything else it must deliver predictability.
Generally, if the methodology can deliver predictability, then over time the
organization will learn how to adjust the variables of time to market,
development cost, support cost, machine resource cost, etc. etc. etc.

If the methodology cannot deliver predictability, then anything else it
CLAIMS to deliver is indistinguishable from hype.

Alexei sounds like a quality guy, and he should recognize that you got to
get the process under control before you can adjust the setpoint.

A lot of software guys have their definitions of quality that tend to
revolve around either some sort of theoretical elegance or some small number
of bugs. But quality is whatever the customer defines it to be. As
developers we don't get to define quality. Once the process is under
control .... once we can deliver what we claim to deliver, then we can
adjust our process to deliver against the customer's perception of quality
.... whether that be fast to market, best price, efficient use of bandwidth,
"user friendliness", whatever.

...

From:	MethodMan
Subject:	Re: Methodology Goals
Date:	18 Jan 2005 04:25:51 -0800

<<
Perhaps the control of quality, or qualities, or attributes, to what
ever level - good, bad, indifferent?
>>

I think the term "better" is inclusive of quality and other attributes
that define what the business thinks is better (a widesweeping term).
But better describes the quality that the business desires and not the
quality that *you* desire. Software is business driven and not
programmer driven.

As far as managing quality, as a manager of software development you
must balance many things in order to deliver what the customer views as
"better". You could deliver the perfect product for them, but if it is
late to market or absurdly expensive it might defeat the purpose of
using the software in the first place.

From:	Juhan Leemet
Subject:	Re: Methodology Goals
Date:	Tue, 18 Jan 2005 14:45:25 -0300

On Tue, 18 Jan 2005 04:25:51 -0800, MethodMan wrote:
> <<
> Perhaps the control of quality, or qualities, or attributes, to what
> ever level - good, bad, indifferent?
>>>
>
> I think the term "better" is inclusive of quality and other attributes
> that define what the business thinks is better (a widesweeping term).
> But better describes the quality that the business desires and not the
> quality that *you* desire. Software is business driven and not
> programmer driven.

I will slightly disagree. Business is interested in profit. Hence, it
usually wants "cheaper" (design and/or production costs) and "good
enough", not necessarily "better", except for marketing purposes. The
actual quality is probably irrelevant, just the perception is required.

> As far as managing quality, as a manager of software development you
> must balance many things in order to deliver what the customer views as
> "better". You could deliver the perfect product for them, but if it is
> late to market or absurdly expensive it might defeat the purpose of
> using the software in the first place.

Yes, "what the customer views as better", but he might be deluded.

Now I would also think that good (not excessive) and (most importantly?)
consistent quality would be a benefit to keeping the true costs down, and
making the customers happy, and giving the marketing guys lots to crow
about. However, practical experience has shown that this is not so. Else,
how come there is so much crappy software out there? Why do we always
start over from the bottom? Why does the cheapest bid (almost) always win?

FWIW, with a buddy, we once delivered a system with 1 bug (spelling
mistake) in 50KLOC and it worked well at 400% intended capacity for years.
Couldn't get the client to sell it, or give us any more work. WTF? Go
figure. No good deed goes unpunished. Too many liars out there.

--
Juhan Leemet
Logicognosis, Inc.

From:	shelley at osel.netkonect.co.uk
Subject:	Re: Methodology Goals
Date:	18 Jan 2005 01:22:18 -0800

Alexei A. Polkhanov wrote:

> I don't remember a case when "cheaper", "faster" or "better" were by

> itself goals of developing methodology, but QUALITY always is. Most
> common believe is that when QUALITY is achieved rest will follow.

I think I agree.

Perhaps the control of quality, or qualities, or attributes, to what
ever level - good, bad, indifferent? With quality under control, but
not necessarily turned up to 11, costs and schedule can be managed too.

If you can't manage quality you can't manage anything?

(Quality is a terrible word for this, its a major turn off or barrier
to discussing 'doing good stuff'. Are there any inoffensive synonyms
that aren't business jargon? I like Pirzig's phrase 'quality and care
are aspects of the same thing', but that can sound pompous too. Maybe
it's a road to Damascus thing.)

From:	Alexei A. Polkhanov
Subject:	Re: Methodology Goals
Date:	Mon, 17 Jan 2005 14:53:46 -0800

MethodMan wrote:
> Does anyone have a resource that describes the high-level goals of a
> methodology? My best stab which is based loosely on other texts
> (because the goal hasn't been explicitly defined) is more high level
> and from the viewpoint of the business: "the goal of a methodology is
> to enable the organization to develop software faster, better, and
> cheaper."
Ops, no... Primary goal of any software methodology should be and is a
QUALITY of resulting product, methodology itself defines means to reach
this goal in complex organization (Waterfall, Spiral model, XP) or by
single individual (PSP). Methodology usually is a well documented set of
practices which allow individual or organization to "consistently repeat
past successes" and achieve quality results.
I don't remember a case when "cheaper", "faster" or "better" were by
itself goals of developing methodology, but QUALITY always is. Most
common believe is that when QUALITY is achieved rest will follow.

> I don't believe this definition of the goal is out of line with any
> known methodology; does anyone not agree or does someone have a
> document where this is defined? Am I being presumptuous for defining
> the goal because perhaps a methodology designer has another goal in
> mind (although I can't imagine what that would be)?
>
Quality.

> Obviously what differs between methodologies is the path they have
> chosen to reach the goal. I am not arguing the details of
> methodologies here, just that they are all designed with the hope of
> developing software better, cheaper, and faster as opposed to worse,
> more expensive, and slower.
>
> Thanks,
>
> MethodMan
>
again Quality.

Alexei.

From:	MethodMan
Subject:	Re: Methodology Goals
Date:	18 Jan 2005 10:02:41 -0800

To use the terminology of this thread, unless we come up with a single
universal methodology of computing (i.e., the correct way of doing
things, regardless of "situations"), we will continue to be in the
same sorry mess that we are in.

The problem is that there is not a single, universal, best way of doing
things. The best way of doing things is based upon the scope of your
problem and the business requirements.

If I were developing software in my dream world, there are a ton of
things that would change. First of all, money and time would become
obsolete and mankind would work towards doing everything perfectly no
matter how much it costs or how long it takes.

Every thing I did would be optimized, have 0 bugs, be extensible,
scalable, tested to perfection, provide multiple interfaces, we would
use a universal language, and software would meet the requirements of
every single user now and in the future.

There would be no need for upgrades or incremental development because
all requirements would be understood before a single line of code was
written, and they would be so perfect that they would never, ever
change.

But in my world, money and time are a factor. Until that changes,
quality will always consider time and money.

From:	Traveler
Subject:	Re: Methodology Goals
Date:	Tue, 18 Jan 2005 15:54:38 -0500

In article <1106071361.847137.259980@c13g2000cwb.googlegroups.com>,
"MethodMan" wrote:

>
>To use the terminology of this thread, unless we come up with a single
>universal methodology of computing (i.e., the correct way of doing
>things, regardless of "situations"), we will continue to be in the
>same sorry mess that we are in.
>
>
>The problem is that there is not a single, universal, best way of doing
>things. The best way of doing things is based upon the scope of your
>problem and the business requirements.

You are already using a single underlying method of doing things even
if you don't realize it. It is called algorithmic-based software
construction. My argument is that the reason that traditional software
is plagued with all sorts of realiability/quality/productivity
problems has to do with a practice that is as old as the computer
itself: the use of the algorithm as the basis of programming. Switch
to a synchronous signal-based approach and the problem will disappear.

Louis Savain

The Silver Bullet or How to Solve the Software Crisis:
http://users.adelphia.net/~lilavois/Cosas/Reliability.htm

From:	Juhan Leemet
Subject:	Re: Methodology Goals
Date:	Tue, 18 Jan 2005 19:03:47 -0300

On Tue, 18 Jan 2005 15:54:38 -0500, Traveler wrote:

> In article <1106071361.847137.259980@c13g2000cwb.googlegroups.com>,
> "MethodMan" wrote:
>
>>
>>To use the terminology of this thread, unless we come up with a single
>>universal methodology of computing (i.e., the correct way of doing
>>things, regardless of "situations"), we will continue to be in the
>>same sorry mess that we are in.
>>
>>
>>The problem is that there is not a single, universal, best way of doing
>>things. The best way of doing things is based upon the scope of your
>>problem and the business requirements.
>
> You are already using a single underlying method of doing things even
> if you don't realize it. It is called algorithmic-based software
> construction. My argument is that the reason that traditional software
> is plagued with all sorts of realiability/quality/productivity
> problems has to do with a practice that is as old as the computer
> itself: the use of the algorithm as the basis of programming. Switch
> to a synchronous signal-based approach and the problem will disappear.
>
> Louis Savain
>
> The Silver Bullet or How to Solve the Software Crisis:
> http://users.adelphia.net/~lilavois/Cosas/Reliability.htm

OK, I read/skimmed that. Nice religion.

I think people have misunderstood Fred Brooks's intent with his "no silver
bullet" paper. IMO he was addressing the naive viewpoint of many managers
that there was just one thing that could be done to make it all magically
better/perfect. Sort of like "if I only had super powers, then I would
show them!" His warning (to my understanding) was that there is no one
thing, at the exclusion of everything else. You have to do EVERYTHING
right! Another big name in computing (I think it was Constantine?) said
that "in retrospect, no project completely/perfectly follows a given
methodology, but if you don't at least try, then you are totally lost!"

In fact, my discomfort with XP and other "modern" methods/methodologies is
that they still hint/promise that they are "the silver bullet", and "all
you gotta do is..." I don't believe it is that simple. There is a lot to
keep in mind. You have to keep your wits about you, and try to do
everything right. Then you should think about CMM and Six Sigma and try to
improve your processes to do better (and better... and better...).

In summary, I don't think there is one single universal methodology (SAD?
UML?), or language (remember PL/I?), or anything. They all have strengths
and weaknesses. They are all compromises. We have to make choices, and
manage processes well. There is no quick/easy solution. No one purchase
order to write. No one genius to hire. Let's not delude ourselves.

BTW, algorithmic based implies procedural, doesn't it? There are some very
good non-procedural languages out there. Are they useless? Don't think so.

Consider also something like accounting and bookkeeping, which has been
around for thousands of years. There is no "one way" to do it. There are
generally accepted practices: but (for fun?) try to ask your government
for their "standards for business accounting". I actually did ask our tax
ministry, naive young thing that I was at the time. They'll tell you to
hire (one of their buddies?) an accountant, who will "design a chart of
accounts". An engineer and good numbers guy I worked with years ago went
to learn some basic accounting (thinking it was well codified and
logical). Drove him crazy: what is a credit or a debit? depends!

--
Juhan Leemet
Logicognosis, Inc.

From:	MethodMan
Subject:	Re: Methodology Goals
Date:	18 Jan 2005 13:16:59 -0800

My argument is that the reason that traditional software
is plagued with all sorts of realiability/quality/productivity
problems has to do with a practice that is as old as the computer
itself: the use of the algorithm as the basis of programming. Switch
to a synchronous signal-based approach and the problem will disappear.

..

This is a computer science issue and really something that I am
powerless over. I am interested in solving business problems and until
the engineers come up with another method I am going to need to
continue using the tools and methods I have available to me today. I
neither agree or disagree with your premise because I don't have enough
information to make that judgement. But from a practical standpoint
this doesn't help me solve the business problems that I face today.