>>  On Sun, Oct 16, 2005 at 11:48:34PM -0200, Luiz Esmiralha wrote:
 >>  >
 >>  > Maybe another question can help clarify the issue.
 >>  >
 >>  > Why pay 100 grand a year for a programmer just to make a guy in the US
 >>  > or Europe happy if I can get the same job paying 20 grand a year for a
 >>  > guy in India?
 >>
 >>  Well those aren't anything near the figures.  I know someone who is
 >>  the IT director for a UK company that uses outsourcing.  The financial
 >>  savings are around 15%.  If he sets up a UK shop in one of the more
 >>  deprived areas of the UK he will be able to get to somewhere near that
 >>  figure - lower salaries, govt grants etc.  As a result he is seriously
 >>  looking at doing just that.
 >>

 In a recent survey, average savings from offshoring are around a bit
 less than 10%. 5% of the companies polled acheved savings around 50%
 (cases where they replaced 400 bucks/hour resources for 50 bucks/hour
 resources).

 The realistic target saving when offshoring operations is estimated
 around 30% as companies become more mature in the way they conduct
 offshoring.

 20 grand a year for a programmer in Brazil is a very good figure. I
 don't know the current average salary of a programmer in the US or UK.
 The 100K figure was based on supposition rather than fact.

 >>  > Your analogy implies that Indian software lacks quality. Quality seems
 >>  > to be measured (or guessed?) in CMM levels by every company in the US
 >>  > and the rest of the world is following this trend. Given that fact, I
 >>  > would like to remind you of the many companies in India appraised at a
 >>  > CMM 5 maturity level.
 >>  > I don't believe in CMM, but the guys in India didn't make it up, they
 >>  > just happily jumped on the SEI bandwagon.
 >>
 >>  I don't believe in CMM either and I dont believe it necessarily produces
 >>  a high quality product.  It has been my experience (of three different
 >>  Indian outsourcing companies) that product quality is variable, and
 >>  a lot of the developers are what I would class as juniors even though they
 >>  are not sold as such.  Undoubtedly some of this can be tracked to
 >>  the fact that development of apps that distant from the users is not the
 >>  best way of doing things. Also there is a disinclination for the Indian
 >>  guys to question the spec if they think it is inconsistent or lacking in
 >>  detail and to raise questions with whoever is leading the project.
 >>
 >>  Some (maybe most) of these issues are often also present for the big US/UK
 >>  consulting firms.
 >>

 I worked with the 'Big Five"  in some projects and they present a
 uniform pattern in their staffing that I call "War Movie Team".

 These teams are usually composed by a seasoned sargent (consultant)
 which marvels the spectator (customer) with his ability and 10 rookies
 (juniors or trainees). The sargent is usually assigned to another post
 in the middle of the movie and must leave the rookies to their own
 luck.

 In unrealistic war movies, the rookies will use their talent combined
 with the experience they acquired with Sarge to overcome the enemy and
 come home as heroes. In real wars and real projects, they are
 slaughtered by snipe fire, hidden mines and disease and return to
 South Dakota in bodybags.

Wee is a framework for building highly dynamic web applications. It is inspred by Seaside.

www.euruko.com

• The framework: Ruby on Rails
• The favored webserver: lighttpd with FastCGI
• An embedded database: SQLite

Locomotive includes the Ruby MySQL and PostgreSQL bindings. If you have MySQL/PostgreSQL installed, or want to use them, Locomotive is ready.

Locomotive will be nice to your existing rails installation as Locomotive is entirely self-contained.

Propositions for enhancements are welcome…

gegroet, Erik V. - www.erikveen.dds.nl/

 >FWIW, I didn't find it insulting.  I was offering my (somewhat
 >> educated) viewpoint.

 I knew that education would get you in trouble someday.
 If you were a dropout like some of us, we wouldn't be having all
 these communication problems.

 That's why I like to work with people who know they're idiots. It's
 just so much easier on all of us.

 If they're an idiot and they know it, I can work with them.

 If they know they're an idiot and they turn out to be smart, so much
 the better.

 If they're an idiot and don't know it, I know I don't want to work
 with them.

 And if they're not an idiot and they know they're not an idiot, I
 don't want to work with them. Why make someone like that suffer?
 After all you'd have to be an idiot to want to work with me.

 The C Programmer
    God consults with the C programmer on every major issue. (As anyone
    who study's processor design knows all to well.)
        The C programmer can walk on water.

 The VB Programmer
    The VB programmer does lunch with God every day.
    He is an olympic class swimmer.

 The Turbo Pascal Programmer
    The Turbo Pascal programmer occasionally has a word with God.
    He can swim pretty well.

 The Fortran Programmer
    The Fortran programmer sometimes catches a glimpse of God.
    He manages to keep himself afloat in shallow water.

 The QBASIC Programmer
   The QBASIC programmer knows who God is.
   He has trouble avoiding drowning in his own bathtub.

 The LOGO Progammer
   About the only thing a Logo programmer knows about GOD is that the
   word is short enough for him to sound out, but he has trouble spelling
   it.
   He needs someone else to cerry him across the water for him.

 The Assembly Language Programmer
   The assembly language programmer is God.
   He parts the water when he wishes to cross it.

 The Forth Programmer
   The Forth programmer don't view ever river he comes across as a
   challenge to his religious faith and just walks across the bridge.

 Von: "SD Magazine"<sd@newsletters.sdmediagroup.com>
 Betreff: SD People & Projects: Mo' Developers, Mo' Problems?
 Datum: Mon, 03 Oct 2005 19:09:26 -0400 (EDT)

 SD PEOPLE & PROJECTS

 October 2005: Bigger Teams Not Always Better
 By Amit Asaravala

 >>>> MO' DEVELOPERS, MO' PROBLEMS?

 Thinking about assigning more developers to a project
 to accelerate your schedule? Be careful. Putting a large
 team on the job could cause you more trouble than it's
 worth, according to a new study by software estimation
 and analytics vendor QSM.

 The study, based on data that QSM collected from 564
 information systems projects completed since 2002,
 revealed that large teams don't complete projects much
 faster than small teams, though they cost much more. In
 particular, teams with 34 people on average completed a
 100,000-line project in 5.6 months at a cost of $2.1
 million, while teams of four people on average took
 about two weeks longer but cost just $294,000. Thus,
 shaving two weeks off the schedule cost some companies
 as much as $1.84 million.

 Why such disproportionate production rates? Blame it
 on the bugs. The larger teams produced more than five
 times as many bugs as the smaller teams, which required
 the teams to reexamine their code more often, according
 to QSM. In the end, this ate into a large portion of
 the time saved by having more developers turn out more
 code per day.

 But before you decide to cut your team back to just
 four people, consider this: The size of the small team
 in the study was just an average, and QSM readily admits
 that it's saving the question of "optimum" team size for
 a future study.

 Rather, the real lessons here are that you'd better be
 sure that accelerating your schedule by adding more
 developers is worth the extra cost, and that you should
 have realistic expectations about how many days you'll
 actually save by doing so.

 --Amit Asaravala

Here’s a very interesting set of comments from Linus Torvalds and Theodore Tso on the problem with writing specs:

kerneltrap.org/node/5725

Here’s a great quote from Linus:

 The classic example of this is the OSI network model protocols.
 Classic spec-design, which had absolutely _zero_ relevance for the
 real world.We still talk about the seven layers model, because it's
 a convenient model for _discussion_, but that has absolutely zero to
 do with any real-life software engineering. In other words, it's a
 way to _talk_ about things, not to implement them.

 And that's important. Specs are a basis for _talking_about_ things.
 But they are _not_ a basis for implementing software.

And a good one from Ted Tso:

 In those cases, if you implement something which is religiously
 adherent to the specification, and it doesn't interoperate with the
 real world (i.e., everybody else, or some large part of the
 industry) --- do you claim that you are right because you are
 following the specification, and everyone else in the world is
 wrong? Or do you adapt to reality?

And another one from Linus:

 So don't talk about specs. Talk about working code that is
 _readable_ and _works_. There's an absolutely mindbogglingly huge
 difference between the two.

All heresy to the BDUF school of thought, of course. But relatively uncontroversial in the XP world. Interesting to see the parallel evolution.

A few months ago I did buy a mac mini. My excuse to my girl-friend was that it would make less noise than my hyper big server. The mac mini looks really nice and OS-X is cute, too. I got to admit, I do love the GUI and the poor fact that most things like WLAN, etc. seem to work out of the box. But the definite downside is that coming from Debian/Gentoo/Suse I got some expectations towards the development tools. Now I waste hours installing fink, etc. .. fighting with different philosophies, but I still enjoy the new journey.

It will take 5 years, as one has to get all right. The fast intuitive UI, the security, the marketing and many other things. Looking at a big company, most people only use:

• Browser
• Calendaring app
• Word
• Excel
• Powerpoint

Why did openoffice not have a wider impact so far? Can a web-based suite win without entering the "comopatability/file format" war?

Have a nice and long weekend. It’s the last two days of the Oktoberfest, so I am preparing for some beer.

 1. vncserver
 2. enter password
 3. remove all in  ~/.vnc/xstartup that is not needed
 4. work:
    DISPLAY=:1 R
 5. vncserver -kill :DISPLAYNUMBER_FROM_STEP_1

Thanks to Stefan!

"Fridays" are short, focused, PDF-only books, written by experts for developers who need information fast. These new e-books are hyperlinked, both internally and to external resources. They’re specially formatted for easy on-screen reading. And you can download any new versions of the Fridays you own for the life of the book.

The first book in this new series is "Rapid GUI Development with QtRuby," written by Caleb Tennis.

See how to use the powerful Qt3 library to create cross-platform GUI applications for Linux and OS X in Ruby. Covers installation, basic and advanced programming, event models, and Korundum.

Contents:

• Introduction
• About Qt. History, versions, installing, testing your installation.
• About QtRuby. Language bindings, SMOKE, installing.
• Get Your Feet Wet. Writing your first program, widgets and the object model, initialization, Qt::Application.
• Take the Plunge. Custom Widgets, geometry and layouts, signals and slots, slot senders. Read an extract
• Sink or Swim. Events methods and filters, the Main event, the event loop, posting and sending.
• The Home Stretch. Qt modules, QtRuby tools, tighter Ruby integration, disposing of widgets, debugging QtRuby applications.
• Korundum. Installing, DCOP, interprocess communication.
• Appendices. Event Method Map, Resources.

For more information on this title or to purchase it ($8.50, 90 pages), please visit www.pragmaticprogrammer.com/titles/ctrubyqt

For more information on this new series, "Fridays", please visit www.pragmaticprogrammer.com/starter_kit/faqs/fridays.html

Thank you for your continued support, Dave and Andy

"Let’s pretend I’ve decided to build a spice rack.

I’ve done small woodworking projects before, and I think I have a pretty good idea of what I need: some wood and a few basic tools: a tape measure, a saw, a level, and a hammer.

If I were going to build a whole house, rather than just a spice rack, I’d still need a tape measure, a saw, a level, and a hammer (among other things).

So I go to the hardware store to buy the tools, and I ask the sales clerk where I can find a hammer.

"A hammer?" he asks. "Nobody really buys hammers anymore. They’re kind of old fashioned."

Surprised at this development, I ask him why."

discuss.joelonsoftware.com/default.asp?joel.3.219431.22

redhanded.hobix.com/inspect/railsfsAfterACoupleMinutesOfToolingWithFuseWhoa.html