Peopleware poll
ysbr
1. Have you read DeMarco and Lister's "Peopleware"?
2. Did you pass it on to your superior(s)?
3. (if Yes on 2.): How did your superior(s) react to it?
-ysbr
Frank
"ysbr" <ar...@barfle.gloop> schreef in bericht
news:uim9fva...@corp.supernews.com...
ysbr
>
> What do you seek?
Anecdotes from peers, an idea how typical IT managers would react to the
contents of this book. I am hopeful that there are positive stories to
tell as well as the negative.
The reason I'd like to know is that I've tried this, and to answer my own
questions, I got:
1.Yes
2. Yes
3. No reaction at all.
which I find both unsettling and disappointing. I'd rather have a big
bawl "Shaddup!" than silence.
-ysbr
Robert Klemme
ysbr schrieb:
>
> Three questions:
>
> 1. Have you read DeMarco and Lister's "Peopleware"?
yes
> 2. Did you pass it on to your superior(s)?
yes, to one.
> 3. (if Yes on 2.): How did your superior(s) react to it?
found it interesting but did not support all positions that
DeMarco and Lister present. don't remember exactly which
positions that were because it's quite some time since. we don't
have seen too many practical reactions to this.
robert
ysbr
> don't remember exactly which positions that were becaus
> e it's quite some time since. we don't have seen
> too many practical reactions to this.
How about:
- "Quality is free - for those who want to invest heavily in it"
- measuring work done in brain-time rather than body-time
- overtime leads to undertime
etc.?
-ysbr
Frank
> 2. Did you pass it on to your superior(s)?
No. In fact, my boss gave me the book.
> 3. (if Yes on 2.): How did your superior(s) react to it?
Not applicable.
To be honest, I don't believe in passing on a book to superiors.
I have spent many years trying to pass (or shall I say push) on good ideas
and experience, and in most cases it just gave me headaches. A more
effective way to educating others is by living according to your own rules
and show people that those principes work. If they don't see it, they are
very hard to convince. If they see it, there is no need to convince them.
You can bring a horse to the water, but you can not make it drink.
The book "Peopleware" is a good book. Together with "7 Habits" is more or
less is the basis of my attitude in work and to an extent in living.
Frank.
ysbr
>
> You can bring a horse to the water, but you can not make it drink.
Very true, as I am finding out the hard way nowadays <g>
-ysbr
David B Lightstone
"ysbr" <ar...@barfle.gloop> wrote in message
news:uir6s44...@corp.supernews.com...
Does this mean that the moral of the story is - methodology is not the problem
mismanagement is?
ysbr
>
> Does this mean that the moral of the story is - methodology is not the
Both are, depending on which perspective you take. Far too many managers
are clinging hard to their 'system' (learnt in MBA school!) and forget
that their primary task should be to coach their people to enjoy their
work and hence make successful products. That having an effective,
spirited, motivated team is 100% more valuable to the company, than any
"Big M" Methodology you can come up with.
-ysbr
David B Lightstone
"ysbr" <ar...@barfle.gloop> wrote in message
No sense in beating a dead horse. You win wars by knowing the applicable
strategies. No follow up necessary. We disagree big time.
>
>
>
ysbr
>
> No sense in beating a dead horse. You win wars by knowing the
> applicable strategies. No follow up necessary. We disagree big time.
Did it occur to you that a team of software engineers cannot be commanded
around like soldiers? I like to think for myself. I want my boss to
support my thinking for myself. I don't want my boss to treat me as a
robot.
Sticking to mechanistic strategy/methodology, instead of encouraging your
people to add their brainpower to yours, is the worst kind of
mismanagement you can commit, IMO.
-ysbr
David B Lightstone
"ysbr" <ar...@barfle.gloop> wrote in message
You get the last word. No sense in beating a dead hourse, let is slide
>
> -ysbr
>
>
>
Ron
> Both are, depending on which perspective you take. Far too many managers
> are clinging hard to their 'system' (learnt in MBA school!) and forget
> work and hence make successful products.
No offense, but the only managers that I know who agree with this are naive
and have very poor management skills. A few were at the helm of dot
bombs...
It's a issue of priorities and causality. My opinion - managers are
responsible for the success of the people (and processes and deliverables)
they manage. Success does not necessarily follow from how well employees
enjoy their work, but the odds of success are certainly far better...
Inexperienced employees need far more coaching on how to be successful than
how to enjoy work. And then there are the employees who enjoy undermining
others' successes more than being successful themselves...
(And, yes, I've given copies of Peopleware to managers where I work. It was
much better received when I was their peer or superior, than when they were
my superior or when I gave it to them anonymously...)
- Ron Zeno
Zed**3
I have read it, more than once, and keep a spare copy
in the office available for anyone who might be interested. I also
keep spare copies of the Santa Teresa report.
On a few occasions I have recommended it to management. It may have
had a small positive effect in a few cases.
One example: A few years ago I worked at a small company that was
really a good place to work for. They were at least partially
"Peopleware compliant", but not without faults. The phone paging
system was a constant annoyance. Many of the developers complained
about it. I quoted passages from Peopleware in arguing to get
rid of it. When we finally got rid of it the company president
quoted the passage from Peoplware in the newsletter making the
announcement.
How much weight the Peopleware quote had compared to the general
level of complaints, I don't know. It was at least noticed. But it
took several years and a new phone system to make that one small change.
I have doubts about how effective such a book can be. After a
few years in software development it appears to me that management,
at least higher level management in large companies ( > ~100) tends
to think of software developers as expensive typists. Thus the
cubicles with enough room to sit at a keyboard, but no consideration
for the fact that HVAC system may sound like a hurricane and make the
desk vibrate or one's office mate uses the speaker phone on LOUD.
If you want a better work environment, I think you have to go out
and find it. Changing the culture of your current employer is likely
to be an exercise in futility.
If you find a Peopleware compliant employer let us know. A lot of
developers are looking for one. The only ones I know anything
about no longer exist. Not because they went out of business, but
because were overall well managed and profitable. This led to
a buyout by a big company with no interest in maintaining the culture
of the small one.
ysbr
>
> You get the last word. No sense in beating a dead hourse, let is slide
Such gallantry... thank you <g>.
-ysbr
ysbr
>
> No offense, but the only managers that I know who agree with this are
> naive and have very poor management skills.
What is your definition of 'management'? Do they comply with the
"peopleware" definition of management?
> A few were at the helm of dot bombs...
That makes sense, because many dotcoms were started by young people who
saw a shot at a fast track to lots of money. These young people were
hardly removed in years or experience from the 'work floor', and it is at
this level where 'peopleware' has the biggest impact (after all, the book
is a criticism of management in favor of workers).
> It's a issue of priorities and causality. My opinion - managers are
> responsible for the success of the people (and processes and
deliverables)
> they manage. Success does not necessarily follow from how well
> employees enjoy their work, but the odds of success are certainly
> far better...
So the conclusion is? You'd want to 'empower' your people as much as
possible, to feel they are making unique and invaluable contributions to
the product, the team and the company. A healthy job satisfaction would
seem essential in fostering such motivation.
> Inexperienced employees need far more coaching on how to be successful
> than how to enjoy work.
This is true. But it is a minor exception, since people rarely stay
inexperienced for very long.
> And then there are the employees who enjoy undermining
> others' successes more than being successful themselves...
Ah yes, but within a well groomed corporate culture and a well knit team,
there would be no room for such behavior.
> (And, yes, I've given copies of Peopleware to managers where I work.
It was
> much better received when I was their peer or superior, than when they
were
> my superior or when I gave it to them anonymously...)
I can imagine!
thanks for your feedback,
-ysbr
ysbr
> I have read it, more than once, and keep a spare copy
> in the office available for anyone who might be interested.
<impressed!>
> I also keep spare copies of the Santa Teresa report.
The *what* report? I tried googling for "Santa Teresa Report" but could
not come up with anything obviously relevant.
> When we finally got rid of it the company president quoted
> the passage from Peoplware in the newsletter making the
> announcement.
Cool!
> If you want a better work environment, I think you have to go out
> and find it. Changing the culture of your current employer is likely
> to be an exercise in futility.
Hmmmm. :-(
> If you find a Peopleware compliant employer let us know.
> A lot of developers are looking for one. The only ones I
> know anything about no longer exist. Not because they
> went out of business, but because were overall well managed
> and profitable. This led to a buyout by a big company with
> no interest in maintaining the culture of the small one.
Argh! What if you're right? Damn!
So, the trick is to find a small, Peopleware'ish place that consciously
donates its profits to charity so as not to seem /too/ successful and be
gobbled by a bigger fish. <g>
-ysbr
ysbr
>
> Don't assume that you're the first person who has had
> the *opportunity* to read Peopleware.
Maybe not, but it does *look* like I'm the only one so far who read it
and appreciated it. (in my company)
> You're probably not going to convince people with more
> experience than yourself to change their actions based on
> something you read in a book.
Well, how about the fact that myself (a senior engineer) and several of
my colleagues are quite dissatisfied with the current practices and would
want to change the way things are done, peopleware style?
> Patience. You can't affect change while you're the low man on the
> totem pole. No matter how much you know that you're right and
> everybody else is wrong.
<g> Noted.
thanks for your feedback,.
-ysbr
David B Lightstone
"ysbr" <ar...@barfle.gloop> wrote in message
You are welcome, ron
Zed**3
ysbr <ar...@barfle.gloop> wrote:
>"Zed**3" wrote
[...]
>
>The *what* report? I tried googling for "Santa Teresa Report" but could
>not come up with anything obviously relevant.
>
It's refered to in Peopleware. See chapter 9 (page 53) and the bibliography
under "McCue, 1978".
Although dated in a few details (e.g., concern for storing punched cards),
they get most of the essentials concerning office facilities for
developers right. Like Peopleware it is pretty much unknown or ignored
and developers are placed in those awful Dilbertesque cubes.
[...]
>So, the trick is to find a small, Peopleware'ish place that consciously
>donates its profits to charity so as not to seem /too/ successful and be
>gobbled by a bigger fish. <g>
>
Not quite. The company was not publically traded. The owners could
have kept it indefinitely. They built a company with the idea of
providing high quality software development and a good place to work.
But after quite a few years at it they decided to cash out. When
someone with a lot of venture capital came along they decided they
would rather have 7 digit bank accounts than be running a company.
Zed**3
ysbr <ar...@barfle.gloop> wrote:
[...]
>
>Well, how about the fact that myself (a senior engineer) and several of
>my colleagues are quite dissatisfied with the current practices and would
>want to change the way things are done, peopleware style?
>
Cultures, in a company or a country, tend to be quite stable no
matter how dysfunctional. It is hard to say what you could do to
improve your situation without knowing a lot of details about it.
But, most likely, any improvement is going to take major long term
efforts on your part if it can be done at all.
Considering that there are several of you, have you considered
starting your own company? This may be a bad time to do that,
but it might be a good time to start planning. I have considered
it myself, but have no skills in sales which is rather essential
for having a business.
ysbr
>
> It's refered to in Peopleware. See chapter 9 (page 53) and the
> bibliography under "McCue, 1978".
ah, thanks!
> they decided they would rather have 7 digit bank accounts
> than be running a company.
tough choice, tough choice. <g>
ysbr
>
> Considering that there are several of you, have you considered
> starting your own company? This may be a bad time to do that,
> but it might be a good time to start planning. I have considered
> it myself, but have no skills in sales which is rather essential
> for having a business.
Now that rings a bell!
Unfortunatley, the best salesperson I know is my
(not-so-peopleware-minded) manager. He could probably sell me an ice
cream on the North Pole.
-ysbr
Zed**3
ysbr <ar...@barfle.gloop> wrote:
[...]
>So, the trick is to find a small, Peopleware'ish place that consciously
>donates its profits to charity so as not to seem /too/ successful and be
>gobbled by a bigger fish. <g>
>
Another comment on what to look for. You need to consider a company's
time horizon. Peopleware describes a work environment for an employer
that expects to be around for a long time and have low employee
turnover. A couple of years ago as the Internet bubble was expanding,
companies were hiring at a furious rate. But the time horizon was short:
start a dot.com, hire a bunch of developers, sell whatever, have an IPO,
get rich.
With all the hiring going on you might have expected working conditions
for developers to improve. But in the small part of the software
development world that I am familiar with things got worse. If you
wanted to work real hard for a couple of years and make enough to
retire young, you might have been happy with the situation. If you
were looking for a long term career in software development, there
weren't many possibilities.
Andrew Gabb
> "ysbr" <ar...@barfle.gloop> wrote:
>
> >Three questions:
> >
> >1. Have you read DeMarco and Lister's "Peopleware"?
> >
> >2. Did you pass it on to your superior(s)?
>
> experience than yourself to change their actions based on something you read
> in a book.
>
> pole. No matter how much you know that you're right and everybody else is
> wrong.
Getting people to change their ways for the better (or otherwise)
normally involves understanding how they think, and having good
communication skills.
Managers who don't understand their workers and/or have poor
communication skills are bad managers and will have difficulty
succeeding for a number of reasons (even though some have skills
which can make failure seem like success or at least someone else's
fault).
Developers who don't understand how their managers think may be good
developers but have little chance of changing their managers'
attitudes or approach. The developers may even be wrong in thinking
the managers are wrong. Arrogance can lead to deafness.
I've often found that changing management's views is relatively
straightforward - you simply ensure (not assume) that you're right,
and that your argument is pitched at *their* benefits, penalties,
risks and opportunities, rather than your own. If you can't do that,
you might as well forget it. Oh, and I've had some rather notable
failures, of course, one of which resulting in me jumping ship.
Andrew
--
[Canberra 15-19 Jul Ph:02 626-55941(temp), AH:02 6297-5531]
Andrew Gabb
email: ag...@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----
Zed**3
Andrew Gabb <ag...@tpgi.com.au> wrote:
[...]
>I've often found that changing management's views is relatively
>straightforward - you simply ensure (not assume) that you're right,
>and that your argument is pitched at *their* benefits, penalties,
>risks and opportunities, rather than your own. If you can't do that,
>you might as well forget it. Oh, and I've had some rather notable
>failures, of course, one of which resulting in me jumping ship.
>
Could you provide a couple of examples of successes, please?
Peopleware is about corporate culture and I can't imagine any
significant shifts that an individual developer could successfully promote.
A. Reed Mihaloew
ysbr wrote:
>
> "Zed**3" wrote
> > I have read it, more than once, and keep a spare copy
> > in the office available for anyone who might be interested.
>
> <impressed!>
>
> > I also keep spare copies of the Santa Teresa report.
>
> The *what* report? I tried googling for "Santa Teresa Report" but could
> not come up with anything obviously relevant.
>
"IBM's Santa Teresa Laboratory-Architectural Design for Program
Development", G. M. McCue, 1978. Reprinted in _Software
State-of-the-Art: Selected Papers_, DeMarco and Lister, 1990.
A bit dated, but excellent work...
Reed
> [SNIPPAGE]
Zed**3
>In article <uiu97na...@corp.supernews.com>,
>ysbr <ar...@barfle.gloop> wrote:
>>"Zed**3" wrote
>[...]
>>
>>The *what* report? I tried googling for "Santa Teresa Report" but could
>>not come up with anything obviously relevant.
>>
>
>It's refered to in Peopleware. See chapter 9 (page 53) and the bibliography
>under "McCue, 1978".
>
I should also have mentioned that the paper was published in the
IBM Technical Journal. If you are interested in reading the article
you might find this in the bound journals section of the engineering
library of any nearby university.
I recommend reading it. It is quite an astonishing piece of work.
The architects observed and interviewed software developers and even
made mock up offices in an effort to find the optimum office environment.
What they came up with matches my experience as to what makes for
a good work environment.
An outsider might wonder what the big deal is, but as most readers
of this newsgroup know, before the crash many companies were going
to great lengths to hire engineers but the ones that paid any
attention to what it took for them to get their work done was
almost non-existent.
There is one major defect in the report. They don't take noise
into account. This is something that needs to be in the building design
right from the beginning.
Andrew Gabb
OK, one anyway. I was called on to act as firefighter in a project,
where we had committed (and already been paid) to provide very
vaguely specified services/software. The client was reasonable but
confused and distrusting, and I was the second firefighter to turn
up. Not pleasant at first.
My boss at the time was a noted micromanager who I knew would make
matters worse if he got close to this client. I told him I could
guarantee to fix the problem with 80-100 hours work (about 50% more
than budgeted), and if he wished to control the effort, to add
another 40 hours. He said 'go', backed off, and I satisfied the
client. We ended up with another 1500 hours from that client as a
result, immediately after.
If my boss had said to do it for less, I would have told him that
the end result would cost more and lose us a client, I'd have put it
in writing, and asked him to take me off the job.
The point here is that I knew where he was coming from. This problem
had been bugging him for months, and I knew he wanted it fixed
desperately, but he needed a clean, guaranteed solution. I gave him
this, and at the same time got him off my back.
I really don't understand your second sentence. Corporate culture is
about people, and some people have more influence than others, and
it doesn't necessarily depend on their rank. A developer can easily
influence things by pointing out that common problems experienced in
projects are predictable, then showing they're preventable. She can
also find out who *is* influential and talking to them.
I think the most telling point here is that I said 'ensure that
you're right', and most developers don't have the experience or
knowledge to be sure, or to project their ideas into the overall
development process. When management is intransigent, you have to
know a lot more and have better communication skills than otherwise.
Andrew
--
[Canberra 15-19, 23-26 Jul Ph:02 626-55941(temp), AH:02 6297-5531]
Zed**3
Andrew Gabb <ag...@tpgi.com.au> wrote:
>> In article <3D30ED38...@tpgi.com.au>,
>> Andrew Gabb <ag...@tpgi.com.au> wrote:
>> [...]
>> >I've often found that changing management's views is relatively
>> >straightforward - you simply ensure (not assume) that you're right,
>>
>> Could you provide a couple of examples of successes, please?
>
>OK, one anyway. I was called on to act as firefighter in a project,
>where we had committed (and already been paid) to provide very
>vaguely specified services/software. The client was reasonable but
>confused and distrusting, and I was the second firefighter to turn
>up. Not pleasant at first.
Thank you for the example.
I was thinking more of changing the normal way business is
done at a company, but it is still useful to make small changes
for specific tasks if you can do it.
Carl Thronson
> Three questions:
>
> 1. Have you read DeMarco and Lister's "Peopleware"?
>
No. Did you? Would you recommend it?
Zed**3
I have read it and recommend it. If I made up a list of books
every software developer and manager should read, "Peopleware"
would be #1 on the list. MMM would probably be #2.