Jake's Borland Conference Report, Part III, Remaining Tutorials and Notes on the Perils of Outsourcing

2003-11-10 03:44:45 AM
Jake's Borland Conference Report: Part III
Saturday afternoon I attended the preconference tutorial 1006: UML Basics:
Activity and StateCharts of UML by Karl Frank of Borland. This was an
excellent session. I learned how to use activity and state charts in a more
agile development process, as opposed to state diagrams, etc. as they are
used in the RUP. Karl is one of the few people on this planet that was lucky
enough to be able to study philosophy at the PhD level (and he even looks
scholarly too), and this made his presentation much more interesting, to me
at least. After all, how often do you see the creation myth of Genesis in an
activity diagram? The session was a balanced mix of exposition and exercises,
so that no matter what your preferred learning method, you were covered. This
was easily one of the most intelligent sessions
I have ever attended.
Sunday morning I attended the precoference tutorial 3030: Project Management
for Modern Software Development, Part I, by Timothy Korson. There was a false
fire alarm toward the beginning of the session, but that was not as big a
disruption as you might think. This session was about managing projects under
the new OO methodologies such as RUP. I would have liked it better if it was
geared more toward managing projects under agile processes, but it was
heavily oriented toward RUP. This session was valuable not just for the
details for also for the insight into how managers approach these topics.
This was illustrated by the questions about how we can implement iterative
approaches when executives and managers require up-front estimates and
contracts. It got me thinking that outsourcing is antithetical to agile
processes but quite friendly to RUP and the waterfall method, because of the
front loaded nature of RUP and the waterfall method. When you outsource a
project you need to specify everything in detail in the contract, because the
lines of communication to developers in foreign countries will always be
insufficient. But as managers and executives learn the advantages of agile
processes, this preference for front-loaded methods will fade away, and with
it the preference for outsourcing.
I came across a very good example of how dangerous it is to outsource to
programmers whose primary language is not the same as the customers and end
users in the first tutorial I attended on Saturday morning. There was an
exercise where we were broken down into groups of four to five people to
design a coffee maker. Some of the members of the group were to be customers
and some were to be developers and project managers. In our group, there were
three Americans and two foreigners, one of whom was from Russia. The
customers were the other two Americans and I was in the developer/project
manager group with the two foreigners. The "customers" specified what they
wanted and explained it to us. One of the requirements what that the carraffe
(sp?) must be "no-drip". Well, the guy from Russia very carefully and
meticulously drew an elaborate and quite clever dual-hull filter for the
coffee maker to fill that spec. (We each had a set of specs to fill for the
"customers" and this spec was his to fill) It was very ungenious, but it was
not what had been asked, so it had to be rejected, and it resulted in lost
time to boot. He simply hadn't understood the requirement, though it was
written in plain English. I've seen this same thing happen in the real world
as well. A lot of time and effort is spent getting the requirements and
writing a complete spec, taking the requirements and specifications to an
outsourcer who then seems to understand everything, gets the client to sign
off on the design docs and then goes off and disappears into oblivion for
several weeks or even months while the developers in India or China or Russia
then produce a piece of software that is a perfect fit to their
misinterpretation of the specs. The simple fact of the matter is that people
WILL gets the specs wrong the first few times they create them. Add to this
the fact that non-native speakers of a language very frequently misunderstand
things in that language and you get a recipe for failure in any process that
doesn't allow for daily interaction between the users and the developers.
Outsourcing by it's very nature makes the production of good software nearly
impossible, because it requires heavy front-loading of the requirements and
documentation process and therefore cements these early
In desparation, some outsourcing firms are hiring Americans to act as laisons
between the users and the developers. This is particularly noticeable for
Indian firms. I came across several of these when I was last looking for a
job. But this strategy is still doomed, because there simply are still not
enough lines of communication between the users and the developers.
Which is a perfect segue into the discussion of the final preconference
tutorial I attended on Sunday afternoon: 3036 Agile Database Techniques, by
Scott Ambler. Scott, who seemed dressed for hiking in the jungle, complete
with a hat that indeed resembles a pithe helmut, is very direct and very
strongly opinionated and tells you so up front. I like that and this was
perhaps my favorite session of the conference. One of the things that Scott
kept saying is that if you don't make yourself agile and productive you are
going to get outsourced, an interesting type of motivation. I covered agile
processes in my report on the first tutorial a few days ago, so I'll not
belabor the point again here, except to say that you ignore this methodology
at your own peril, no matter what you think of the personalities that
espouse it.
Next, was the main opening session, which I'll cover in a separate post...
***Free Your Mind***