General talk about software patterns

["Chris Finlayson" <cfinlayson AT vls-inc.com>]

Oh, and another thing!

Naturally, a rock-solid technical team will probably choose the best
technology, implement faster, communicate to management effectively, etc,
etc.  Unfortunately, the 1% of such individuals can only go so far.....

I've consulted for large companies where for every 10 people maybe one knew
what was going on and was productive.  The reality is that a rock-solid
technical team likes to work on interesting problems, and doesn't want to do
something that's been done a million times over (think eCommerce).  Not
everyone is a Software Engineering PhD, or very much interested in
continuing their education past the bare-bones-minimum, or very much
interested in working at all.  I'm not a Software Engineering PhD, and even
I'd be bored if I were working on American Express' eCommerce site.  I can
only imagine how a real PhD, or similarly trained/talented individual would
feel.

I worked for an extremely brilliant architect who used to work for IBM.  I
was talking about getting an advanced degree to him, and he told me that he
was involved in the hiring process at IBM of engineers.  He said they almost
immediately "blacklisted" PhD applications, because they "only want to work
on interesting problems".  IBM's experience (at least within his division)
was that the PhD's got bored, or were uninterested, and therefore not as
motivated as someone else who maybe wasn't as talented as said PhD, but was
charged up to learn and get tasks done.  I think it takes something like 5-7
years to a PhD in software engineering - after such an investment, I'd sure
as hell want to work on cool projects and would probably be annoyed with the
engineering proletariat.  

Therefore, even though a rock-solid technical team will solve anything and
everything in the best possible manner, companies sometimes have a tough
time assembling and maintaining such talent because said talent simply gets
bored after a while.  Therefore, the company must "dumb-down" the hiring to
pitiful non-PhD's such as myself.  

For any company working on straightforward problems which they will have
difficulty hiring/retaining PhD's (or very talented) individuals, they just
have to accept the fact that they won't be getting the top 1% of the
engineering community, and will choose a technology that the remaining 99%
can easily assimilate, learn, and/or has experience with - ergo the
companies will go with the establishment.

--c.
  


> -----Original Message-----
> From: Chris Finlayson 
> [mailto:cfinlayson AT vls-inc.com]
> Sent: Tuesday, October 26, 2004 10:23 PM
> To: 'Ralph Johnson'; 'Mark Grand'; 'Mike Beedle'; 'Pascal Costanza'
> Cc: 
> 'patterns-discussion AT cs.uiuc.edu'
> Subject: RE: [patterns-discussion] Pattern-Oriented Programming
> 
> Greetings,
> 
> 
> Be it right or wrong, the best product technically doesn't always win.  We
> know this.  The "us versus them" attitude will do nothing to solve this
> (management is stupid, we know better, etc....)
> 
> A little "sell" isn't bad, and should in fact be expected.  This was in
> fact the philosophy of the mathematician/businessman Dr. Edward Deming who
> was hired by the US government to rebuild Japan post-WWII to be a
> capitalist society.  His philosophy was to get management and workers
> together in a symbiotic relationship and reject the
> authoritarian/dictatorship management model that was in vogue in America.
> Of course, Japan ended up coming back stronger than ever where pre-WWII
> they were viewed as low-quality manufacturers, and suddenly they started
> manufacturing higher-quality goods than America.
> 
> Deming's idea: Management must get their hands dirty, and encourage
> feedback and communication with workers, and even "sell" them on why it is
> what they're doing is productive, beneficial, etc.  Reject the "us vs.
> them" attitude.  In the long-run, this makes for (more likely) the best
> decisions and a better product.
> 
> America and the world has a long way to go.  For example, it goes with
> little argument that the metric system is better than the English system
> of units of measurement.  The whole world is on the metric system except
> Americans, it's more intuitive, blah blah blah (does anybody even know
> what a foot-pound is?).  In America, we were supposed to convert to the
> English system in the 70's.  Yet few Americans (myself included) ever use
> the metric system, and never plan to, even though we may rationally know
> that it's better.
> 
> Why don't we go to the metric system?  First and foremost, funding for
> American education is abysmal, which is where this conversion would have
> to take place.  It would mean educating teachers, changing textbooks, etc.
> - our government simply doesn't allocate enough funds for education to
> support this.  Our government needs to be sold on the idea of conversion.
> 
> Likewise, be it right or wrong, Sun and Microsoft have developed end-to-
> end enterprise systems to cater to the masses.  Even if we assume that
> today someone came out with the "best" programming language ever as judged
> by a panel of experts, it'll go nowhere if it doesn't have a well-stated
> business case and a vision for the future.
> 
> I've worked for Java shops and Microsoft shops, and right or wrong, the
> direction of a company's choice of technology  is influenced by several
> factors.  Back in the day, web development was cumbersome at best.  I've
> worked with the Microsoft suite of products for web development: biztalk,
> commerce server, SQL server, .NET, and the tight integration was a joy, as
> was ultimately the lack of coding necessary to accomplish straightforward
> tasks.  Our company was working with other companies who had Biztalk
> servers already set up, and were SOAP and UDDI compliant and all that good
> stuff - we had to communicate with them.  We could've reinvented the
> wheel, or buy a Biztalk server ourself and be over-n-done with.  I'm not a
> Microsoft evangelist by any means, I don't think they're extraordinarily
> groundbreaking in research, but I do think they're good at filtering out
> what people have already done, picking and choosing the best-of-breed
> ideas, and implementing them in a unified system.  Finally, they
> communicate the vision in a manner that buy vs. build decision makers
> understand.
> 
> The latter part is I think the crux of it all - communication and
> convincing.  I wouldn't expect the CEO of American Express to understand
> software engineering, even though his company is highly dependent on a
> quality back-end software product.  He doesn't even know what he doesn't
> know.  Likewise, I don't even know what I don't know about being the CEO
> of a large company like American Express.  The higher level individuals
> who are in charge of making technology decisions can only make their
> decision based upon how well the problem and vision is described to them.
> I tend to doubt the CEO of a multi-billion dollar company is an idiot.
> Even if he were convinced that technically a better solution exists, he
> may be thinking of interoperability with other companies that have already
> followed a mold (e.g. communication via Biztalk). Assuming he's not an
> idiot, what's lacking is the proper evangelism and unified idea.
> 
> I've been in the commercial world all my life and all I've ever seen,
> read, and heard about are Sun and Microsoft.  I'm an engineer know nothing
> about Smalltalk outside the examples in the GO4 book.
> 
> With companies like Microsoft and Sun that have so much momentum, it's
> hard to believe that any grass-roots programming language will ever
> dominate (even if it is superior).  The only way I'd think it'd be viable
> is if a business case is developed and communicated effectively to non-
> technical decision makers.  Of course, the only motivation to have a
> business case is to have a company that would sell a Smalltalk (or
> whatever) vision.....that either competes with, or works in conjunction
> with, the established vendors.
> 
> 
> 
> --c.
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: 
> > patterns-discussion-bounces AT cs.uiuc.edu
> >  [mailto:patterns-
> discussion-
> > bounces AT cs.uiuc.edu]
> >  On Behalf Of Ralph Johnson
> > Sent: Tuesday, October 26, 2004 3:00 AM
> > To: Mark Grand; Mike Beedle; 'Pascal Costanza'
> > Cc: 
> > patterns-discussion AT cs.uiuc.edu
> > Subject: Re: [patterns-discussion] Pattern-Oriented Programming
> >
> > On 10/24/04 6:10 PM, "Mark Grand" 
> > <mgrand AT mindspring.com>
> >  wrote:
> >
> > > In the commercial sector, it is hard to find Lisp or Smalltalk people.
> > > Reimplementing in a more common language will, over time, reduce costs
> > and
> > > make the progress of software development more predictable.
> >
> > This is what managers think.  Managers are wrong.  Converting a Lisp or
> > Smalltalk program always increases costs and makes the progress of
> > software
> > development dramatically less predictable.  It isn't even close.
> >
> > I've seen Smalltalk projects in trouble because the programmers all
> left.
> > This was mostly back in the days when Smalltalk was very hot and there
> > were
> > programmers making $2000 a day.  (Not many, but a few.)  It was hard to
> > keep
> > good programmers on a project, especially with bad management.  Managers
> > didn't have that problem with COBOL or C.  But now Smalltalk is not in
> > such
> > demand.  Salaries are the same as for other languages and Smalltalk
> > programmers don't move around any more than other programmers.
> >
> > It is hard to hire a lot of Smalltalkers fast, but it is easy to hire
> them
> > slow.  So, you shouldn't try to have a 100 person Smalltalk project, but
> > those were always bad ideas.  Part of the magic of Smalltalk is that you
> > can
> > do with ten people what would take 100 with another language.
> >
> > It is well known that the key to successful software projects is getting
> > good people.  Good people prefer productive programming languages.  In
> my
> > experience, the best programmers prefer "weird" languages like Smalltalk
> > or
> > Lisp.  Or Ruby, or Ocaml.  Productive programming languages let your
> > development group be smaller, reducing management problems.
> >
> > -Ralph Johnson
> >
> > _______________________________________________
> > patterns-discussion mailing list
> > patterns-discussion AT cs.uiuc.edu
> > http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion