SW org. levels
Eric Peterson
With many thanks to Watts S. Humphrey at SEI who wrote "Managing the
Software Process" describing the SEI software maturity levels, and
Edward Yourdon for providing a clear interpretation in his book
"Decline and Fall of the American Programmer", I hereby provide my own
set of software organizational levels. I want to stress up front that
level 1 organizations are not always successful, their success depends
totally on the quality of their software developers, systems
engineers, marketers, and managers. In the descriptions below I will
show how successful level 1 organizations are more fun to work for,
have more motivated developers and are a great deal more productive
than most higher level organizations.
The levels are:
Level 1: Intuitive
Level 2: Repetitious
Level 3: Deafening
Level 4: Moribund
Level 5: Out-of-business
L E V E L 1: The Intuitive Level.
Level 1 organizations are characterized by independent software
developers in ad hoc groups with results that are generally
unpredictable and oftentimes innovative. There are a great variety of
styles within level 1 organizations and developers tend to group
around their style and many will even organize into level 2 and 3
groups.
Unfortunately only a subset of level 1 organizations are successful.
Some characteristics of successful level 1 organizations are:
* Software developers who are responsible for determining short and
long term requirements and keep these in mind as they develop code.
* Systems engineers who essentially "work for" the software developers
by reviewing code and designs, helping with testing and cm, and
keeping track of requirements.
* Managers who are smart, well-informed and react quickly.
* Managers who are willing to admit to the uncertainties of software
development and marketers who can keep customer interest with
prototypes and partial capabilities.
Why do level 1 organizations (even successful ones) rise towards
higher levels?
* The biggest reason is the desire for top-down development which is
driven by the misconception that design changes are "cheaper" than
code changes. This is only true because the designs themselves are
"cheap", containing a large number of arbitrary assumptions and
choices.
* Management desires more predictability. They would rather have a
"bird in hand" within a fairly certain period of time than
potentially nothing at all.
* Management desires less stress. Level 1 organizations place a great
burden upon management to react quickly to change, to promote the
organization's goals like maintainability amongst software developers
who might have different priorities for timeliness and quality.
* Software developers desire less stress. Level 1 organizations can
have lots of competition between developers with the result that
effort can be wasted, especially the effort of less talented or less
aggressive developers.
L E V E L 2: The Repetitious Level.
Organizations at level 2 have started to embrace the philosophy that
individualism is less important than software uniformity, and give
lots of "lip-service" to a formal development process whether or not
the process is followed by all developers.
Higher level organizations (above 1) also tend to promote the use of
top-down software development which is analysis followed by design
followed by coding. While there is always a degree of top-down
development in any software development, the higher level
organizations formalize the phases. For example, a level 2
organization will beginto gather statistics and assign schedules to
the analysis and design phases.
Level 2 organizations initiate the use of statistics (software
metrics) and schedules. The statistics gathering is necessary to
generate schedules and the schedules are used by management to placate
customers. In order to collect and promote the use of these
statistics, level 2 organizations start to form a "systems oligarchy"
who formalize the organizations software development process. This
group holds meetings that developers are supposed to but not required
to attend.
An organization at level 2 can generally become a more successful
level 1 organization simply by getting rid of the systems oligarchy,
and replacing them with a few good reactive managers.
L E V E L 3: The Deafening Level.
Level 3 organizations take the process goals from level 2 and make
them "manditory". Software developers are required to attend numerous
process-oriented meetings and are buried under an avalanche of
process-oriented memos and documents. Process adherence is measured
by regular use of statistics at each step of the development process.
Some general characteristics of unsucessful high level organizations
(level 3 and above) are:
* CASE tools are used to sanctify detailed arbitrary designs and to
further formalize the process.
* Quantitative measurements such as "having the correct 47 menu items"
replace qualitative measurements like "excites new users".
* Trivial bugs like a missing "stderr" inside "fprintf" require at
least a one page form to correct.
* Designs are no longer discussed in the cafeteria or hallways but in
lengthy meetings where hypothetical architectures are detailed beyond
any possible contextual (bottom-up) justification.
* Innovation is the exclusive privilege of the systems oligarchy, the
rest of the team has to follow the process.
L E V E L 4: The Moribund Level
At level 4, the systems oligarchy takes actions to curtail development
by forcing the use of formal process through mandatory reviews at each
process step. Developers who try to increase their productivity by
skipping steps or documentation of steps are slowed by lengthy review
sessions and/or counseling.
Development is strictly top-down so that it can be turned into
measurable steps. CASE tools are universally used by system designers
who can also automatically generate executable code. "Code
implementors" are given almost no autonomy or respect. Thus level 4
organizations are much like Stalinist countries in which the ruling
class hands out boring unrewarding jobs to a captive proletariat.
L E V E L 5: The Out-of-business Level
Level 5 organizations usually only exist by government largess or from
the momentum of lower level accomplishments. All independent
innovative software developers have been completely replaced by
block-diagram designers and drones. Although level 5 has promises of
doing new and exciting things (the systems oligarchy tells you so),
the potential customers are usually scared away after the fourth or
fifth time a "requirements gatherer" shows up (with no prototype).
Research projects in level 5 organizations usually study the latest
code generator or high level system analysis tool.
Level 5 represents the final step in an inward focus on development
process and away from requirements, data, and users. Requirements are
treated abstractly, and data is also an abstraction to be studied for
requirements instead of real bits to be analyzed with prototype code.
And, of course, the dreams and desires of the eventual users of the
software are ignored.
Eric Peterson
Michael Winters
Eric Peterson <er...@capella.tsc.gtefsd.com> wrote:
>"Software Organizational Levels"
>
>With many thanks to Watts S. Humphrey at SEI who wrote "Managing the
>Software Process" describing the SEI software maturity levels, and
>Edward Yourdon for providing a clear interpretation in his book
>"Decline and Fall of the American Programmer", I hereby provide my own
>set of software organizational levels. I want to stress up front that
>level 1 organizations are not always successful, their success depends
>totally on the quality of their software developers, systems
>engineers, marketers, and managers. In the descriptions below I will
Great descriptions! I want to applaud you for this post. :--)
>show how successful level 1 organizations are more fun to work for,
I agree, 100%, that Level 1 orgranizations are the greatest, noting that
a little of Level 2 thrown in is fine, but that organizations tend to
go too far or leave out, entirely, documentation and procedures.
One governement contract I was on required programmers to write program
headers to document each program. So, for a 10 line subroutine, I have to
write 100 lines of documentation, as in-line comments!! This can get kind
of ridiculous.
>have more motivated developers and are a great deal more productive
>than most higher level organizations.
>
>
>The levels are:
>
>Level 1: Intuitive
>Level 2: Repetitious
>Level 3: Deafening
>Level 4: Moribund
>Level 5: Out-of-business
>
>
>L E V E L 1: The Intuitive Level.
>
>Level 1 organizations are characterized by independent software
>developers in ad hoc groups with results that are generally
>unpredictable and oftentimes innovative. There are a great variety of
>styles within level 1 organizations and developers tend to group
>around their style and many will even organize into level 2 and 3
>groups.
>
>
>Unfortunately only a subset of level 1 organizations are successful.
>Some characteristics of successful level 1 organizations are:
>
>* Software developers who are responsible for determining short and
> long term requirements and keep these in mind as they develop code.
keep the managers out of micro-managing these deadlines.
This is what I hate about CASE and 4GL tools, but like listening to
Top-40 or other popular music that is played on 99% of radio stations,
most organizations want to remove and fun or unpredictability in
developing software and replace the process by something horribly boring.
Although level 5 has promises of
>doing new and exciting things (the systems oligarchy tells you so),
>the potential customers are usually scared away after the fourth or
>fifth time a "requirements gatherer" shows up (with no prototype).
>
>Research projects in level 5 organizations usually study the latest
>code generator or high level system analysis tool.
This is definitely true, since I just posted the results of a CASE
tool we are looking at, but fortunately, our organization doesn't have
CASE or it's methodologies so ingrained in our culture that programming
becomes a drone-like activity. There are too few of us for that probably
to ever happen, but you never know.... I was in shock the first time I
was "forced" to use a 4GL language, several years ago. There is talk of
eventually completely doing away with application developers, but I hope
that doesn't happen soon. Or will we all be working for Microsoft or
Oracle some day? :-)
>
>Level 5 represents the final step in an inward focus on development
>process and away from requirements, data, and users. Requirements are
>treated abstractly, and data is also an abstraction to be studied for
>requirements instead of real bits to be analyzed with prototype code.
>And, of course, the dreams and desires of the eventual users of the
>software are ignored.
>
>Eric Peterson
I want my FORTRAN back! :-(
Again, I want to say that I really enjoyed reading the above post.
----- Mike Winters Peace Corps (202)606-5543
Bob Hathaway
>In article <2h40ks$l...@europa.eng.gtefsd.com>,
>Eric Peterson <er...@capella.tsc.gtefsd.com> wrote:
>>"Software Organizational Levels"
>>...
>>The levels are:
>>
>>Level 1: Intuitive
>>Level 2: Repetitious
>>Level 3: Deafening
>>Level 4: Moribund
>>Level 5: Out-of-business
This is very funny, but I couldn't resist posting. With people arguing
against total quality, simple process control, and even modern methods
(OO for software), I'm beginning to agree with Yourdon. High-quality
software developers have nothing to worry about.
I recall reading in Boehm that a grossly deficient 250 PhD's in computer
science are awarded each year in the U.S. And I'd estimate the number
qualified in software engineering to be around 5. The lack of top-quality/
top-qualified people should be a real concern, for their voices are lost
in a sea of noise.
Proof of poster being 25 years out-of-date:
>I want my FORTRAN back! :-(
I agree that processes and methods should be flexible, as do the authors
of the process control and (OO) methods discussed, but this is obviously
understood and dealt with explicitly. For example, by Humphrey and all
modern (OO) software methods. In fact, flexibility provides the foundation
of modern OO methods, starting with Boehm straight thru to Booch.
I hope I can be forgiven for my non-understanding attitude; I guess modern
high-quality methods have been almost a religion to me.
Best Regards,
bob
Michael W Cerny
: "Software Organizational Levels"
: The levels are:
I'm the development manager of a small start-up, and I would characterize
our group as being very much a level-one effort. We were exceptionally
lucky in that we hired a core group of developers who were able to
effectively coordinate together for a large distributed software effort.
Unfortunately, while we have done a good job at getting functionality in
place, our forecasting record is abysmal. Given that our funding
depends upon getting the software finished, I've been trying to
institute schedules. My rationale is that a schedule forces a developer
to be held accountable for his current workload (a novel concept here <g>).
I spent some time before starting trying to determine the best way of
generating them. About the only way that I found that made sense was to
sit down with a developer and have him estimate the amount of time to
completion. I have more development experience than most of the guys
here, so I will oftentimes modify the developer estimates to reflect
my (theoretically) more accurate guess.
It's been tough to avoid the temptation to avoid putting a bunch of
process-oriented procedures.
Mark Shanks
>
>The levels are:
>
>Level 1: Intuitive
>Level 2: Repetitious
>Level 3: Deafening
>Level 4: Moribund
>Level 5: Out-of-business
>
>
>L E V E L 1: The Intuitive Level.
>
>Level 1 organizations are characterized by independent software
>developers in ad hoc groups with results that are generally
>unpredictable and oftentimes innovative.>
>
>
>Organizations at level 2 have started to embrace the philosophy that
>individualism is less important than software uniformity, and give
>lots of "lip-service" to a formal development process whether or not
>the process is followed by all developers.
>L E V E L 3: The Deafening Level.
>
>Level 3 organizations take the process goals from level 2 and make
>them "manditory". Software developers are required to attend numerous
>process-oriented meetings and are buried under an avalanche of
>process-oriented memos and documents. Process adherence is measured
>by regular use of statistics at each step of the development process.
>
>L E V E L 4: The Moribund Level
>
>At level 4, the systems oligarchy takes actions to curtail development
>by forcing the use of formal process through mandatory reviews at each
>process step. Developers who try to increase their productivity by
>skipping steps or documentation of steps are slowed by lengthy review
>sessions and/or counseling.
>Thus level 4 organizations are much like Stalinist countries in which
>the ruling class hands out boring unrewarding jobs to a captive
>proletariat.>
>
>L E V E L 5: The Out-of-business Level
>
>Level 5 represents the final step in an inward focus on development
>process and away from requirements, data, and users. Requirements are
>treated abstractly, and data is also an abstraction to be studied for
>requirements instead of real bits to be analyzed with prototype code.
>And, of course, the dreams and desires of the eventual users of the
>software are ignored.
Process-dweeb response:
Heretic! Blasphemer! The Emperor does TO have clothes! I CAN"T HEAR
YOU MMMMM MMMMMMM MMMMM!!!
Paul C. George
er...@capella.tsc.gtefsd.com writes:
>Unfortunately only a subset of level 1 organizations are successful.
>Some characteristics of successful level 1 organizations are:
>
>* Software developers who are responsible for determining short and
> long term requirements and keep these in mind as they develop code.
>
>* Systems engineers who essentially "work for" the software developers
> by reviewing code and designs, helping with testing and cm, and
> keeping track of requirements.
>
>* Managers who are smart, well-informed and react quickly.
>
>* Managers who are willing to admit to the uncertainties of software
> development and marketers who can keep customer interest with
> prototypes and partial capabilities.
>
Your (I hope somewhat tongue in cheek) insighfull post clearly shows the
risk in process improvement based upon a !systems oligarchy!. The
characteristics you mention above are critical at any maturity level. The
higher levels as you describe them are reducing flexability and
capability rather than increasing the ability to run projects sucessfully.
The problem with level 1 organizations is that the supply of talented
software people and managers, like the supply of General Bernadotte!s, is
small. Success is dependant upon individuals.
Second, ad hoc efforts by creative individuals tend to be inconsistant,
incompatable, and often mutually incomprehensible between different
developers. (!...but what you heard was not what I meant! )This makes
both consistency checking and verification difficult. It _can_ work with
a small team which has worked together, but has problems scaleing.
Communication is an arcane and fallible art.
Many software developers are not good at capturing requirements from
users, recording them clearly, or interpreting them consistantly.
Providing some standards for requirements specifications, designs, and
requirements traceability helps avoid mistakes. The process oriented
principles such as defineing requirements before solution before
implementation is also valuable to help support good engineering. The
process may spiral, recurse, or iterate; but it is hard to build
something until you know what it is. It is even harder to tell if it was
what you (or your customer) intended.
I dont think that systems engineers should !work for! software engineers,
particularly in HW/SW systems, but rather !work with!. Systems engineers
will probably define the initial requirements, along with marketing. They
tend to have a broader background and focus than pure software engineers.
(We may have a problem with job descriptions). SW people will doubtless
refine or elaborate the requirements, and are certianly responsible
!keeping them in mind!. I think both parties work as a team focusing on
different things.
Process should not imply rigidity or lots of paperwork, but rather an
understood template for doing business. As you note, reviews are key
techniques for insuring correctness & completeness, but you have to use
some kind of common language and set of expectations. Using some common
method helps both communications and encourages rigor. The development
process should not be top down, but rather !first things first!.Often
!speeding up the process! by skipping steps just means fuzzy thinking and
incomplete work which blows up later. !Tailoring! should be a standard
practice, but it is pro-active rather than reactive (!We!ve got to catch
up!).
=======================================================================
===
There are two kinds of a fool:
One says !This is old and therefor good'
The other says !This is new and therefor better!
-----------------------------------------------------------------------
---
Paul C. George, Sr. Methods Specialist pge...@bailey.com
Bailey Controls Co., Wickliffe OH (216)585-8675
-----------------------------------------------------------------------
---
Disclaimer: I am neither a ventriloquist nor a dummy
=======================================================================
===
Eric Peterson
writes:
|> Your (I hope somewhat tongue in cheek) [...]
I was serious.
|> [Good people are scarce]. Success is dependant upon individuals.
So we are better off if "success is dependent on committees"?
|> Second, ad hoc efforts by creative individuals tend to be inconsistant,
|> incompatable, and often mutually incomprehensible between different
|> developers. [...]
So we sacrifice originality and productivity for compatability and
consistency? I prefer to spend the extra hours needed to review my
colleagues' original designs and code.
|> Many software developers are not good at capturing requirements from
|> users, recording them clearly, or interpreting them consistantly.
Good software developers are.
|> [processes are good]
Good software developers never spend a moment thinking about them
because the best ones are obvious.
|> [systems engineers are broader than SW engineers, we need both]
True, but as a "team" (like you say) and not as part of a "process".
Especially not the typical process where "Systems" hands some
drivel down to "Software".
|> Process should not imply rigidity or lots of paperwork, but rather an
|> understood template for doing business.
The "business" of creating software or the "business" of looking busy?
|> [reviews are good but require consistency]
|> The development process should not be top down, but rather
|> !first things first!. Often !speeding up the process! by skipping
|> steps just means fuzzy thinking and incomplete work
which we have to fix later. Good new ideas in software always start
out fuzzy, and take shape as we build-a-little and test-a-little. The
bottom line is good software developers will build high quality
maintainable code without the benefit of drawings full of blocks,
schedules with milestones, or total-quality-configuration-control.
On the other hand, your paint-by-numbers painting might look nice,
but it won't be new, interesting or valuable.
|> [...]
|> Paul C. George, Sr. Methods Specialist pge...@bailey.com
|> Bailey Controls Co., Wickliffe OH (216)585-8675
eric
Paul C. George
>|> [Good people are scarce]. Success is dependant upon individuals.
>
>So we are better off if "success is dependent on committees"?
No. Committees don!t enter into it. The individuals in question are the
(rare) competent managers and the skilled developers who through
extraordinary efforts save the poor managers asses when the project fouls
up. The idea behind higher maturity levels is to distil the sucessfull
techniques of good managers and developers and make them available to the
less skilled.. It also provided mechanisms for coordinating individuals,
enhancing communication, and supporting pleas for reasonable schedules. A
standard process should provide a framework and set of !best practices!
for
a project that is customized for every project, rather than re-inventing
the wheel for every one.
>
>|> Second, ad hoc efforts by creative individuals tend to be
inconsistant,
>|> incompatable, and often mutually incomprehensible between different
>|> developers. [...]
>
>So we sacrifice originality and productivity for compatability and
>consistency? I prefer to spend the extra hours needed to review my
>colleagues' original designs and code.
Providing you can understand them.
Again, I dont see that defining a process must !sacrifice originality and
productivity!. The use of common notations on a project and providing
minimum contents for deliverables (i.e. define !done!) shouldn!t impact
creativity. If an item for a deliverable or a notation isn!t appropriate
for a particular problem, pick one that does. Having a common language or
comparable products will aid productivitiy you discover errors early and
avoid mistakes in communication.
>
>|> Many software developers are not good at capturing requirements from
>|> users, recording them clearly, or interpreting them consistantly.
>
>Good software developers are.
I guess I haven!t seen many good developers by your definition, and I
have
been in a lot of companies. I have definitely never seen an entire
project
staff composed of them. I have observed that (very oddly) programmers
tend to be unable to think symbolically. They also don!t seem to be very
good writers, and make all kinds of interesting assumptions about what is
common knowledge or a project concensus. English is a rather slippery
language, and anything that aids precision and specificity may help the
process (if it doesn!t require more effort than it is worth. This is
called
engineering analysis).
>
>|> [processes are good]
>
>Good software developers never spend a moment thinking about them
>because the best ones are obvious.
>
Unfortunately no. We are not talking about techniques or methods, and
even
then it is not !obvious! what is best, as it changes based upon the
circumstances. There is a considerable divergence of opinion between
developers about what is !best! in anything. We are talking about
mechanisms to allow _groups_ of developers and non-developers to work
together efficiently. I get the feeling that you are used to projects
with
either single developers or less than 5 on the team, and with very short
duration.
>|> [systems engineers are broader than SW engineers, we need both]
>
>True, but as a "team" (like you say) and not as part of a "process".
>Especially not the typical process where "Systems" hands some
>drivel down to "Software".
Amen - this is where good process analysis and definition comes in. You
analyze customer/supplier relationships and determine what everyone needs
to do their job. Anything unused or unneeded for a particular project or
the generic (superset) process is purged.
>
>|> Process should not imply rigidity or lots of paperwork, but rather an
>|> understood template for doing business.
>
>The "business" of creating software or the "business" of looking busy?
>
The former- framework and toolkit for development & other supporting
activities. Looking busy is just wasted effort. The best engineers and
process engineers are lazy. A project selects what is appropriate for the
problem at hand. A few things like inspections and testing should be
mandatory for product development to prevent sloppyness. I have known
some
real disasters to occur because a !star! developer was convinced he was
so
good that a clean compile constituted unit test.
>|> [reviews are good but require consistency]
>|> The development process should not be top down, but rather
>|> !first things first!. Often !speeding up the process! by skipping
>|> steps just means fuzzy thinking and incomplete work
>
>which we have to fix later. Good new ideas in software always start
>out fuzzy, and take shape as we build-a-little and test-a-little.
The idea is to avoid having to fix it later if you can. If you are
experimenting or prototyping, use the process for an scientific
experiment.
Have a plan that states your hypotheses or issues, describe your
approach,
and define your decision/success criteria. Then do it. Finally write up
your results and what you intend to do next. The record will be useful
for
others. By all means put your best people on such a task. You can
spioral
and reiterate in a project revisiting !sections! of a deleleverable
elaborating or changing as needed. But you had better know what
constitutes
!completeness! for it and you had better have some kind of change control
and CM to allow recovery and avoid !feature creep!.
>The bottom line is good software developers will build high quality
>maintainable code without the benefit of drawings full of blocks,
>schedules with milestones, or total-quality-configuration-control.
We have extensive objective evidence that this is not the case. Good
developers _can_ do such things but usually don!t for a number of
reasons,
many of them external.
Drawings help later developers and maintainers understand the software or
system without having to decipher !write-only! code fragments scattered
between multiple files. Schedules help managers run large long term
projects and detect when one is in trouble or it!s scope has been
misinterpreted. It also helps to estimate how long something partially
known might take based upon past experience, and do a business analysis
of
whether it is worth the effort. CM avoids chaos in the code library and
helps assure others don!t step on your code. It is most frustrating when
something that worked yesterday doesn!t today. These things may not
allways
be needed for a one person project, trivial bug fix, or quick and dirty
prototype, but they are usually needed for a software organization that
intends to be around for a while or maintain a product base.
>
>On the other hand, your paint-by-numbers painting might look nice,
>but it won't be new, interesting or valuable.
A better image then !paint-by-numbers! is a !chinese menu! - 1 from
column
A and 2 from column B, appetizers & desert optional. Whether it is new or
interesting depends on the problem, not the process or lack thereof.
Valuable is determined by the customer or the company (based upon sales
vs
cost)
You have clearly had some bad experiences with !all not mandatory is
forbidden! !one size fits all! processes intended to avoid thought on the
part of managers or slavishly adopted by managers withought thought or
analysis. My experiences with 2167A contracts and ignorant program
offices
confirm it can happen. Programs were rarely willing to take the effort or
!risk! of tailoring.
=======================================================================
===
There are two kinds of a fool:
One says !This is old and therefor good'
The other says !This is new and therefor better!
-----------------------------------------------------------------------
---
Paul C. George, Sr. Methods Specialist pge...@bailey.com
Bailey Controls Co., Wickliffe OH (216)585-8675
gam...@rapnet.sanders.lockheed.com
> In article <CJMzp...@bailey.com>, Paul C. George <pge...@bailey.com>
> writes:
I'm sorry but this whole post ticked me off. If you don't have something
constructive to add to *WHAT IS SUPPOSED TO BE A TECHNICAL conference*, then
how about not posting, or sending email? What are we supposed to be
*blessed* by your inference that at least you are a "Good software developer"?
Then go build some software that does "good". Meanwhile, the rest of us can
concern ourselves with issues that MAY improve the "art" of software
development. To the extent that process improvement aids in this end, I fully
support it. As the reviews come in IF there is little improvement something
else will likely take process improvement's place. If major improvements are
possible everyone stands to gain. YOU don't need to be on the leading edge of
this effort, but I seriously question your underlying motivation for trying to
crush it with such drivel.
Apologies to any others who didn't read this post the same way I did ;)
Joe Gamache
Robert G. Munck
> The levels are:
>
> Level 1: Intuitive
> Level 2: Repetitious
> Level 3: Deafening
> Level 4: Moribund
> Level 5: Out-of-business
If you missed this article, go! find it! read it! It has enough truth in
it to be very, very funny and very painful. I'm not sure it if was always
the article itself that was funny, or the actual current "truths" in s/w
development processes.
--
Bob Munck
Mark Shanks
>>(large chunk of previous discussion snipped)<<
>I'm sorry but this whole post ticked me off.
"Sall right.
> YOU don't need to be on the leading edge of this effort, but I
> seriously question your underlying motivation for trying to
> crush it with such drivel.
I infer that by "this effort", you mean "process development".
If anything, the original poster, rather than "trying to crush
it with such drivel", was merely waving as a bystander at the
passing juggernaut, rather than throw himself under it's wheels,
as seems to be the fashion, particularly with government
contractors.
>Apologies to any others who didn't read this post the same way I did ;)
And mine to all whose religion I may have insulted.
-------------------------------------------------------------------
| Mark Shanks |
| Principal Engineer | All opinions mine,
| 777 Displays | of course.
| sha...@saifr00.ateng.az.honeywell.com |
| "We have such sights to show you..." |
-------------------------------------------------------------------
Lowell Skoog
>The levels are:
>
>Level 1: Intuitive
>Level 2: Repetitious
>Level 3: Deafening
>Level 4: Moribund
>Level 5: Out-of-business
I think the problem that Eric Peterson reveals here is that although
we have observed increasing levels of maturity in software development
organizations, software process improvement is still a level 1 activity.
The success of process improvement is extremely dependent on the skills
of the people implementing it.
Unfortunately, it sounds like Eric has experienced poorly implemented
process improvement efforts. This doesn't deter folks like myself from
seeing value in the effort. It just makes us more careful.
---
Lowell Skoog Fluke Corporation Everett, WA, USA
low...@tc.fluke.COM {uunet,microsoft}!fluke!lowell (206) 356-5283
Phil Julian
In article <CJzqz...@tc.fluke.COM>, low...@tc.fluke.COM (Lowell Skoog) writes:
|> er...@capella.tsc.gtefsd.com (Eric Peterson) writes:
|>
|> >The levels are:
|> >
|> >Level 1: Intuitive
|> >Level 2: Repetitious
|> >Level 3: Deafening
|> >Level 4: Moribund
|> >Level 5: Out-of-business
|>
|> I think the problem that Eric Peterson reveals here is that although
|> we have observed increasing levels of maturity in software development
|> organizations, software process improvement is still a level 1 activity.
|> The success of process improvement is extremely dependent on the skills
|> of the people implementing it.
|> ---
|> Lowell Skoog Fluke Corporation Everett, WA, USA
|> low...@tc.fluke.COM {uunet,microsoft}!fluke!lowell (206) 356-5283
Well, I like the humor, but like all good comedians, there is a bit of
the philosopher or psychiatrist in them. And he does poke fun at our
intellectual icons -- as Rev. Billy Wirtz says, "Sacred cows do make
the best burgers!".
As I read Eric's post, I thought of all the arguments I have heard
over the years against good software engineering practices, whatever
the current buzzword may be. And I am really interested in what the
programmer thinks about these issues, because without their support,
all these concepts will fail.
Personally, I call the level 1 stage the Wild Wild West. If you don't
like a concept, an idea, or a software practice, then you pull out
your six shooter and you blow them away. It's a land full of rugged
pioneering individuals who are weather worn, stubborn, crotchety
curmudgeons. The problems occur when there are too many of those Wild
Wild West cowboys and cowgirls, and not enough of the open and
unspoiled frontier -- no elbow room, pardner.
When you put those rowdies into Dodge City, you would expect them to
get arrested by the software police, if only we had some. But the
usual case is bemused tolerance, since we all must take care of our
village idiots. Some people can do no wrong, especially if you don't
understand exactly what they are doing, even though you suspect that
they must really be idiots savant. So, level 2 is when the carpet
baggers and the cavalry come in, and you just know the sherrif of
Dodge City will be coming soon (level 3).
Pretty soon, it's all gone to hell and is no more fun. The saloons
are gone. If you kill a gun slinger in the streets, you go to trial.
No more spitting on the sidewalk, or they'll drag you in. Pretty
soon, they will make this a big city and bring in the railroad --
we'll become San Fransisco, and no longer be Po Dunk.
Order and progress are established (level 4), except for those
unincorpated parts in the next county, with no taxes, no lawmen, and
no zoning ordinances. That's where the rebels live in their run down
houses and cardboard shacks. They are still trying to find the last
remaining frontier lands on the earth. Most of them are dying from
hypothermia in Antarctica, since they really have no idea how to make
the wilderness habitable. And as they gently ride or hobble off into
the sunset, let us hope they get far from here and forget to take a
map and compass with them, because they think that navigation by
intuition is the only way to travel.
--
Phil Julian | "I call it warpabilly, muddle of the rude, queasy
SAS Institute, Inc. | listening!"
Open Systems R & D | Rev. Billy C. Wirtz, as quoted in the Record
jul...@unx.sas.com | Exchange Music Monitor
Jon Poletti
HaHaHaHaHaHaHaHaHaHaHaHaHa.
You know, it was just so *funny* HaHaHaHaHaHaHaHaHa.
I can hardly contain myself. HaHaHaHaHaHaHaHaHa. As soon as I read it,
I printed it right out. I show it to my customers every chance I get.
HaHaHaHaHaHaHa. We're such a fun bunch! You know, my customers thought it
was funny too! They said, well software never works anyway. HaHaHaHaHaHaHa.
Even my boss thought it was funny. HaHaHaHaHaHaHa. Boy, it doesn't get better
than this.
You know I think that Watts Humphrey is all wrong about this stuff.
HaHaHaHaHaHaHaHaHaHa. I mean someone can sit in their garage and whip out
little programs --- HaHaHaHaHa -- and wonder Why are all these quality nuts
making such a fuss? HaHaHaHaHa. It's just software. And such funny software
at that.
You know, Humphrey says that you can't skip levels, but HaHaHaHaHaHaHaHaHa
But, I think it would be so easy to skip from Level 1 to Level 5 (see above).
HaHaHaHaHaHaHaHa.
Sorry, but I couldn't resist. These idiots have been driving me crazy. Ehm.
Well, I feel much better now. HaHa.
Jon Poletti
--------------------------------------------------------------------------------
The opinions expressed here are my own and do not reflect those of Hns
--------------------------------------------------------------------------------
Jon Poletti, Software Engineer Hughes Network Systems
INTERNET: jpol...@hns.com 11717 Exploration Lane
(301) 601-7245 Germantown, Maryland 20876
--------------------------------------------------------------------------------
"A man who works to survive is a slave" Joseph Campbell
--------------------------------------------------------------------------------
Jon Poletti
HaHaHaHaHaHaHaHaHaHaHaHaHa.