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.
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.
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).
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.
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.
Without finding a way to interest the less-motivated people, 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.
> 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.
This says a lot about the attitude of management towards the turnover
problem. It says that they don't want to solve it.
> 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. :)
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).
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).
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.
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.
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.
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.
Robert.
--
"Software is too expensive to build cheaply"
Robert Watkins http://twasink.net/ [EMAIL PROTECTED]
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/
