MTB: The Otepää marathon

After a lengthy pause there was a decent marathon to ride and I took the opportunity. I mean, there was also the Värska marathon, but the organizational side was so horrible last year I chose not to go. If anyone reading this was there this year, please post some comments.
So, back to the Otepää marathon. The race starts on the worldfamous Tehvandi sport center (they host WM stages for cross-country skiing there) which has plenty of parking spaces and overall good facilities. As opposed to the Tartu marathon that starts at the same place this one also ends there, which is good. The only downside of the location is the long start coridor which makes people that were late with registration wait for an eternity before they can actually start riding.
From start on the trail goes through the city allowing for the riders to spread up. After the city, it's a couple of kilometers of wide asphalt that makes for good overtaking oportunities. This is not for long (otherwise it won't be a MTB marathon, would it?) and by the 20th kilometer you are experiencing the full beauty of the countriside which contains mainly of slopes. The ascent on the 22. km is the toughest (Harimägi, if you can be bothered) but not the only one. Actually the whole distance between 20. and 30. km is one big ascent followed by a steep descent. Pay attention here: the downward slopes are fast and usually very bumpy. For the first time I really understood why people invest into real good forks. After you have managed not to break your neck tehre, it's all pretty nice and smooth till the end. There is even a strech of good tarmac around the 44th km. If you still have some power left, it's a good place to pass some people who don't (I did pass two:)). The last part of the track turns back to the woods and is of no particular interest. However, this year the final kilometer was really wicked. You reach the stadium, see the finish line and forget what the computer's been saying: it must be the end and yes, you have to catch that last one guy and indeed you do. Turns out the computer was right about the distance after all and you are taken for a last strech up and down some hills along a narrow path. Which is the place where you run out of your last and the guy you triumphantly passed 100 m back leaves you standing. Nasty.
It's actually a quite nice track as it's real fast (helped by relatively try wether this year) but still has a total ascent of 655m according to my Polar which is a tad short of the nearly 800m of the Haanja marathon but way over an average of 450 or so.
As Blogspot is now allowing to add images to the posts (way to go!) I can finally show off my fancy hardware and share a track profile.

Redefining the triangle

To my major surprise people actually read my blog and I actually get some feedback :) One of the most useful ones was by Asko who pointed out that the Project Triangle of Death is in fact a rectangle. The corner I was missing is Quality. My first thought was to object as this aspect is included in the Functionality but after I while I got the point. Come to think of it, how often have you seen people actually considering what quality the delivered product could be? Everybody want's créme de la créme, does not want to pay for it and ends up with something rather less splendid. But this whole process of determining functional quality is rarely implicit. Yes, sure, people to project quality management all the time and even agree if you tell them that patching something together is cheaper than building anything solid. However, quality seldom participates in critical decision-making and hence deserves a place in the Project Rectangel of Death.

P.S. anybody having a suggestion for a less morbid name for this thing, please feel free to e-mail me :)

On agile development

I will be changing jobs in a couple of weeks. This wouldn't be anything to brag about if it weren't for the huge contrast between them. From managing IT in a state agency in a EU country to helping to let the whole world talk for free (that's Skype for the unknowing amongst you). From a strictly regulated and rigid environment that has been very successful in terms of delivering software to a free-flowing and agile environment that has also a shining success to present. Thinking of it, a question rose:

When doesn't it make sense to go agile?

By agile development I mean production of software according to the Manifesto for Agile Software Development and no I don't think there is something like purely agile or rigid methodology. Don't get me wrong, I am a huge fan of XP and I have been trying to implement things like small iterations and release planning but we ended up with something rather contrary to the Manifesto. Surprisingly enough, it works.

Could it be enforced specifications?
Working for a state agency in a EU country means that lot of the development resources go towards creating software that is either supporting a centrally agreed upon business process or has to talk to similar software in other member countris. In both cases you usually get delivered a pile of binders full of functional specifications and test scenario that have to be meticulously followed. Hence, no user stories, no tight customer envolvment (and sometimes it's all chinese for them, too) and no change. By the way, the purists among you should actually try to read 300 pages of functional test cases to understand what a system does :)
On the other hand, you get the best acceptance tests you can imagine and they sometimes even come with automation tools. Also, getting to know the system together can really draw the team together so customer envolvment can be achieved. The specifications usually do not cover how the system should look upon the screen and there are always things that are either not needed or have to act a bit differently because of the legal environment so there could actually be room for some change after all. Ergo, the enforced specifications alone can not be the reason not to do agile development.

Could it be the sourcing model?
As a state agency you are not free to choose whom you work with or how you choose them. Instead, you have to follow the procurement laws that tend to come bite your ass as soon you don't pay attention. Ever seen a deadline closing on your 1 mln euro project while a crappy CMM level 1 company is protesting your whole tender dossier in court? Also, unless you want to start arguing with all kinds of enforcement agencies ("what do you mean, collaboration over contracts?"), you have to be able to specify the whole project (including time schedule and budget estimates) in the Terms of Reference and, even worse, stick to it.
Even if you do the whole thing in-house you still have to live with the people you have. State officials are rather well protected (at least around here) and rather badly paid so assembling a good team might prove difficult.
Doesn't sound too promising for agile development does it? Actually, it could be done. There are ways to get a long-term framework contract going so you can build trust that feeds the collaboration, people can be trained and it is usually possible to shield the individuals and interactions from the cold breath of the tender process.
Once again, this can't be it.

What else?
As developing good tax and customs software has not been an easy task, there are lot of other difficulties that could be used to argue against the use of agile methologies in state agencies. However, if inspected closely, most of them turn out to be of purely technical manner or could be overcome with some well-directed effort. Hence, the answer must lie somewhere else.
It seems that it all comes down to the organizational culture. Governmental agencies usually have rather high centralization and/or formalization (google Roger Harrison to get an idea what i'm talking about) creating a mostly role or power based culture while agile development assumes orientation towards achievment and support (low centralization/formalization). So we end up with a rather worn-out statement that you should always choose the right tools for the right task. In our case, choose the development methodology to mach your organizational culture and, to answer the question stated in the beginning, it does not make sense to do agile development unless your whole culture supports that kind of thinking. Simple isn't it?

MTB: Haanja marathon

It was a while back (19th of June, to be precise) but I haven't come around to writing about it. The most prominent feature of this race was a total ascent of 785 m which is aproximately twice as much as an ordinary Estonian MTB marathon. for example:

Race	TA
Haanja	785
Tallinn (Kõrve)	415
Mulgi	525

In terms of organization and track preparation everything was excellent. The track combined steep slopes and woodland with gravel roads giving anough oportunities to rest. There is nothing much else to say about the race as there were no specifically dangerous sections and anyway, I was too busy pedalling uphill to note anything :)

MTB: Tallinna maraton

Abstract: Yet again a marathon I could successfully finish (I had a nasty accident last time). It was great fun but again, it feels kind of snobby to write in English about something so utterly Estonian.

Tallinna Rattamaraton
Rada oli tõesti hästi ette valmistatud ja väga mõistlikult üles ehitatud: tehnilisemad tõusud ja metsavehe vaheldus kenasti maantelõikudega. Selles mõttes oli tegu täieliku vastandiga Mulgi maratonile, kus kruusalõigule on vahele pikitud mõnisada meetrit heinamaad mis läheb uuesti kruusaks üle. Ei saa öelda, et see kuidagi kergem või raskem oleks, aga mulle meeldib nii rohkem.
Espordi foorumis (www.esport.ee) küsis keegi rehvide kohta ja sai vastuseks, et Kõrvemaal ei ole kunagi porikummi vaja läinud ja ei lähe seekord ka. Paraku taas kord näide sellest, et seesinane foorum on käest ära, kuna kusagil 20 ja 30 kilomeetri vahel oli _väga_ palju mudaseid kohti ja ka muus osas ei olnud rada just kuivemate killast. Kui ei usu, vaadake pilte (näiteks see). Kokkuvõttes kulusid porikummid täiesti ära, ilma oleks üsna raske olnud.
Nagu öeldud, oli rada väga hea ja konkreetseid nõuandeid ohtlikest või keerulistest kohtadest anda ei olegi. Ainus kindel nõuanne on mitte alustada lõpuspurdiga liiga vara. Viimasel viiel kilomeetril on kuus rämedat tõusu (20, 15, 10, 20, 10, 15 meetrit kõrguste vahet), nendeks on vaja jõudu varuda.

Photo: The Budapest file

This opens something I hope grows into a series of photography-oriented logs of places I happen to go. Hence:

Taking pictures in Budapest, Hungary
This is a wonderful city to take pictures at. I was there on 26th and 27th of May. It was unexpectedly hot, the weather was perfect and that set certain limits to photography. By 8 AM the light was already too harsh and sun too hot for any photography. I have been in Hungary once before in November las year mostly concentrating to the area around the Heroes' square on the Pest side. This time it was Buda and Danube. As the city is situated on steep banks of the river, the best time for photography depends on the precise location. Here some tips:

• The wonderful Parliament building is the nicest before 6 AM with the sun rising behind it, shortly before sunset around 8PM and after 9PM when the lights come out. The setting sun illuminates the Pest side only briefly as the western bank of Danube is rather steep and covers most of it.
• The Buda castle (and most of the Castle District) looks very good around 6AM with the rising sun iluminating it. In the evening it gets into shadow fairly quickly.
• The Fisherman's Bastion silhouettes against the evening sun under some angles and as it's built of white stone sunrise looks spectacular in early light.

Regarding the Fisherman's Bastion, it is the best place to take night shots of the Parliament building and the Pest coast but attention: on warm summer nights it is a popular spot amongst local lovedoves and finding a stable place for your tripod might be tricky. The bastion has a gallery with pillars each of which is decorated in a different way. Lot's of great detail shots to be had!

The Budapest is full of very well preserved or skilfully restored statues of white stone. The most prominent ones are different lions, four of whome watch the Lánchíd bridge and additional ones can be found scattered around the Castle District and lower riverbank on the Buda side.

One thing to keep your eyes open for are the dogs. Hungarians are fond of them and picturesque master-pet couples are commonplace. This means, however, that you are certain to step into dogpoop if you go strolling in the dark.

When going out to the Castle District early in the morning from the Pest side remember, that the historic elevator (looks nice and offers a spectacular view, btw) may not be open yet. The best alternative is a small rather well-hiden stairway across the street from the elevator entrance. It's quite a climb but the much longer route around the south end of the Castle is not easier (although it takes you by some beautiful lion statues)

Be certain to take a look at the Vajdahunyad Castle: it is not big, it is not that spectacular and it's a mock but is full of wonderful detail, especially in the autumn.

Some links:

• A professional-level gallery of commented pictures. Great for planning your trip http://www.earth-photography.com/Countries/Hungary/Budapest_photos.html
• My own set of pictures. http://photo.see.ee/coppermine/thumbnails.php?album=48
  

MTB: Mulgi rattamaraton

Abstract: I am kind of into MTB-ing and rode a marathon yesterday. This post is in Estonian as if you can't understand it you are very unlikely to ever come in 100 miles radius of Viljandi to actually make any use of the information.

5. Mulgi Rattamaraton
Tjah, sai teine eile läbi sõidetud. See oli hooaja esimene pikem sõit ja ei osanud väga miskit oodata. Siiski on kevadel kõvasti trenni tehtud ja lootused olid üleval. Sõit läkski hästi, õnnestus isegi natuke taktikat teha, kuid aeg kaks minutit üle kolme tunni on liiast. Rada oli üsna kummalise raskusatmega: väga kiired kruusased lõigud vaheldusid metsaradadega kus oli sees ootamatult suured takistused. Kümmekond meetrit põlvini muda puujuurte vahel või aasa peal, mis on tegelikult läbimatud. Samuti on paaris kohas järskude servadega maantee ja muidu kraave.

Raja enda kirjeldus on saadaval siin. Keerulisemad kohad olid sellised:

• Rada algab asfalditõusedaga linnas sees. Tuleb peale passida, kuna vahel tekivad rajale kõrged äärekivid
• 10. ja 20. kilomeetri vahel on kilomeetri jagu mullateed, mida keegi on üritanud telliste ja liivaga parandada. Tulemuseks rehvitapja (telliste teravad servad liiva seest välja turritamas), kehvema esimese amordiga on lihtne kukkuda. Sel ajal on keskmine sõitja veel põhimassis sees, rahvast on tihedalt ja tuleb olla ettevaatlik
• Kahekümnendate kilomeetrite teises pooles on pikem lõik kuusemetsa alust juurikatega teed. Aeglane ja raputab, kuid samas kergesti läbitav
• Viimased kolm kilomeetrit lähevad üle põllu ja läbi ühe sügavat sorti järsu seinaga kraavi. Rada on kitsas ja aukudega ning lõpeb saepuru täis aetud mülkaga. Asja teeb keerulisemaks, et selleks ajaks on kätte saadud matkasõidu lõpetajad ja trügimist on üksjagu

Kokkuvõttes: ilm oli hea ja sõita oli mõnus, aga rada oleks võinud ühtlasem olla ning tüütu oli kümme minutit finishikoridoris aja (!?) fikseerimist oodata. Paneks teile siia ka raja profiili, aga nähtavasti ei õnnestu Bloggerisse faile üles laadida :(

The Project Triangle of Death

Hi,

This is the first one in a series of posts on principles of IT project management from the customer perspective. The idea is to make my painful experiences public so others could avoid them. Here we go, stay tuned for more.

The Triangle of Death, part one.

If you have ever participated in a software (or, in fact, almost any other) development project you have probably made acquaintance with the fearsome creature that gave this post a name.
The Triangle of Death or ToD consists of Resources, Time and Functionality. These parameters of a project are obviously tightly interconnected and interdependent although these relations are often neglected, especially by management. One could imagine this triangle as three poles with a length of rope tied around them. If you move one of them, the rope pulls the others along or allows for others to move. Let's define the vertexes in a bit more detail

• Resources. By that we mean all kinds of resources available to the project. They include money, people, computers and so on and so forth. Basically everything that can be used to achieve the goal. By removing or adding resources the course of the project can be altered so either more functionality can be implemented (more people do more work) or the same amount of functionality can be implemented in a shorter amount of time (more people complete work faster). Bear in mind that these relations are not that strict. Often adding more people to a project makes things even worse and there are tasks that just take time (think of letting concrete harden)
  
• Time. It's obvious, isn't it? Every project has deadlines and more often than not the extent they are followed is the main criterion for evaluating a project's success. If we give the team more time, they can get more work done. If the deadlines are cut, more resources are needed or the functionality is compromised. Again, these relations are flexible to some extent so giving a project a infinite amount of time does not guarantee they can build you a rocketship
• Functionality. Ultimatively, no project is set up to burn a pile of money or give a group of people something to do. Well, that happens, but not that often :) Hence, a IT project must deliver a set of functionality at the end of the day. One should not think of the functionality in its narrow sense of summary of capabilities of a piece of software. Rather, every piece of output including documentation, changes in processes or even amount of customer satisfaction should be considered as functionality produced. If more functional burden is added to a project, either more time or more resources are needed to produce it and vice versa

Now knowing the components of the ToD it's time to ask "what's the point?". These relations are obvious enough (although often ignored) to be treated as common sense. It's true, of course. Worth to consider, however are some conclusion that can be drawn from these associations I'm trying to bring here.

The uncertainty principle
If one component of the ToD is uncertain, so are the others. The rule is not binary and a more correct wording would be "no components of the ToD can be more strict than the others". People perfectly capable of understanding that one can not go anywhere without knowing where to go in everyday life try to set strict deadlines and resources to projects with more than fuzzy functional requirements. The reason is, probably, that functionality is really difficult to describe throughly. Even estimating time and resources going to describing of the functionality requires specific skills and experiece. So you better make sure everybody inside the project and everybody counting on it have a good understanding of what is going to be produced. Otherwise bitter disappointment and/or heavy punishment will certainly follow.

Besides functionality that is extremely easy to get communicated in a fallacious manner, resources are also often misunderstood. The project manager, naturally, expects everybody to participate in the project full time and probably more. This is also calculated into the project schedule. People, however, have a myriad of other responsibilities and tasks to handle besides the project and have their direct boss giving them additional tasks in the worst case.

Here we go again

what is this about blogging that makes it so hot? Even me, who in the course of 10 years of more or less professional web building have not managed to create let alone update a personal web site, am blogging now.
Actually, it's my second attempt. The first one had three posts and was in my MSN Space. Kind of neglected that, after a while: too crublesom to log in to and no nice way to refere to it. MSN 7 is not yet widespread enough, anyway.
So, back to blogging. It seems that a surprisingly wide group of people has discovered a taste for writing. I don't think so may of us actually enjoyed writing essays at highschool but all of a suddeln there are blogs everywhere. Maybe it's just the ease of it? Or a strange flavour of exhibitionism? dunno, gotta be a psychologyst to figure that one.
The scale of blogs is rather surprising, too. They range from my own random thoughlets to comprehensive reviews of a specific matter as this really cool discussion of the XA protocol (found here) shows.
Which one is it gonna be for me? I could do some picture blogging (although I keep a up-to-date collection of my best pictures at the Home for Professional Amateurs). Also, there has probably been enough traumatizing project management and architectural experience in my life to produce some experience blogging. Or maybe start posting my Polar excercise files to start my own training blog? There is no way of knowing. It's probably gonna be a mix of those. So, if you happen to read this (beats me, how you got here, by the way) and can remember the URL, welcome back!