Home > Archive > Cobol > December 2007 > The Art of Project Management
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
The Art of Project Management
|
|
| Robert 2007-12-23, 6:56 pm |
| Following are (fair use) excerpts from the book by Scott Berkun, former Microsoft project
manager.
I invested so much time in these lists because I knew that having clear priorities was the
backbone of progress. Making things happen is dependent on having a clear sense of which
things are more important than others and applying that sense to every single interaction
that takes place on the team. These priorities have to be reflected in every email you
send, question you ask, and meeting you hold. Every programmer and tester should invest
energy in the things that will most likely bring about success. Someone has to be
dedicated to both figuring out what those things are and driving the team to deliver on
them.
What slows progress and wastes the most time on projects is confusion about what the goals
are or which things should come before which other things. Many miscommunications and
missteps happen because person A assumed one priority (make it faster), and person B
assumed another (make it more stable). This is true for programmers, testers, marketers,
and entire teams of people. If these conflicts can be avoided, more time can be spent
actually progressing toward the project goals.
.....
If you do use the three most common ordered lists, make sure that they always map to each
other. Every engineering work item should map to a feature, and every feature should map
to a goal. If a new work item is added, it must be matched against features and goals.
This is a forcing function to prevent random features. If a VP or programmer wants to slip
something extra in, she should be forced to justify it against what the project is trying
to achieve: "That's a great feature, boss, but which goal will it help us satisfy? Either
we should adjust the goals and deal with the consequences, or we shouldn't be investing
energy here." If you teach the team that it's a rule to keep these three levels of
decision making in sync, you will focus the team and prevent them from wasting time.
.....
Have you ever been in a tough argument that you thought would never end? Perhaps half the
engineers felt strongly for A, and the other half felt strongly for B. But then the smart
team leader walks in, asks some questions, divides the discussion in a new way, and
quickly gets everyone to agree. It's happened to me many times. When I was younger, I
chalked this up to brilliance: somehow that manager or lead programmer was just smarter
than the rest of the people in the room, and saw things that we didn't. But as I paid more
attention, and on occasion even asked them afterward how they did it, I realized it was
about having rock-solid priorities. They had an ordered list in their heads and were able
to get other people to frame the discussion around it. Good priorities are power. They
eliminate secondary variables from the discussion, making it possible to focus and resolve
issues.
http://msdn2.microsoft.com/en-us/library/aa480154.aspx
http://www.scottberkun.com/the-book...ect-management/
Excerpts from the author's blog:
XXXXXXX Driven development (ADD) - Any team where the biggest jerk makes all the big
decisions is XXXXXXX driven development. All wisdom, logic or process goes out the window
when Mr. XXXXXXX is in the room, doing whatever idiotic, selfish thing he thinks is best.
There may rules and processes, but Mr. A breaks them and people follow anyway.
Cover Your Ass Engineering (CYAE) - The driving force behind most individual efforts is to
make sure than when the shit hits the fan, they are not to blame.
Development By Denial (DBD) - Everybody pretends there is a method for what’s being done,
and that things are going ok, when in reality, things are a mess and the process is on the
floor. The worse things get, the more people depend on their denial of what’s really
happening, or their isolation in their own small part of the project, to survive.
Get Me Promoted Methodology (GMPM) - People write code and design things to increase their
visibility, satisfy their boss’s whims, and accelerate their path to a raise or the corner
office no matter how far outside of stated goals their efforts go. This includes allowing
disasters to happen so people can be heroes, writing hacks that look great in the short
term but crumble after the individual has moved on, and focusing more on the surface of
work than its value.
http://www.scottberkun.com/blog/200...en-development/
| |
|
| In article <n3ptm3dslcg5oubru6oc61t1ktbsets438@4ax.com>,
Robert <no@e.mail> wrote:
>Following are (fair use) excerpts from the book by Scott Berkun, former
>Microsoft project manager.
[snip]
>If a VP or
>programmer wants to slip
>something extra in, she should be forced to justify it against what the
>project is trying
>to achieve: "That's a great feature, boss, but which goal will it help
>us satisfy? Either
>we should adjust the goals and deal with the consequences, or we
>shouldn't be investing
>energy here."
VP (or other Boss): 'What part of 'I sign your timesheets/write your
performance reviews' do you have difficulty in understanding? It may not
make sense to you but that's because I have the Big Picture and you don't;
questioning this will be treated as grounds for transfer to the mailroom.'
From
<http://groups.google.com/group/comp...69?dmode=source>
--begin quoted text:
Date: 1997/12/29
[snip]
Hmmmm... decades back, when I got my First Job, my sainted Mother, may
she sleep with the angels, gave me the following sage counsel:
'Then it comes to work remember two things: you can be wrong about
something... and be fired for it; you can be right about something...
and be fired for it.'
--end quoted text
DD
| |
| Robert 2007-12-24, 3:55 am |
| On Mon, 24 Dec 2007 00:21:21 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <n3ptm3dslcg5oubru6oc61t1ktbsets438@4ax.com>,
>Robert <no@e.mail> wrote:
>
>[snip]
>
>
>VP (or other Boss): 'What part of 'I sign your timesheets/write your
>performance reviews' do you have difficulty in understanding? It may not
>make sense to you but that's because I have the Big Picture and you don't;
>questioning this will be treated as grounds for transfer to the mailroom.'
Management by fear is good for maintaining the status quo; it doesn't work for fostering
innovation. The same has been said about Cobol, by some proponents as well as critics.
Berkun's prescription is a central feature of formal processes, where the lists are called
Detailed Design, High Level Design and Business Requirement. The document that relates
them is often called Requirements Tracability Matrix. In order for a VP to add a pet
feature, he or she would have to intimidate three committees and a group of auditors.
| |
|
| In article <4f9um3dbmdd0fn08hmma3s8l63p9as4f7b@4ax.com>,
Robert <no@e.mail> wrote:
>On Mon, 24 Dec 2007 00:21:21 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>Management by fear is good for maintaining the status quo; it doesn't
>work for fostering
>innovation.
What fear? This is Management by Objective; if someone objects then the
objective of a paycheck is not meant.
>The same has been said about Cobol, by some proponents as
>well as critics.
Something was said about paying the piper and calling the tune long before
Babbage's Analytical Engine was dreamt-of, as well.
>
>Berkun's prescription is a central feature of formal processes, where
>the lists are called
>Detailed Design, High Level Design and Business Requirement. The
>document that relates
>them is often called Requirements Tracability Matrix. In order for a VP
>to add a pet
>feature, he or she would have to intimidate three committees and a group
>of auditors.
'(A) central feature of formal process'... Mr Wagner, some people might
say that this is antithetical to progress, with RAD
two-coders-to-a-keyboard programming and JIT implementation of features
that weren't thought of back when someone said 'wouldn't it be nice if we
could...' and other aspects of Modern Design.
Centralised, formal processint... what comes next, requests for User
Sign-Off?
DD
| |
| Pete Dashwood 2007-12-24, 6:56 pm |
|
"Robert" <no@e.mail> wrote in message
news:4f9um3dbmdd0fn08hmma3s8l63p9as4f7b@
4ax.com...
> On Mon, 24 Dec 2007 00:21:21 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
> Management by fear is good for maintaining the status quo; it doesn't work
> for fostering
> innovation. The same has been said about Cobol, by some proponents as well
> as critics.
>
> Berkun's prescription is a central feature of formal processes, where the
> lists are called
> Detailed Design, High Level Design and Business Requirement. The document
> that relates
> them is often called Requirements Tracability Matrix. In order for a VP to
> add a pet
> feature, he or she would have to intimidate three committees and a group
> of auditors.
>
Not at all.
I have worked in places where a VP simply overrides the process and says:
"That's what I want."
You can have all the checks, balances, lists, correlations, processes, and
accountability you like, it is trumped by ego and power.
(Dealing with this, is covered in a forthcoming book I'm writing... :-))
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Judson McClendon 2007-12-24, 6:56 pm |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
>
> You can have all the checks, balances, lists, correlations, processes, and accountability you like, it is trumped by ego and
> power.
Or stupid/ignorant/etc. and power. The main ingredient is power. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Robert 2007-12-25, 3:55 am |
| On Mon, 24 Dec 2007 12:56:06 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <4f9um3dbmdd0fn08hmma3s8l63p9as4f7b@4ax.com>,
>Robert <no@e.mail> wrote:
>
>What fear? This is Management by Objective; if someone objects then the
>objective of a paycheck is not meant.
Before 1980, IT shops were managed intuitively like factories, retail stores and offices.
You imply they still are. Small and some medium sized shops still are, but not big
organizations.
The informal approach was found to be unreliable because it depended on managerial skills.
It was replaced in the '80s and '90s by formal methodologies such as CMM, ISO9000, SDLC,
etc. Formal processes wouldn't have been necessary if managers had been competent.
Berkun is 20 years late. He's telling managers what they should have done. Now the process
tells them the same things in excrutiating detail.
>
>Something was said about paying the piper and calling the tune long before
>Babbage's Analytical Engine was dreamt-of, as well.
>
>
>'(A) central feature of formal process'... Mr Wagner, some people might
>say that this is antithetical to progress,
The foundations of formal processes are basics that managers should have known without
being told. There are two main criticisms, both unfounded:
1. It prevents incremental development, i.e. making changes on the fly based on feedback.
That was done on purpose. It prevents feature creep and forces organizations to plan
BEFORE cranking code. We all know the undisciplined programmer mode, which wants to start
writing code immediately.
2. It is excessively burdensome; it kills productivity by turning programmers into paper
pushers.
Only in organizations that fight it, or haven't figured out how to do it efficienetly. The
right way is to turn the paperwork over to process specialists or low paid interns. The
benefit is in the controls, not the paperwork.
A valid criticism of formal processes is that they're not scalable to small organizations.
In a shop having 1 (you) to 20 developers, the manager needs to apply Berkun's ideas in an
informal way. If he or she thinks like a programmer, nothing great or even good will be
accomplished. They'll forever be solving yesterday's problems rather than tomorrow's.
>with RAD
>two-coders-to-a-keyboard programming and JIT implementation of features
>that weren't thought of back when someone said 'wouldn't it be nice if we
>could...' and other aspects of Modern Design.
Some blame the proliferation of methodologies on immaturity of the computer industry.
Gimme a break. We've been cranking code for more than 50 years.
Some hope for a magical solution from the computer itself. Application generators appeal
to that idea. We learned nothing from the failure of CASE tools in the '70s. Generators
keep popping up like weeds. Their supporters are programmer types, who think every problem
can be solved with code.
Interpreters are a variation on the code generator theme. Rather than explicitly
generating code up front, they generate equivalent decision processes on the fly at
execution time. It's not apparent they're generating code because they don't spit it out,
they just execute it. OO is another attempt to disguise interpretive code as real code.
Formal processes don't rule out that mode of design. They say it should be done with
prototyping tools during the DESIGN phase rather than the programming phase.
>Centralised, formal processint... what comes next, requests for User
>Sign-Off?
Some see User Sign-Offs as ass covering. No, it corrects abuses that occurred during the
undisciplined '70s, when systems were forced on users without any feedback. Users need to
be involved in high level planning and final verification (UAT).
Some think the programming act should be so transparent that users are involved there, as
well. I remember sitting with an accountant, an honest to god bean counter, and having to
explain line for line what my changes to an assembly language program were doing. It was
surreal. He was befuddled and I kept wondering why the process was wasting both of our
time.
| |
|
| In article <re31n3lbpvdvr9vsdr82j1ieavsor2a9ub@4ax.com>,
Robert <no@e.mail> wrote:
>On Mon, 24 Dec 2007 12:56:06 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>Before 1980, IT shops were managed intuitively like factories, retail
>stores and offices. You imply they still are.
Since 1980, IT shops I have worked in still seem to maintain some kind of
link, however tenuous, between 'do what is asked of you' and 'get paid'.
>Small and some medium sized shops still are,
>but not big
>organizations.
Wow... in big organisations there's no link between doing what's asked of
you and getting paid? Such a Brave New World!
>
>The informal approach was found to be unreliable because it depended on
>managerial skills.
>It was replaced in the '80s and '90s by formal methodologies such as
>CMM, ISO9000, SDLC,
>etc. Formal processes wouldn't have been necessary if managers had been
>competent.
Acronym of the W might have been received a bit differently were that
to have been the case, as well.
[snip]
[snip]
[color=darkred]
>The foundations of formal processes are basics that managers should have
>known without
>being told. There are two main criticisms, both unfounded:
>
>1. It prevents incremental development, i.e. making changes on the fly
>based on feedback.
>
>That was done on purpose. It prevents feature creep and forces
>organizations to plan
>BEFORE cranking code. We all know the undisciplined programmer mode,
>which wants to start
>writing code immediately.
I barely know what *I* know, Mr Wagner, let alone anyone else... but I
recall seeing a single-panel cartoon of a fellow looking at several
desks'worth of coders captioned 'All right... now all of you get busy
programming while I go off and find what the user wants'.
Mr Wagner, in the few snippets above you've managed to question the
competence and capabilities of Managers - who did not know What They
Should Have Known - and Programmers - who want to code without any prior
planning - and there's a good possibility that in the next few snippets
you'll most likely cast a few aspersions towards the Executives, the
Organisations they head, the Governments under which said Organisations
are chartered and the Forces of Nature which shape the globe on which they
all exist.
It is a difficult and complex world to live in... but hey, if it were easy
then *everyone* would be doing it.
DD
| |
| Robert 2007-12-26, 3:55 am |
| On Tue, 25 Dec 2007 20:09:30 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <re31n3lbpvdvr9vsdr82j1ieavsor2a9ub@4ax.com>,
>Robert <no@e.mail> wrote:
>
>Since 1980, IT shops I have worked in still seem to maintain some kind of
>link, however tenuous, between 'do what is asked of you' and 'get paid'.
I've never heard of anyone being denied pay for an hour spent at work.
>
>Wow... in big organisations there's no link between doing what's asked of
>you and getting paid? Such a Brave New World!
In big organizations there is more clarity in communicating what is being asked. It used
to be communicated verbally, scribbled on a napkin or written on a whiteboard.
>
>Acronym of the W might have been received a bit differently were that
>to have been the case, as well.
>
>[snip]
>
>
>[snip]
>
>
>I barely know what *I* know, Mr Wagner, let alone anyone else... but I
>recall seeing a single-panel cartoon of a fellow looking at several
>desks'worth of coders captioned 'All right... now all of you get busy
>programming while I go off and find what the user wants'.
>
>Mr Wagner, in the few snippets above you've managed to question the
>competence and capabilities of Managers - who did not know What They
>Should Have Known - and Programmers - who want to code without any prior
>planning -
I didn't impose a formal process. Your charge should be directed at the executives who
did.
>and there's a good possibility that in the next few snippets
>you'll most likely cast a few aspersions towards the Executives, the
>Organisations they head, the Governments under which said Organisations
>are chartered and the Forces of Nature which shape the globe on which they
>all exist.
We already have an excess of commentary on politics and religion.
>It is a difficult and complex world to live in... but hey, if it were easy
>then *everyone* would be doing it.
The world is unnecessarily complex. For example, the fine structure constant is set at
7.297352..E-3. Where did that number come from? It should be e**2 E-3 = 7.389056...
We can compute e to any precision we want as (1 + 1/n)**n, where n is any large number.
There is no way to compute the fine structure constant.
The increase is only 1.25%. If we increase the gravitational coupling constant by the same
percentage, thereby maintaining the same ratio, formation of carbon and other heavy
elements will not change at all. Better yet, let's change it from 1.752 E-45 to 1.7725,
the square root of pi.
To whom do I write about cleaning up these obvious design errors?
| |
|
| > Berkun is 20 years late. He's telling managers what they should have done. Now the process
> tells them the same things in excrutiating detail.
For some, sure. For others, namely all the web folk, they haven't made
those mistakes yet (though their ignorance of software history, often
a blessing, sets them up to be personally acquainted with them soon).
If there's anything in my book that's of value to this thread, it's
the essential need of trust for good work to happen. The growth and
protection of trust between any two people working together is really
all that any programmer or manager on a team ever has. Most of the
process rubbish I see is an attempt to replace the manager's
responsibility for building trust with rules that try to prevent
mistrust from happening - but the side-effects (lack of empowerment,
the fleeing of bright mavericks, committees and their Kafka-esque
meetings, general massacring of passion) are nearly always worse than
the problems the process was intended to solve. And when the process
fails, process-mongers always blame the process and start hunting for
a new one, instead of examining their basic incompetencies as managers
or leaders of people.
Given the choice between A) a team of people that trust each other,
but have no awareness of formal process, vs. B) a team that has
memorized every software process guidebook ever, but have no faith in
each other, and I'll take A every time. Their relationships will allow
them to build whatever process they need and grow. Team B, despite
their individual talents and process knowledge, is doomed.
Sure - I like team C (a team that trusts each other *and* understands
the value of lean, well crafted processes), but they're less fun to
argue about :)
-Scott
www.scottberkun.com
| |
|
| In article <0ib3n3t2iesnt3dh3gn8435flb4nthlpms@4ax.com>,
Robert <no@e.mail> wrote:
>On Tue, 25 Dec 2007 20:09:30 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>I've never heard of anyone being denied pay for an hour spent at work.
I've heard rather often of people being denied the chance to spend hours
at work because they have not done what is asked of them... but perhaps
our experiences are different.
>
>
>In big organizations there is more clarity in communicating what is
>being asked. It used
>to be communicated verbally, scribbled on a napkin or written on a whiteboard.
In the large organisations for which I have consulted, Mr Wagner, once
again our experiences are different... someone High Up issues a dictum,
someone a bit less High Up sends out a memo, someone yet a bit less High
Up does some scrawling... and the projects continue apace. It may be
otherwise, elsewhere.
[snip]
>
>I didn't impose a formal process. Your charge should be directed at the
>executives who did.
Mr Wagner, some folks get to sit in corner offices and issue dicta, some
folks get to scrawl things on whiteboard and pray they don't hear 'I know
that's what I told you but it's not what I want!'... t'was e'er thus,
perhaps you learned, somewhere, the acronym RHIP.
[snip]
>To whom do I write about cleaning up these obvious design errors?
From
<http://groups.google.com/group/comp...56?dmode=source>
--begin quoted text:
Attributed to Alfonso X (The Wise) of Spain: 'Had I bben present at the
creation I would have given some useful hints for the better ordering of
the universe.'
--end quoted text
DD
| |
|
| In article <5a925c42-b4ac-43e6-b7d5-0c5857eb35ba@t1g2000pra.googlegroups.com>,
Scott <info@scottberkun.com> wrote:
[snip]
>Most of the
>process rubbish I see is an attempt to replace the manager's
>responsibility for building trust with rules that try to prevent
>mistrust from happening - but the side-effects (lack of empowerment,
>the fleeing of bright mavericks, committees and their Kafka-esque
>meetings, general massacring of passion) are nearly always worse than
>the problems the process was intended to solve.
I'm not sure what you're calling 'process rubbish' here, Mr Berkun... but
I've worked on few sites where programmers have told me that telecommuting
was discussed and turned down because the managers decided that without
being able to count nostrils and recta they would not be able to tell if
the work was actually getting done.
Nobody - at least nobody whose view held sway during the considerations
of telecommuting - appears to have said 'How about... 'we know the work is
getting done by the reaching of goals and milestones, just the way we do
now but without actual bodies around.'
>And when the process
>fails, process-mongers always blame the process and start hunting for
>a new one, instead of examining their basic incompetencies as managers
>or leaders of people.
Mr Berkun, sociologists have said that members of (group) will (up to a
point) protect their own at the expense of others; there's not much new
under that particular sun.
I recall reading... something, an article, an editorial, a letter to the
editor, a few decades back, written by a programming consultant about Why
He Does What He Does. He reported that shortly after he finished his
apprenticeship (2 - 5 years' worth of coding experience, give or take a
hair) his manager took him into the Corner Office and offered him a chance
to don the Mandarin's Cap and become... a Manager.
The author begged off, saying that he enjoyed writing programs and would
rather stick with being technical... and the response was a sneered
'Technical? You want to be *technical*? You don't understand...
technical people are given things by management; management gives
things... to itsself.'
The manager could not understand why anyone would not like to be Just Like
Him (a function of identification with a 'we-group'... I think Durkheim
mentioned something along these lines). The author concluded that the
culture of the organisation favored management and that he was committing
a kind of career suicide; if you are offered a chance to become a part of
management and turn it down then you might as well be asking for a
transfer to the mailroom.
The only alternative he saw that allowed him to reach middle age and do
something that he did well and loved doing was... to become a consultant,
going from site to site and cutting himself off from the identifying
lifeblood of any particular company.
'In the complex recipe of personnel ingredients that makes up Bumpfco
we value all contributions highly... but if you want to get beyond a
certain wage grade then you have to be iceberg lettuce, period.'
DD
| |
| Robert 2007-12-26, 6:56 pm |
| On Wed, 26 Dec 2007 01:35:07 -0800 (PST), Scott <info@scottberkun.com> wrote:
>Given the choice between A) a team of people that trust each other,
>but have no awareness of formal process, vs. B) a team that has
>memorized every software process guidebook ever, but have no faith in
>each other, and I'll take A every time. Their relationships will allow
>them to build whatever process they need and grow. Team B, despite
>their individual talents and process knowledge, is doomed.
Building trust is more difficult when the workers are thousands of miles away and the
manager's main qualification is ability to speak Hindi.
Thanks for the reply.
| |
| Robert 2007-12-26, 9:56 pm |
| On Wed, 26 Dec 2007 14:03:35 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <0ib3n3t2iesnt3dh3gn8435flb4nthlpms@4ax.com>,
>Robert <no@e.mail> wrote:
>
>Mr Wagner, some folks get to sit in corner offices and issue dicta, some
>folks get to scrawl things on whiteboard and pray they don't hear 'I know
>that's what I told you but it's not what I want!'... t'was e'er thus,
>perhaps you learned, somewhere, the acronym RHIP.
I don't see how Brookhaven's Relativistic Heavy Ion Physics lab has any bearing on
programming management.
>
>From
><http://groups.google.com/group/comp...56?dmode=source>
>
>--begin quoted text:
>
>Attributed to Alfonso X (The Wise) of Spain: 'Had I bben present at the
>creation I would have given some useful hints for the better ordering of
>the universe.'
>
>--end quoted text
You previously quoted Alfonso in defense of GO TO. I used to think being the Go To Person
was a good thing. Now I see it means 'programs like they did in 1252.'
| |
|
| In article <2ip5n35fa7uj8m6jt3gfjd2ggqu6h9f6bg@4ax.com>,
Robert <no@e.mail> wrote:
>On Wed, 26 Dec 2007 14:03:35 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>
>I don't see how Brookhaven's Relativistic Heavy Ion Physics lab has any
>bearing on
>programming management.
Good thing you weren't asked to, eh?
>
>
>You previously quoted Alfonso in defense of GO TO.
With a bit of skill and insight one can use the same alphabet to write
both COBOL and poetry, as well.
DD
| |
| Robert 2007-12-27, 3:55 am |
| On Thu, 27 Dec 2007 01:43:30 +0000 (UTC), docdwarf@panix.com () wrote:
>With a bit of skill and insight one can use the same alphabet to write
>both COBOL and poetry, as well.
It is difficult to write Cobol in metered form i.e. blank verse. I've tried. Consider
PERFORM (foo) in iambic tetrameter. Foo would need six syllables, which would probably
exceed the 30 character limit. One could use caesura, placing two statements on the same
line, but then it wouldn't look like Cobol.
| |
| Arnold Trembley 2007-12-27, 3:55 am |
| Robert wrote:
> On Wed, 26 Dec 2007 14:03:35 +0000 (UTC), docdwarf@panix.com () wrote:
> (snip)
>
> I don't see how Brookhaven's Relativistic Heavy Ion Physics lab has any bearing on
> programming management.
Perhaps I will be writing something that everyone else already knows.
I believe DocDwarf is a former military man (whose parents were
married to each other), and although I have never had the honor of
serving it is my understanding that in that environment RHIP would
mean "Rank Hath Its Privileges".
With kindest regards,
--
http://arnold.trembley.home.att.net/
| |
|
| In article <2ib6n314knm2fi25afnmj06vv4j9dlhmne@4ax.com>,
Robert <no@e.mail> wrote:
>On Thu, 27 Dec 2007 01:43:30 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>
>It is difficult to write Cobol in metered form i.e. blank verse.
If it were easy, Mr Wagner, then *everyone* would be doing it... to borrow
a phrase from Walt Kelly: haven't a few folks here claimed that COBOL
doesn't get much blanker than what I've blunk out at them?
DD
| |
|
| In article <2rHcj.82040$MJ6.80050@bgtnsc05-news.ops.worldnet.att.net>,
Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
>Robert wrote:
>any bearing on
>
>Perhaps I will be writing something that everyone else already knows.
> I believe DocDwarf is a former military man (whose parents were
>married to each other), and although I have never had the honor of
>serving it is my understanding that in that environment RHIP would
>mean "Rank Hath Its Privileges".
Mr Trembley, I'm sure folks are grateful that you've supplied my intended
use instead of Mr Wagner's 'Hey, I can find a list of acronyms!'
offering... then again, I'm probably sure of other things that I'm sure
folks find to be utterly ridiculous.
Season's Greets to you 'n your'n.
DD
| |
| Howard Brazee 2007-12-27, 6:56 pm |
| On Wed, 26 Dec 2007 14:25:58 +0000 (UTC), docdwarf@panix.com () wrote:
>I'm not sure what you're calling 'process rubbish' here, Mr Berkun... but
>I've worked on few sites where programmers have told me that telecommuting
>was discussed and turned down because the managers decided that without
>being able to count nostrils and recta they would not be able to tell if
>the work was actually getting done.
>
>Nobody - at least nobody whose view held sway during the considerations
>of telecommuting - appears to have said 'How about... 'we know the work is
>getting done by the reaching of goals and milestones, just the way we do
>now but without actual bodies around.'
But I've also worked where telecommuting was allowed, with such
criteria used.
I remember in AFROTC, every term a new student was boss - and normally
did a reorg.
....
[color=darkred]
>The author begged off, saying that he enjoyed writing programs and would
>rather stick with being technical... and the response was a sneered
>'Technical? You want to be *technical*? You don't understand...
>technical people are given things by management; management gives
>things... to itsself.'
>
>The manager could not understand why anyone would not like to be Just Like
>Him (a function of identification with a 'we-group'... I think Durkheim
>mentioned something along these lines).
Isn't that the nature of man? Look at all of the Righteous wars we
have because the other guys don't want to be Just Like Us? Jews
were hated because they wouldn't recognize that our way was best.
Sunni vs Shiite or Protestant vs Roman Catholic are like that. Even
homosexual bashing is pretty much the same thing.
My way is right - therefore all proper thinking people should want to
do things my way.
| |
|
| In article <mqf7n31pktfs95tove24e298eoufh8ommu@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Wed, 26 Dec 2007 14:25:58 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>But I've also worked where telecommuting was allowed, with such
>criteria used.
This, perhaps, might assist Mr Berkun in describing 'process rubbish'...
or it might not; his response has yet to be seen.
[snip]
>
>Isn't that the nature of man?
That I cannot say, Mr Brazee... I've found these human-being type folks to
have strange, inconsistent and unpredictable behaviors. Maybe that's why
I've only read sociology and never worked in the field, instead making my
living as a COBOL-codin' fool.
DD
| |
| Pete Dashwood 2007-12-27, 6:56 pm |
|
<docdwarf@panix.com> wrote in message news:fl0go0$nq6$1@reader2.panix.com...
> In article <mqf7n31pktfs95tove24e298eoufh8ommu@4ax.com>,
> Howard Brazee <howard@brazee.net> wrote:
>
> This, perhaps, might assist Mr Berkun in describing 'process rubbish'...
> or it might not; his response has yet to be seen.
Given that Mr. Berkun is not a contributor to this thread and what has been
quoted here is simply selective extracts from his book, chosen by Robert,
it may be some time before there is a response from him...
I see no practical point in discussing his opinions unless he is present and
able to defend or explain them. To do less simply means a discussion on
other people's opinions of what he wrote; a bit like priests discussing Holy
Writ, and exactly as useful...
A productive discussion would be based on the opinions of those discussing,
without requiring comment from someone not involved in the discussion.
But it has been some time since there was a productive discussion in CLC...
:-)
Pete.
--
"I used to write COBOL... now I can do anything."
| |
|
| In article <5titciF1e2il7U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
><docdwarf@panix.com> wrote in message news:fl0go0$nq6$1@reader2.panix.com...
>
>Given that Mr. Berkun is not a contributor to this thread and what has been
>quoted here is simply selective extracts from his book, chosen by Robert,
>it may be some time before there is a response from him...
>
>I see no practical point in discussing his opinions unless he is present and
>able to defend or explain them.
Mr Dashwood, perhaps in all the rush you missed
<http://groups.google.com/group/comp...73?dmode=source>
and to which I responded with the abovequoted section beginning with 'I'm
not sure what you're calling 'process rubbish' here, Mr Berkun...'
It seems that he put in an appearance... whether there will be more or not
remains to be seen.
DD
| |
| Pete Dashwood 2007-12-27, 9:56 pm |
|
<docdwarf@panix.com> wrote in message news:fl1i78$722$1@reader2.panix.com...
> In article <5titciF1e2il7U1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> Mr Dashwood, perhaps in all the rush you missed
> <http://groups.google.com/group/comp...73?dmode=source>
> and to which I responded with the abovequoted section beginning with 'I'm
> not sure what you're calling 'process rubbish' here, Mr Berkun...'
>
> It seems that he put in an appearance... whether there will be more or not
> remains to be seen.
>
> DD
Thanks Doc,
I didn't see that post and it didn't show up in my mail reader.
I have since re-loaded the thread and it now shows.
I'll read his book before commenting further... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
|
|
|
|
|