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