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

More screenshots

David Norfolk recently interviewed me regarding how I view XP and architecture. He started out quite skeptical, but I found his article balanced and thoughtful: www.theregister.co.uk/2005/09/11/beck_on_xp_architecture/

You have to love the irony here:

1) IBM drops Smalltalk, handing it to Instantiations:

www-306.ibm.com/software/awdtools/smalltalk/transition.html

2) Another part of IBM, focused on syndication technology, starts to realize that dynamic languages like Smalltalk are the wave of the future:

www.intertwingly.net/blog/2005/09/09/The-Case-for-Dynamic-Languages

Damon wrote: > I bought the book Smalltalk Companion, by Ted Bracht, to see if I can > pick up Smalltalk. I’ve programmed in Java for several years, and I > think I have a decent grasp of OOP issues. > […] > Missing though are insights that I seek to translate the concepts that > I learned in developing in the file-based language of Java with its > edit/compile/test iterative development process to the image-based > interactive development process of Smalltalk.

 Welcome aboard!

 I made the Great Leap Forward from Java to (Dolphin) Smalltalk a few years ago
 and I think I can still remember how it felt. My motives were not too unlike
 yours -- curiosity about what was claimed to be a better way of working, more
 than anything. What I got out of it wasn't quite what I'd expected. I was
 hoping to find better tools, what I found was a different way of thinking about
 OO.

 You've already had a couple of fairly direct answers to your specific
 questions. I'm going to try to take a step back and talk a little about the new
 way of thinking. I'll try to relate it to your questions as I witter on, but
 the connections may seem (be) rather indirect.

 BTW, this is all -- obviously -- only my own opinion. Other Smalltalkers might
 disagree with much, or even all, of what I want to say.

 The "image" is the *central* concept of Smalltalk. In comparison, nothing else
 is very important. (I'm aware that there are Smalltalk dialects that don't have
 images, but I -- personally -- can't see the point.). If you are like me, then
 you are currently thinking of a big difference between Smalltalk and Java being
 that Java stores code in files, whereas Smalltalk keeps it in the image. That's
 sort of true, and I'll get back to it, but, for a minute, just forget about
 code, it's not important (really!). What matters is *objects*.

 The image is the place where the objects live. Technically, the image is a
 garbage-collected heap that can be saved to file, and later restored, thus
 saving and resuming the state of a computation. *Technically* that's true, but
 it isn't at all a helpful way to think about it. A more organic metaphor works
 much better. I think of the image as a deep, murky, pond where objects move
 around in the depths like fish. It's an important part of the metaphor that the
 objects are *independent* of me. Even if I designed and wrote the classes, once
 an object has been created it has an independent existence. I can talk to it, I
 can ask it to perform operations, but it is separate from me. In a sense it is
 "my" object, but it is only "mine" in the same way that a pet, or a rose bush,
 or a table, could be "mine".

 The image is where the objects live. Not the code, the objects. We'll get back
 to the code in due course, but not yet. The Smalltalk environment is just a
 place where you can talk to objects; no more, no less. Oh, sure its got class
 browsers, debuggers, editors, etc, but that's all tinsel. What matters is that
 it is a place where you can interact with the objects.

 I'll get back to the "tinsel" later too, but for now, I want to talk about the
 one part of the environment that isn't just a productivity aid: the workspaces.
 Workspaces are the medium through which you talk to objects. You *can* describe
 workspaces as "containing snippets of code" which you execute, but IMO that's
 exactly the wrong way to think of it. A better picture (slightly
 tongue-in-cheek) is as a kind of singles bar, where you can meet objects, talk
 to them, check them out, get to know them. Each workspace has a number of
 objects that are (temporarily) living there; they are the values of the
 variables in the workspace. In most cases they'll die when you close the
 workspace, but until you do they'll survive and you can talk to them. I keep
 some workspaces hanging around for days if they contain objects that are
 important for what I'm doing. The way you "talk" is by sending messages written
 in the Smalltalk programming language, but that's almost incidental. The
 important thing is that you are communicating with them using an interactive
 text-based medium, like using an IRC channel.

 I very much like that picture. A workspace is like an IRC channel for talking
 to objects. One difference is that the other users of a real IRC channel don't
 usually die when you sign-off (at least I don't think so, I admit that I've
 never actually used IRC).

 (BTW, you can save the *text* of the workspace in a .ST file -- it's actually
 saved as RTF -- but that just saving a transcript of the conversation. If you
 re-opened the text in a different workspace window then you'd see the text but
 the objects wouldn't be behind it. Using cut-and-paste from one workspace to
 another has the same effect and can be a good way of killing unwanted objects
 without loosing the record of what was said.)

 Another way of interacting with objects is to use the Inspector(s). They give
 you a much more nuts-and-bolts, low-level, view of the object -- a more
 intimate view, if you like. I, personally, don't think that the Smalltalk world
 has yet woken up to what inspectors *could* be, but the current implementations
 (like "flipper" in Dolphin) do at least allow you to see inside the objects.

 An image will contain many objects, some long lived (living, perhaps, for
 decades), most very short lived indeed. Some will be simple or trivial, like
 Strings and Points. Others will have complicated internal structures, and/or
 complicated behaviour. But they are all objects, and they all live in the
 image, and you talk to them in workspaces.

 Classes are one particularly interesting kind of object. Remember I'm *still*
 not talking about code (that comes later), I'm talking about the objects called
 classes. Just like any other objects, you can invite them to join you in a
 workspace:

     class := String.

 and then you can use the magical Smalltalk object-oriented IRC to talk to them:

     class name. "--> #String"
     class allSubclasses size. "--> 3"

 and so on. So classes are objects, and they live in the image.

 Since Smalltalk is a programming environment with GUI features, there's nothing
 more natural once we've reached the point where we have an image full of
 objects, than to start writing tools that allow us to interact with the objects
 in more structured/convenient ways. Workspaces and Inspectors are fine for the
 basics, but we'll soon want better tools that allow us to see the relationships
 between objects (or some subset of objects -- the classes for instance), or
 what messages they understand. Maybe we'll want to be able to modify their
 behaviour, or create new kinds of objects. That's exactly what the IDE
 provides. The class browsers, etc, are merely a collection of tools for talking
 to objects. They are useful, even highly desirable, but ultimately dispensable
 because we could talk to the objects without them, anyway.

 But now it's time to get to the subject of code. The progression I've taken,
 starting at objects, then the important tools, then classes, then more tools,
 and finally code, really does represent a progression from the most important
 to the least. In this way of thinking the code is the least important part of
 programming in Smalltalk. (Of course, I'm schizoid about this, I don't
 *really* think that the code is the least important part -- just muck with my
 code's formatting and watch me explode -- but on the other hand, I really *do*
 think that the objects are more important.)

 Code is how we tell objects how to behave. It's text in the Smalltalk
 programming language. We're programmers so we care about code; when we wrote
 the tools for looking at objects, we naturally designed the tools so that we
 could also see the associated source code. For instance our special tool for
 looking at classes (the class hierarchy browser) allows us to see the source of
 the methods, to change the source and recompile, etc. That's natural for us as
 programmers. If we weren't programmers then we'd want different tools, and we'd
 be interested in talking to different objects. Such systems, built for
 non-programmers, are called "applications", but they are still just
 Smalltalk -- tools for talking to objects that live in an image. (A big
 difference is that the "image" of an application is typically not persistent,
 unlike the image of the IDE).

 Back to code. Granted that the most important thing is the objects and how they
 behave, we still do care about the code. We want to organise it, back it up,
 put it under source code control, etc. A class is an object that lives in the
 image, but the source code *for* that class is something else. For all sorts of
 reasons, we want to keep that outside the image. The way that Dolphin organises
 source-code is via Packages. A package is a collection of the source code for
 classes and methods (and a few other things too, which don't matter here) that
 is kept outside the image in one or more files. You can load the package into
 the image, which will create an actual Package object, and class objects
 corresponding to the source-code. Or you can "uninstall" the package, which
 really means killing the Package object and the Class objects.

 So a package is just a way of collecting related source-code together. Some
 Smalltalks go further and associate namespaces with packages. Dolphin doesn't
 (and I'm not at all sure that I think that's a bad thing). You can load the
 same package into different images, in which case you'll have duplicate
 versions of the class objects living in both images. If you do that then you'll
 want to be careful not to make changes to the classes in one image and not the
 other, because then the package file cannot reflect the state of both images.
 The package mechanism is relatively simple; it could be improved, but I find it
 adequate for my needs. Package files are text files, you can edit them with vi,
 or notepad, or whatever. Occasionally I do that if I want to make particularly
 sweeping changes to the source. Of course, if you do that then you have to
 install the changed version into the image before it'll do anything useful.

 Notice how very different this way of thinking is from the way that even the
 best Java IDEs encourage you to think. When I started out in Smalltalk I was
 thinking of the IDE as if it was a Java IDE. I though of it as a tool that
 allowed me to write code, and had features to allow me to browse and test the
 code. After a year or so I realised that I'd turned the picture upside down
 completely, and in the process had revised my conception of what
 Object-Oriented programming is all about. As a Java (or C++) programmer I had
 pretty much thought my .java (and .cpp) files *were* the classes, and I thought
 that creating classes was what programming was *about*. I now think of the
 objects as being the important thing, and the classes as very secondary, hardly
 more than an implementation detail.

 I *feel* that that has made me a better programmer. Of course it's not possible
 to know for sure, but if it has, then it all comes down to Smalltalk's
 workspaces...

 (A couple of asides for seasoned Smallalkers, if any are still reading:

 Was Dolphin the first Smalltalk to have workspaces that kept the values of
 variables rather than throwing them away after each evaluation ? VW used to
 discard them and I think VASt still does. Squeak keeps the values, but I don't
 know how long that's been true. Anyway, whichever implementation it was that
 introduced the idea can -- I think -- claim to be the first *truly*
 object-oriented Smalltalk. Presumably also the first truly object-oriented IDE
 of any kind.

 Writing this has made me focus on the unease that I still feel with
 programming-in-the-debugger. I was already a bit suspicious that it might
 encourage a (crypto-)topdown approach to decomposition. I'm now starting to
 wonder whether it also is part of a "code-centric" way of thinking, rather than
 the "object-centric" mindset that I think Smalltalk *should* foster.)

 BTW. One book on Smalltalk that I heartily recommend, especially if Ted
 Bracht's "teach-by-example" approach isn't right for you, is Chammond Liu's
 book, "Smalltalk Objects, and Design". It's the best book on Smalltalk that
 I've ever read (although it's not Dolphin-specific), and in fact I'd say it's
 the best book on OO that I've ever read too.

 Oh well. Once again, this has been a longer post than I'd intended. I don't
 know if anything I've said has made any sense to you, or has seemed even
 slightly relevant. I've had fun writing it anyway...

 -- chris

A number of times before we’ve talked about organizations behaving in ways that seem pathological, and what agilists might do in those circumstances.

This interesting article suggests that a number of headline CEOs (and likely a bunch of high-level executives and corporate climbers) are diagnosable psychopaths:

www.fastcompany.com/magazine/96/open_boss.html

In particular, quoting from the article, they score highly on eight characteristics:

• glibness and superficial charm
• grandiose sense of self-worth
• pathological lying
• conning and manipulativeness
• lack of remorse or guilt
• shallow affect (i.e., a coldness covered up by dramatic emotional displays that are actually playacting)
• callousness and lack of empathy; and
• the failure to accept responsibility for one’s own actions.

For me, this article was an eye-opener. There have been a couple of agile adoption efforts that I have participated in where, in retrospect, I concluded the only thing I could have done was walk away as soon as possible. From my armchair diagnosis, both involved psychopaths in positions of power.

Now it makes sense. These people weren’t just sincere but misguided. They really had no interest in transparency, in long-term sustainability, in producing good work, in steady progress. Indeed, given that they thrive in chaos and confusion, that they enjoy or are indifferent to suffering, their values are fundamentally opposed to the values we here hold.

Nancy Van Schooenderwoert added: Yes, a very fascinating article! I have a book on a related topic. It’s "the Corporation" by Joel Bakan (2004 Free Press). A cover blurb says:

  "The corporation's legally defined mandate is to pursue relentlessly
  and without exception its own economic self-interest, regardless of the
  harmful consequences it might cause to others."

I got the book recently and haven’t read it yet - but this article seemed to point at the same problems on a personal level.

www.rubyist.net/~matz/slides/oscon2005/index.html