Last weekend I went on a two day "Geek Cruise"; a sort of mini-conference, arranged by Cantara
To be quite honest I had no idea what to expect from the event and I had my doubts when I noticed that Totto had put me down for a talk on a topic for which I can confidently claim that I am certainly not any kind of authority. I can't recall the title right now, but in retrospect, and with a bit more sleep, I see that he didn't ask me to give a talk on the security challenges of ID-systems, but "merely" how you would build a scalable ID-system. That's actually something I would be able to talk about for hours without repeating myself.
But I had barely had any sleep when I sat down to write the talk, so instead I gave a talk on what sort of mindset you need to build a scalable system -- which is perhaps more important than how you actually do it.
Summarized in a few words: if you do not understand the problem domain on a very fundamental level, you are not going to succeed in solving your problem at scale. Sorry. Methodology and fashionable practices are no substitute for knowing what you are doing. If you do not know what you are doing you still can do well if you are adaptable, open minded, willing to be unconventional and learn.
In my talk I mentioned that I am skeptical towards treating fashionable practices such as pair programming as some sort of universal solution, and I was somewhat surprised (stunned, more like) to find that the majority of people present do in fact find pair programming beneficial as their main way of writing code. I have to admit that I was a bit stunned.
I usually ask people who are willing to pay lip service to pair programming if they actually practice what they preach, and I am used to that the vast majority somewhat shamefully admitting that while they think it is a good idea in principle, they do not actually do it.
Personally, I find pair programming annoying. I usually write code in bursts lasting 1-4 days and when I do program it is a largely introvert activity. I have a very non-linear programming style which means that it can be really hard to follow what I am doing. And if I have to stop and explain everything gets painfully slow and ideas quickly get lost. I also get terribly bored when watching other people program and I am invariably frustrated when I have to sit and watch someone else edit code. People use different text editing tricks, and some people are just too painful to watch as they clumsily key their way through code.
I prefer to separate the actual moulding and writing of the code from the reviewing of it. Going over a chunk of code that I have just written works better for me because then I can dedicate my full attention to understanding what the other person is thinking and we can have a discussion without the risk of me losing my train of thought.
Of course, sometimes I do find pair programming beneficial. For instance when I have no idea why something that looks reasonable either doesn't work or just feels wrong.
I think pair programming is a matter of experience and personal preference. Some people prefer to do pair programming. Most experienced people I have met to date can't stand it. Which is why I was surprised to find myself in a room with experienced programmers who could not just stand it, but who preferred it.
Oddballs, the lot of them :-).
There was a whole spectrum of views on typical enterprise architecture. While I got the impression that nobody thought relational databases were the ultimate solution to everything, some seemed more fond of their RDBMS than others (hi Johannes! :-). I guess this has more to do with the reality of the world people live in than any deep-seated preference.
I've spent the last 10 years in a field where relational databases are almost completely irrelevant as a data management technology, so obviously, I don't really use them in any manner that poses any scalability challenge.
On the first day, Emil from Neo4J presented a taxonomy of databases. Emil is part of the NOSQL crowd and eagerly pointed out that NOSQL should be read as "Not Only SQL" rather than "NO SQL". Apparently some get their knickers in a twist over the latter definition.
Emil also talked a bit about their product, a graph database called Neo4J. Not having seen a viable specimen of this species before I was very intrigued. Especially since problems involving large graphs has slowly grown to become a topic of interest in more ...uhm, pedestrian developer communities. When I get a bit of spare time I intend to play around with Neo4J. I have some interesting problems that I think might be a good fit for it.
Totto tried make us define when a relational database stops being relational. We agreed to just leave it at "it stops being relational when you lose joins". In any case, a relational database stops being really useful as such when you have to partition the data across machines, which is probably true even for products that offer ways to deal with this.
Hands off my data!
Although the term SOA has been so thoroughly discredited by the flatheaded morons who incessantly stick web services onto anything and everything, and then go on to talking about this makes them service oriented even though they still use the database as an integration point, there was fierce agreement, at least between Dan and me that allowing access to state only through services was The Right Thing.
Sometimes the hype can kill something that was actually a fairly good(ish) idea.
Well, hype and Web Services. Nobody had much positive to say about web services. I found it rather heartwarming when someone said "I hate raw web services. I want proper client libraries".
Everyone agreed that the Erlang crowd are a smug bunch (ok, we're jealous).
Sentiments on Ruby seemed to range from "nice", via "a good replacement for Perl", to "oh grow up, it is a fucking toy".
At some point Dan brought up "gossip protocols" or "epidemic protocols". Sadly we didn't get around to discussing this topic in more detail, so I will have to read up a bit on this later.
EDIT: added links.