Hi, Robert,
> -----Original Message-----
> From: Robert Watkins [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 17, 2004 10:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [XP] Joel on Software
>
>
> Kay Pentecost wrote:
> >>The concerns I've got with this are several-fold, but here
> are three:
> >>1) This assumes that the less-skilled developers have more domain
> >>knowledge, and thus know the better way to glue the controls
> >>together. This
> >>is not the case in my organisation at least (not as a blanket
> >>rule, anyway).
> >
> > So that's an invalid assumption on management's case, right?
>
> In general, yes. The idea is meant to be that the "less
> skilled" developers
> are actually developers in other technlogies, and typically
> know the legacy
> applications that are being augmented or replaced. As such,
> they are meant
> to have a good understanding of the domain already.
Supposed to. I worked with a bunch of Cobol programmers who "supposedly"
knew the domain, and they did... but... We were re-creating the program for
Windows/Client Server, and their lack of Windows knowledge held us back. I
got in trouble <grin> for labeling a picture of the GUI with the names for
Combo boxes, list boxes, text boxes so that they wouldn't call everything a
"box" ("the box on the screen is the wrong size."
They did know what the actual users did... but they knew how they did it
with the old system, and were unable to abstract that to the actual tasks.
"Joe types in xxxx, and then copies the yyy to ppp."
>
> The problem is that they don't, in many cases. This is because of the
> development process used before didn't encourage them to
> understand the
> domain; it only encouraged them to build the application as
> specified in
> the detailed design document.
Ah!! Yeah, that wouldn't be helpful.
>
> So, what you end up with is a developer who understands their
> application
> in detail (hopefully!). This makes them appear superficially
> familar with
> the domain, certainly enough to fool their management (who,
> being divorced
> from the business themselves, don't know better... more on
> this later).
Yes. Seems like a lot of our work is going to be educating management.
> However, they don't have the deep understanding which a true
> domain expert
> would have, and this means all they can really do is build the same
> application again.
Yes, that's what would have happened with the COBOL group I mentioned. It
*didn't* happen that way, because the team lead on our group was a Cowboy
Coder who did things his own way. That didn't make the project better.
>
> There are, of course, exceptions to this general statement.
>
> > They're missing a crucial point. People grow as they live. The most
> > motivated will learn a great deal (I use myself as an
> example, modestly
> > enough <grin>) and the least motivated will learn/grow in
> their own way.
> > The most motivated to learn will leave as they get better.
>
> True. It's also true that we have adopted a deliberate policy
> of giving the
> less-skilled developers who show interest the (few) chances
> to work with
> experienced mentors. In some ways, this makes the gap worst;
> we end up with
> a gap of motivated and skilled developers on one side, and
> less-motivated
> and less-skilled developers on the other.
Yes, of course. And it *reduces* motivation for those who aren't perceived
as "motivated."
Learning happens whether it is offered officially (the chance to work with
mentors) or not. The ones who are *not* offered the opportunity to get
official training learn *just as much*... that is, they learn that they can
show up and get paid without putting in (what is perceived as) the extra
effort to *excel*. The rational is "I can get by." Whatever motivation was
there before, whatever energy to excel was there before, gets sublimated...
into something that the person finds more rewarding.
Let me say this a slightly different way... *Every* single person, no matter
how "motivated" they feel, or how "motivated" they are perceived to be (and
those may not be the same)... Every single person gains in a period 100
units of learning.
What goes into those units depends on the person. For one person, it may be
100 Units of "getting better at what they do." They may learn new skills,
new ways to think. For another person, it's also "getting better at what
they do," but not in new ways, but in covering their butt, "getting by" --
in short, whatever they were doing before to be considered less motivated.
So the company is *investing* in training whether the person learns better
skills or "getting by" skills. In one case they get better performers that
help the company be more productive. In the other case, they get worse
performers who block the company from being more productive. Talk about
waste!!
>
> Without finding a way to interest the less-motivated people,
It's my belief that no one can motivate someone else.
It's pretty easy to de-motivate someone... just do something they perceive
as "punishment" when they act on motivation. For example, someone works
late, or a weekend day... and the next day or so is criticised for taking an
extra 15 minutes for lunch... if this happens frequently, working the
*extra* hours becomes a punishment.
> I don't know
> how to solve this. The solution I would be inclined to use
> (gradually push
> them out of the door) isn't one that management wants to use.
My personal opinion is that people who aren't motivated enough to do the
continuous learning and perform to the best of their ability don't belong in
Software Development at all, and pushing them out the door is the best thing
that can happen to them and the company... so I'm with you.
As for solving the motivation problem, the best you can do, IMHO, is avoid
DE-motivating people... and that includes de-motivating the high performers
by keeping on the low performers...
>
> > No matter how much actually training a job offers, some of
> us will get
> > more... and with more training we'll be more valuable...
> and if the company
> > doesn't acknowledge that, we change companies. Every employee is an
> > investment... and the ones who are motivated are the best
> investment...
> > which the ignorant company is going to lose. Why train
> people to work for
> > your competitors?
>
> Actually, that's the argument that management is using
> against _us_! They
> are concerned that investing a lot of money into developer
> training is a
> poor investment, not because it doesn't work, but because
> they aren't the
> ones who get the return. They want to use less-skilled
> people, _even if
> they aren't as effective_, because they don't need as much investment.
AH! but they are greatly lowering any return on investment! When they are
not offered training and advancement, the best producers *leave*, don't
they? The worst ones stay until they are forced out. The return from the
self-trained goes to the next company (where mediocrity hopefully isn't
rewarded -- with security, whatever)... the return from the less-skilled is
*negative* in that not only do they are they less productive, they encourage
the others around them to be less productive, too.
The company is already making an investment: salary, sick leave, annual
leave, holidays, insurance, and whatever stuff they pay for. Everything
people learn about culture and the company's business increases their
individual worth. Not paying for training, even when it means mentoring
from within, means that this asset with a salary of X, and company knowledge
of Y, either gets their own training and leaves (a loss to the company of
X+Y in direct costs and T of future skills from the self training) or they
learn more negative getting-by skills... which might be something like (X+Y)
minus the effect of negative training.
Following here? I'm not real hot with this X and Y business...
>
> This says a lot about the attitude of management towards the turnover
> problem. It says that they don't want to solve it.
Perhaps they see a less-skilled worker leaving as saving them money.
Perhaps they don't see the more productive worker leaving as costing them
money.
>
> > Do you know what management's rational for doing this is?
> And why they are
> > seeming to ignore the successful cases you cited?
>
> There are a number of reasons, in my opinion. They are only
> indirectly
> related to what management is actually saying. :)
Yeah, frustrating, isn't it?
>
> Firstly, we are an internal IT shop for a larger
> organisation. This is a
> bank and insurance company with about 8000 staff. The IT
> section is about
> 800 staff, the vast majority of which are infrastructure,
> operations, and
> other non-developer types. The _developers_ are probably
> about 200-250
> people, all up, most of whom exist to support legacy (but vital!)
> applications such as our core banking and insurance systems
> (mostly COBOL
> beasts). These people are broken up into about 30 sub-teams,
> and have very
> little cross-team communication. There are about 50-60 people
> across those
> teams who are of interest to me in that they either are or
> will soon be
> using Java tools (my own role is limited to advocating for
> Java developers;
> while I do care about the others, I only have so much effort
> to spend).
Aggghh.... I've been there. Not in the position you're in, but in the type
of company. The developers are a cash sink. Not a good place for a caring
developer.
>
> So, for starters, we are a small group, but scattered so we can't
> effectively share knowledge. Many in that group are
> minorities in their own
> teams. There are probably 6-10 senior developers in that
> group; the rest
> fall into the less-skilled section. The two successful teams
> have half of
> the senior people; they are senior, BTW, _because_ of the
> knowledge and
> training they got by working in the successful teams. Effect,
> not cause. So
> the majority of the less-skilled are struggling. Management
> is reluctant to
> commit the senior people to mentoring on the grounds that
> they wouldn't get
> any other work done. Not surprisingly, the senior people we
> do have are in
> high demand.
>
> Because IT is a separate division, there is a disconnect (at
> a management
> operational level) between IT and the rest of the business
> (our customers).
> The business side of the organisation sets priorities,
> largely in the form
> of budgets. IT is essentially given a shoe-string budget to
> handle normal
> operational concerns and minor work (called "business as
> usual" or BAU
> tasks). Most new work is managed as separately funded projects; these
> projects don't have much incentive to committ to long-term activities
> outside of the project such as training. It's no small
> co-incidence, BTW,
> that one of the successful teams has been engaged in a 2-year
> and still
> on-going multi-phase project - a long running project does
> have incentive
> to train. Unfortunately, the vast majority of projects are
> short-term (3-6
> months).
I think this is called Silos, isn't it? Agggh. Not a good way to work.
>
> In short: the business side doesn't really care too much about the IT
> group. To the extent it does care, it focuses on the
> operational folks (the
> help desk, the system adminstrators, the network and telecomm
> guys, and so
> forth), partly because they're the majority. The software development
> people are left out in the cold.
Yes. The operational folks are more visible.
>
> IT's own management is disconnected from the business, and to make it
> worse, they're largely disconnected from their own teams.
> Senior management
> have all been in management roles for most of their careers
> (only a couple
> even had technical roles at the start). Even team leaders
> have typically
> been in management roles for several years. This means that
> management is
> largely unable to assess or nuture their technical staff.
Yes.
>
> The short-term emphasis supplied by projects, budget cycles, and
> performance review cycles discourages longer-term thinking. And the
> turnover situation, which like many companies is worse
> amongst the skilled
> staff, discourages investment in staff that requires a
> long-term to pay
> dividends.
>
> In short: it's a culture problem.
>
> We have been working to change this. But it's slow. And
> vendors coming in
> promising quick fixes don't help. Management that pays little
> attention to
> their own staff seems more than willing to believe a vendor
> who says that
> their latest tool du jour will solve everything. Go figure.
Depressing.
>
> For my own part, I'm taking Martin Fowler's advice and,
> having failed to
> change my organisation sufficently, have decided to change my
> organisation;
> I finish up in about 5 weeks and am moving on to a company
> that will have
> different problems but at least doesn't have these ones.
I wish you luck. And I think you should write up more about your
experiences with this company... maybe someone will be better off for
reading about it.
Kay
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
