Wiki

Firday, we had the kick-off for a new project. Nothing out of the ordinary, except that, instead of the usual waterfall development method, we’ll be using SCRUM. It fits the process of this project much better.

Of course, we get lots of Web 2.0 hype along with the project. Maybe it’s just me, but I don’t see this whole ‘wave’ thing happening. I see linear progression from the start until now — stuff gets invented, other people add to that stuff, and it goes on and on and on. It’s not like we suddenly make completely different websites than we used to — we just use a few new techniques in addition to what we already did.
In my view, Web 2.0 doesn’t exist. It’s more like Web 0.999999 — just like LaTeX is slowly progressing in version to e, and TeX is slowly converging to pi. There will probably never be a version 3.0 of LaTeX, because development right now simply adds to the existing shell, not a complete rebuild.

However, due to this being a Web 2.0 project, I proposed we used a wiki for requirements management. There will be multiple ‘owners’ of specific subsets of functionality. Right now, it’s a Word document that, at any given time, is being editted by multiple people. Even if you use something like Sharepoint, you will get versioning conflicts, even if people have been editting separate sections of the document.
A great way to step around this problem is to use a wiki. A functionality is a single wiki page, everybody always has the latest version available, and collaboration is a lot easier.

Me and my big mouth. My proposal was accepted, and now I have to install a wiki and worry about security and all that sort of stuff…
I use WAMPServer at home to build the webshop, so I already had a WAMP-stack available to experiment with. It runs on Windows XP Pro, which is exactly what it will have to run on in the early stages of the project (just a machine tucked away somewhere, not even an official development server or something like that, because we have to be flexible).
So this morning I downloaded the MediaWiki, which is the software the Wikipedia runs. Fortunately, it uses PHP and MySQL, and after unzipping a file and a few mouse clicks, I succeeded in installing the software. And another round of reading through the documentation allowed me to close the wiki off for non-logged-in users, and to enable file uploads.

Our CMS is a servlet, so I also researched how to connect Apache to Tomcat under windows. I hope I have enough time on tuesday morning to install all that stuff…

I like tinkering with stuff like that. Especially if other people already did the hard work for me and all it takes is a bit of tweaking of configuration files!

Recruitment stupidity

So, I have an account over at Hyves — some sort of networking site, except painfully slow. I had my account for about a week when I was approached by a recruiter.

Somehow, recruiters all have the same strategy. They all stress that their account is such a large company. They all want your CV and your contact details so that they can simply pattern-match in their database.
This recruiter was no different.

So I explain that I work at a relatively small company, that I don’t want to work for a large company, that I don’t fancy travelling a lot, that I don’t want jobs that are primarily programming. I gave a short description of my current work, what liked about that and what I didn’t like so much.

Her answer? “Please call me about this job in Brussels!”

I don’t know whose mails she has been reading, but surely not mine.

Crawling losers

We have a foosball table at work. Some of my colleagues are really, really into that game — there’s also an internal competition, etc. One of the unofficial rules is that if you get beaten with a 10-0 score, you have to crawl under the table. I guess it’s a bit like keelhauling.

So one of my colleagues made a site, KruipendeStumpers (which loosely translates to ‘crawling losers’) with photos and movies of people crawling under the foosball table.

Software development is like armed combat. There is a target functionality, and you need to cover it completely. The difference between large and smaller project teams is how they equip their troops.

You see, if you have a small target and few people, it is feasible to equip them all with rifles. Using squad-level tactics, you can deploy your troops quickly and reactively. If the target moves (that is, the client changes some of the requirements of the desired functionality), all it takes is a slight adjustment in aim to continue to cover the target. Small project teams are very agile, and are best suited for building small systems.

As targets increase in size, you can do one of two things.
One is to add more rifle-equipped troops. This has a practical upper limit, because of diminishing returns — at a certain point, your troops start to move into eachother’s line of fire, communication gets harder, and things may degenerate into chaos. See also: The Mythical Man-Month.

The second possibility is to change the equipment of your troops. Instead of four rifle-men, you could man a piece of artillery with four people. The number of people stays the same, but the power of the process is much higher — which means you can cover even larger targets in the same time. In software development, the whole set of project methodology, requirements analysis, better tools and a strict programming methodology is the equivalent of a large-caliber cannon.
However, it has a drawback: the artillery needs careful adjustment to hit the target just right. Customers sometimes balk when they find out there is a lot of ‘overhead’ associated with their projects: project managers, pre-sales consultants, requirements analists, etc. All these people add to the project, but they don’t directly build the solution. But because of their work, the actual developers can operate so much more efficient — nailing the target at the first try.

But it gets worse. If the client changes the specs mid-way (thus ‘moving the target’) all of the careful calibration of the cannon might have been useless. If you’re aiming at a bunker somewhere, but then suddenly you have to take aim at a tank that comes over a hill somewhere else — it takes time to re-aim the cannon!
So, a strict and thorough project methodology isn’t really suited for small projects. But having a cannon pays off for large projects, because you can nail the project with a single, well-aimed hit.

With me so far? Then, here’s the lesson of the past two weeks:

It all goes to hell if you try to do a large project and equip all your engineers with the equivalent of rifles. Then, when you find out it isn’t going to work, call in the guys with the artillery at the last minute — but don’t adjust your plan of attack for it (that is, don’t fix the specs beforehand). Then react snarky if they balk at doing stuff that could more easily be one by a rifleman. And whatever you do, don’t manage the project! It might cramp your style!

H. didn’t complain about the Angelic Layer Character Vocal Album. He complimented me on my choice of music, even — though that was when I played the Propellerheads.

I feel more confident now. Tomorrow, it’s the Seatbelts live concert, and perhaps the .hack//SIGN soundtrack!

Musique non stop

When we moved into the new office, about a year ago, I got to share a room with B. and D. I immediately instated a ‘headphone-only’ policy, because I had to listen to B’s choice of music before. He likes rap and R&B, which in itself isn’t so bad. But he had a list of about 10 songs, which he put in Winamp’s shuffle with repeat — so the whole day, I was listening t the same songs over and over again. Needless to say that I got tired of it rather quickly.
On the other hand, I didn’t want to inflict my collection of anime soundtracks on my colleagues either — so everybody used their headphones and all was right in the world.

Due to various project circumstances, last week monday, H joined the team on the room, taking D’s place. B wasn’t present, and H asked about the strict ‘headphones-only’ policy. So I told him about B’s choice of music and my choice of music, and he was curious whether this “überhappy Japanese pop” was as bad for his mental health as I made it out to be. We do have a set of speakers in the room (to be used by B when I am away), so I hooked up my computer to the speakers and blasted the album ‘April’ by Round Table and Nino (known from the opening theme to Chobits). To my amazement, H admitted that he kinda liked the tunes. So I put on some Maaya Sakamoto, which he liked as well.

Then B came back. I was ready to unhook the speakers, but he said that he was OK with my choice of music. So I played the soundtrack to Haibane Renmei. And they were OK with that too.

So now I have been promoted to the room’s DJ, completely out of left field. I do play other stuff than only J-pop, and so far I have had only one complaint: Kraftwerk was too monotonous for H’s tastes.

I wonder when it gets too weird. Maybe I should play the Angelic Layer Character Vocal album — if they don’t protest against that, then anything in my private MP3 collection should be OK…