3 items are tagged with people:

Recently, I read A Mathematician’s Apology from G. H. Hardy. There was one sentence that struck me:

‘…most people can do nothing at all well. … perhaps five or ten percent of men can do something rather well’

He is not alone is this observation, Paul R. Brown called it the Tyranny of the Average. This is not only the case in our progession, but everywhere you look - most people have no clue what they are doing, or why they are doing it a certain way. Most time, they cannot even tell you what they do.

I’m afraid that because of that, most people are doing jobs they cannot do even half-way good (and according to the Dilbert principle, most of them end up in management). Also, these people are victim to the Cargo Cult Programming: they just follow some guidelines or patterns they have seen somewhere. But they do not know why these guidelines have been developed, and how they can be used effectively (and when they should be used). The Daily WTF is full of the code created by these people.

So, what to do? For me, first it means setting higher standards to other people, and to encourage and help them to meeth these standards (like better code style or more powerful ways to do something). The other is, at the same time, to reduce the flexility the developers have within our framework. This does not make the developers any better, but reduces the amount of damage one can do.

Cruizer said that .NET 3.5 does things which Smalltalk already did nearly 40 years ago. A while ago, while learning more about Smalltalk history (and about the great things therein), I came to the conclusion that all great ideas in computer science have been made before 1975:

• all programming paradigms: LISP (1958), Smalltalk (around 1970), FORTRAN (1953), PROLOG (about 1970), FORTH (1970), COBOL (1960)
• the relational database (Codd, 1970), OO-Databases in the 70s
• Garbage Collection and virtual machines: LISP & Smalltalk
• the laser printer: 1970
• graphical displays and CAD systems: 1963 (Sketchpad)
• the mouse: 1963 (Doug Engelbart)
• Hypertext: 1945 (Vanevar Bush’s memex and Ted Nelson Xanadu, 1965)
• computer collaboration: 1968 (Engelbart’s oNline System)
• the computer demo: 1968 (NLS)
• the GUI: 1970 (for the Dynabook, in Smalltalk)
• Networking: 1969 (ARPANET)
• Laptops: 1970 (Alan Kay’s Dynabook)
• WYSIWYG: 1974 (the Bravo editor for the Alto computer)
• and many more

What’s most disgusting for me: many of the great ideas of these inventions have been forgotten by the majority of all the developers and architects and computer engineers (or maybe they just ignore them). And so we are damned to invent all these ideas again - in most cases in a much weaker version.

Both Turmalix and Mark Levison discuss the problems faced by locally distributed teams. For a current project one half of the team is located in Melbourne, Australia, the other half works in Germany. Out biggest problem - the information flow. If a team sits in a common location, you have many ways of getting information: just go to someone and ask him directly, have regular short meetings, maybe you overhear a nearby conversation, or you meet someone while getting a coffee. All of that is missing now, and the german team sits, literally spoken, in the dark.

The time difference makes things even worse. Currently Melbourne is always 8 hours ahead, after DST this will be 10 hours. We have a windows of several hours only because one team works constantly overtime, and the other people try to start early enough in the morning to allow at least for a daily information sync.

But if there are any unforeseen problems, and somebody needs help from the other team, he normally needs to wait until the next day. This especially requires care when you are checking code into the repository - we had too many cases of non-compiling code, and this can disrupt the work of a whole team for a day.

Our most important tool so far is ICQ, because it allows instant communication like the telephone, but can be ignored if you are busy or something else needs your attention. We try to have regular phone calls (because speaking is faster than typing :), but the heavy schedule doesn’t always allow for that.