Just came back from the very interesting talk (which seems to be obliged with its taking place to twitter and to AgileHolland community) by Robert Martin.

The announced topic was "next programming languages", but the discussion was more broader than that. It was not a specially prepared event, which was just right.

For me, the most noticeable moments were (in no particular order):

- Brief introduction to Ruby and Clojure. What a pity I've not been involved with Ruby earlier! Seems like fun. Clojure - at first glimpse, not sure if it's the language for biological humans but who knows... it does seem to be very concise, but the code with minimal syntax is far from being easily understood. Well, may be, those who did program in List think otherwise. I didn't. Wouldn't mind to give it a try though!

- More about Ruby: the absense of interfaces, or rather, the interfaces reduced to the logical end: every separate function is an interface. Have to think about it. From one side, it seems to be logical. From another side, my feeling is that in this case, you definitely need other methods (like TDD) to ensure you are not getting an unexpected mess, if some object you use does have the method you want to call, but it's not what you think of it!

- The discussion about Scala which followed afterwards. Everybody present appeared to be very interested! Great that Scala seems to be "in the spot". May be transition from Java to Scala might occur in the same way as the transition from C to C++ occured? Again, who knows?.. The key question in relation to this statement was: "What is that little difference in Scala in comparison to Java which would make it like C++ was to C?"  (For me, the biggest similarity is really in the possibility to more or less painlessly switch from Java to Scala, without the need to immediately introduce big changes... and the little difference is "functionality" - the same way as "object orientation" was in C++).

- Seeing somebody at hand distance who can quote the number PI up to 200 digits after decimal point...

Also, the audience (which consisted of an intersection between the Dutch twitter community and the members of Agile Holland) was very enthusiastic and helpful, otherwise the discussion would not be that interesting.

By the way, what would be the next next step? If the functional languages, as it was also mentioned tonight, are on the raise because of the need to handle concurrency properly, what could happen if - for now still very mystical - quantum computation would prove to be a reality after all? Or will it be considered just a very specific type of concurrency? Will assembly still have a chance then? ;)

Last but not least: recommended reading: the book "Structure and Interpretation of Computer Programs" (available online here). "This book will explain, why assignments are bad and why concurrency is a disaster, and how we still can handle concurrency if we get rid of assignments", - according to our guest:)

Now, that's it.

So called little changes...

Almost every time when you hope to escape a little known effort with the help of some less-known trick, you are guaranteed to end up doing more work than was planned.

Fresh example.

We needed to provide a Subversion account for beta-testers (at that moment, there were not too many of them, due to the nature of the project). It could be done by adding one more user to the "real" subversion database, and giving him restricted access to one sandbox directory only. However, this was considered to be too much of a burden (also because until now, there was no per-directory policy). So it was decided to establish a new "sandbox" subversion repository to be used for this project (which was not a bad decision in fact, only it should have been made much earlier).

As a result of that, we've got a week or so delay until all problem with new Subversion repository (which also happened to be established on a newly arrived machine and was using different protocol than the other one - svn instead of http) were cleared up.

Those were:
- some research to adapt the SVN connection layer to svn protocol;
- discovery that if we have SVN with anonymous access (easiest option) then SVN doesn't log the users which breaks some project requirements -> some time to set up the non-anonymous access;
- discovery that the SVN server on that machine was too old in comparison with the one used in the "real" repository, which manifested in the nasty side effects. As a matter of fact, there was a bit of luck, because the machine was using Solaris and the support for a suitable SVN has just been introduced. If it was not the case, the whole effort of setting up SVN there would have to be considered waste;
- discovery that updating SVN server required updating quite a few other services on the same machine and spending time doing that;
- last but not least, one more workaround had to be provided to solve a problem with one library that was mysteriously not found while SVN was running.

To sum up: as a result, we have got some knowledge and lost some time. It was not 100% critical for the given project, but in more pressing situation, a week of delay might have very bad implications. May be, in the research-like project it even makes sense to go untested routes in order to gain knowledge (and actually, this one could be defined as a research).

In the hindsight, at the moment when it was decided to do the less known thing it had to be communicated that the time estimations become risky. But the nice additional twist was that the person who made that decision was sure that "it was supposed to be easy".

How to anticipate that? Via micromanagement, asking everybody to come up with a sketch of what they are going to do? But then you might end up with the other type of waste; besides, in case the person responsible for the task is considered to be a senior specialist, he/she might take such requirement as an offence. (Well, I know how to handle that part in theory: by establishing a formal procedure everybody must follow prior to make any changes... these things don't happen overnight, and I've yet to see the place where they really work).

It all seems to be boiling down to convincing the people to follow these procedures. They can't be forced if nobody sees their value. How to convince people to change? May be they have some deeper reasons to behave like thay behave? (Like the ones described in this article, for example :) )

Remains an open question.

Some people just don't cooperate - how to convince them?

Quite discouraging to see people who try to be irreplaceable by not sharing their knowledge with others and/or preventing others from helping them.

It often happens when somebody is insecure about themselves - for whatever reason - and is concerned that if he/she gives away all his/her knowledge, he/she will be replaced by somebody who can do the same things quicker.

I wonder what could be done in this situation? (Don't say "fire them", because this is the last resort). How everybody copes with such team members? They are not useless, quite the contrary. They usually know a lot about what has been done in the past. But when it comes to the new things, they are slower and they see it themselves. This makes them nervous and they begin to be suspicious and close down. Add to this the communication problems because of the age / culture gap and you have it :(

Are there any examples of achieving a win-win outcome?