Welcome to issue #5 of Allen Holub's Sporadic Newsletter.

(c)2003, Allen I Holub. All rights reserved.
You may redistribute this newsletter freely, provided that
you redistribute it in its entirety without modification.

This newsletter is strictly opt in.
Subscribe at   /newsletter
Unsubscribe at /newsletter/opt_out.html
Back issues at /newsletter/archive

-- For Subscribers Only

To access the subscribers-only part of the web site this
month:

	URL:					/subscribers
	User name:				
	This month's password:	

The password changes with every newsletter.

The subscribers-only section contains:

	A Design Patterns Quick Reference.
	IBM's Santa Teresa Study.
	Access to my game-of-life page, discussed below.

-- New Stuff on the Web Site

I'm finishing up a new book on design patterns that will
teach the patterns by actually using them in code. (The
tentative title is "Holub on Patterns: Understanding Design
Patterns by Looking at Code," to be published by apress
(www.apress.com) in a couple of months.

One of the programs I'm analyzing in the book is a
Game-of-Life implementation, and in preparation for
publishing the book, I've set up a Life web page
that you might find interesting. For the time being,
access the page at .
(I'm not going to link the Life page into
the site proper until the book is closer to publication, at
which point the link will migrate over to the software
page.)

The page has a cool game-of-life applet on it (not written
by me), if you've every wanted to play around with the game.

-- Learn about Java "Tiger"

Java's 1.5 (Tiger) release, scheduled for beta in a few
months, incorporates several significant changes to the
language itself. In particular: 

* Constrained types (enums) 
* Generics (sort of like C++ templates) and a "generified"
  collection library. 
* Metadata (user-defined attributes for classes, fields,
  and methods) 
* Primitive-type boxing/unboxing 
* Static imports 
* A "foreach" syntax 
* Variable-length argument lists (and printf) 

Generics, in particular, present an entirely new way of
programming in Java, and are implemented in a completely
different way than C++ templates. Generics are not just
"templates for Java." They are much more capable but
easier to manage. They also incorporate the notion a
"variance," which is entirely missing from C++.

I've put together a set of slides that provide
a lightweight overview of Tiger, which you can
download from the "Course Notes & Slides" page:
.

I've also put together a one-day short course on Tiger.
I'll review all the proposed additions, with emphasis both on
what the feature is good for, and more importantly, on how
using the features incorrectly (or at all) can get you into
trouble and otherwise cause havoc. We'll cover generics — by
far the most involved of the new features — in depth.
I'm considering including a short bring-your-own-laptop hands-on
segment, if you think that's a good idea (write and tell me).

This relatively inexpensive class is a great way to get
on top of the new technology early.

I'll be giving the class in Berkeley on Friday, Sept 19.
Get details at .

If you want to bring your whole team up to speed,
I can do the class in house.

-- Some Ruminations

Linux:

If any of you are worried about SCO's reprehensible attack on
Linux, Frank Hayes did a nice analysis for ComputerWorld
.
He points out, rightly, that if SCO had a leg to stand on they
would have been granted an injunction that prevented IBM from
distributing Linux. Meanwhile, the German government has enjoined
SCO to stop threatening Linux users, and Australia is considering
racketeering charges. It's illegal to demand payment for a
licence that you don't need, then threaten you when you won't
pay.

Outsourcing:

Hayes also has an interesting take on the outsourcing issue

where he points out that the way to compete against the
outsourcers is to provide services that they just can't provide.
By nature, an outsourced project cannot keep up with changing
requirements, so if your shop has an Agile process in place, then
you have an advantage. Outsource just doesn't work in a
changing-requirements environment.

My own thinking on those lines is also centered around process.
Motorola went the CMMI hard-core high-ceremony process route a
few years ago, and the result was an overall productivity
increase of 300%.  (Even more if you just look at coding, which
came together 8 times faster with 80% fewer bugs than before. The
difference between 800% and 300% is the time that they were now
spending in design.) You don't get a 66% cost savings simply by
outsourcing, so it would actually be more expensive for Motorola
to outsource than it was for them to improve their processes.

Once you factor in the time that you spend putting
together the detailed specification that you need to be able to
outsource, mangaement costs, etc., you won't get anything like
a 66% cost reduction by outsourcing.

Programmers tend to focus on salary differential, but the real
advantage that the offshore shops have is that they take the
design and development *process* really seriously, so get
significant productivity increases over shops that have
little or no discipline (i.e. 90% of the American programming
shops). If process was the only factor, they'd wipe us out
because of the labor-rate factor, but the oursourcers have to
make money, too, and their profit margins suck up the labor
savings. Outsourcing is cost effective only because American
shops don't take process and design seriously, so they are
inherently inefficient.

On the other hand, given an ingrained cowboy culture, it might
be that the only way to fix the culture is to fire all your
programmers, outsource, then hire back a staff that believes in
the benefits of design and discipline. That route would
certainly be more cost effective than continuing to
outsource. Of course, you could take matters in your own hands
and try to improve the efficiency of the existing shop :-).

If you go this route and need some help, you can reach me at 
/allen.html :-).

------------------------------------

Until next time, 
	Allen



2003/08/08