Probably last photo from the Beijing series.
Sunday, March 18, 2007
Goodbye and welcome!
It's time I got serious. Well, sort of. This means that from now on, my serious thoughts and more thorough writings on software architecture and management in general go into a separate blog called Human Architecture and the rest of my passions and moans will stay at The Place for BelZaah. Let's just say that posts going "I had a crappy day" and "A software architect at Skype thinks this or that" really should go to two different places.
Saturday, March 17, 2007
Friday, March 16, 2007
Start of a tradition?
I have been quiet for almost a week because last weekend kind of slipped past before I could grip it and this week I have been in London (missing my camera badly as the weather was brilliant). On flights and airports I did some organizing on my feeds, added a bunch of friends and decided to start posting daily (or at least very frequent) photos, maybe with some stories attached to them. Let this be a good start and let's see how far do I get.
A guard at Tiananmen Square at sunrise. October 2005.
A guard at Tiananmen Square at sunrise. October 2005.
Thursday, March 08, 2007
Correction on the smokes
Apparently, when writing about the wolf smoking cigarettes the other way around a couple of posts ago, I was plain wrong. As a friend pointed out, he is smoking a specific brand of soviet smokes called "Belomorkanal" (White Sea Channel, also look at my post about history) which have a very long white filter and short gray part with tobacco.
Silly me, then. Also, he was kind enough to point out that 1411200 roubles will get you a railway wagon (560 000 packets) of those things. The fact that somebody actually knows that is kind of spooky. Anyway, thanks for helping out!
Silly me, then. Also, he was kind enough to point out that 1411200 roubles will get you a railway wagon (560 000 packets) of those things. The fact that somebody actually knows that is kind of spooky. Anyway, thanks for helping out!
Wednesday, March 07, 2007
It's spring
This morning I discovered that it is almost possible to take a shower without turning on the lights, it's that light outside. Also, the weather is getting warm (ish), the birds are singing like crazy and there is a crow building a nest right behind the window of some of our developers. Weee!
Monday, March 05, 2007
Comments on the Architecture post from 3/3
Sergei made a valid comment on that post. The thing is that the layers are of different dynamics: the organizational structure changes much more often than the functional architecture which is in turn more dynamic than the technical architecture. Which means that any reorganization creates tension on functional architecture. If the tension is not handled and the two layers not synchronized, one of them breaks: either the functional architecture breaks apart with all the consequences to the underlying layers or the reorganization fails and is reverted.
Some old photos
Got delivery of Epson R800 last week which, after some initial issues with paper handling, is doing brilliant work. Printed out some views of the Golden Gate Bridge I took almost a year ago and discovered they are not in flickr yet. Fixed it. Also uploaded some new pictures of our Maine Coon. What a tail, eh?
Saturday, March 03, 2007
Wait for me, rabbit
The other day somebody sent me a link to a youtube video that had scenes from an old Russian cartoon, "Nu pogodi, zajets", remixed and combined with a soundtrack by Rammstein. The video was not that good but the "Related" links rocked: somebody has uploaded all the old Nu Pogodi episodes every soviet kid adored! I had jolly good times watching them. They just do not make stuff like this any more. The whole thing is full of platnoi (sort of crook in Russia, amazingly google could not spit out any good links and my keyboard is too weak to go into detail here) references, signs of Soviet everyday life, reflections on different campaigns that frequently sweeped the great country and so on.
Also, they are refreshingly politically incorrect. And not in a way South Park is (which is apparently created under influence of controlled substances without any desire to reflect reality) but it shows how things really were. Look at the very first scene of the third episode. The wolf steps out of a makeshift garage (a _very_ familiar sight for everyone who has lived in the USSR) and lights a cigarette. And he lights it from the filter side.
And the music. It's a miracle: every scene has it's very own piece of music perfectly matched to it. The authors have not confined themselves to one style, oh no. They have picked tunes from folk to propaganda to rock to pop. Marvelous!
As opposed to Tom & Jerry and others, these cartoons were produced in very low volume. Between 1978 and 1985 only 15 episodes were made. In fact they produced more but the ones above 15 are not true to the original spirit and can not really be considered as part of the series.
Part social experiment, part attempt to amuse the crowd, I played one episode to my class during a coffee break. They are a mixed lot of various ages looking to get an additional degree in accounting. Most of the people enjoyed it and knew most of the scenes by heart but there actually were a couple of people to whom it really didn't say anything. On one hand it is a pity we don't remember good things that are not yet that ancient. On the other, it is probably better there is a new generation for whom the Soviet times is just something their parents sometimes talk about.
Also, they are refreshingly politically incorrect. And not in a way South Park is (which is apparently created under influence of controlled substances without any desire to reflect reality) but it shows how things really were. Look at the very first scene of the third episode. The wolf steps out of a makeshift garage (a _very_ familiar sight for everyone who has lived in the USSR) and lights a cigarette. And he lights it from the filter side.
And the music. It's a miracle: every scene has it's very own piece of music perfectly matched to it. The authors have not confined themselves to one style, oh no. They have picked tunes from folk to propaganda to rock to pop. Marvelous!
As opposed to Tom & Jerry and others, these cartoons were produced in very low volume. Between 1978 and 1985 only 15 episodes were made. In fact they produced more but the ones above 15 are not true to the original spirit and can not really be considered as part of the series.
Part social experiment, part attempt to amuse the crowd, I played one episode to my class during a coffee break. They are a mixed lot of various ages looking to get an additional degree in accounting. Most of the people enjoyed it and knew most of the scenes by heart but there actually were a couple of people to whom it really didn't say anything. On one hand it is a pity we don't remember good things that are not yet that ancient. On the other, it is probably better there is a new generation for whom the Soviet times is just something their parents sometimes talk about.
On architecture
I have been thinking that there should be a generic way to express the role of an architect in an organization and thus also helping people be better architects. So here it comes.
The layers
Architects know that system architecture is not a thing in itself, it is strongly bound to how an organization works in general. There are authors who have thought about that to some extent (like Christophe Longépé) but they usually only look at the technical or functional side of the systems. It seems to be much wider than that, let's build a stack here:
Let's explore this layering using an example. Let's say a system architect has three projects on the table for evaluation, each of them approaching the concept of a corporate customer from three different angles creating a technically unsolvable puzzle: although the architect sees that it would make sense to have the three systems talking to each other this can not be done because one treats companies as phone numbers with some fields attached, the second one as a source for authentication information (several customers can operate under the same legal agreement) and the third as an entity that has to pay VAT.
How did it come to this? Apparently all of the layers were affected. Firstly, the organization was set up as a set of silos which do not talk to each other, which leads to the three different unsynchronized projects being initiated.
Secondly, the functional architecture consists of a phonebook, a list of warrants describing who can do what business with the company and an accounting system. This poor setup gives the business units no support in their quest for solving their business problems and getting money pouring in.
The technical architecture, the third layer, now has to face the situation and figure out a way to solve this. As forcing the business people back to the drawing board does not work (remember, there are silos and nobody has ever spoken to them about the concept of a unified customer view) and re-writing all existing systems would blow the budgets of all three projects all there is to do is to build three separate systems. Which, as the architect knows, will lead to an integration nightmare the moment somebody discovers it would make sense to have the ability to have the company phone number displayed along the agreement information so the legal people can conveniently place calls.
The support layer now faces even more trouble: instead of having one or two applications to deploy there is three, all of which have different availability requirements, different release cycles, different versioning schemes and so on.
In short, a problem in an upper architecture layer leads to a growing amount of issues on its way down. Actually, the same applies to the opposite direction. Imagine a setup where two different outsourcing partners (one using RUP and the other XP) are forced to work together to tightly integrate their applications as there has been a change in the organizational structure. The very least that will happen is that the applications remain separated and the business guys suffer acute schizophrenia while participating in a planning game in the morning and compiling requirement artifacts in the afternoon.
The conclusions
Following conclusions can be drawn from the layering concept:
The layers
Architects know that system architecture is not a thing in itself, it is strongly bound to how an organization works in general. There are authors who have thought about that to some extent (like Christophe Longépé) but they usually only look at the technical or functional side of the systems. It seems to be much wider than that, let's build a stack here:
- Organizational architecture. This layer answers questions like what business are we in? How do different parts of organization relate to each other? What are the core principles the organization lives upon? What business processes do we have?
- Functional architecture. Every organization performs a certain set of functions in its everyday life. This layer deals with what clumps of functionality (like accounting, HR, customer service etc.) there are and how they interact.
- Technical architecture. This is the domain usually attributed to technical architects and deals with logical components, integration methodologies, middleware and so forth.
- Support architecture. The layer consists of processes tools, and organization that works underneath the technical architecture. Version control setup, release and testing procedures, coding conventions, team interaction, development methodology etc.
Let's explore this layering using an example. Let's say a system architect has three projects on the table for evaluation, each of them approaching the concept of a corporate customer from three different angles creating a technically unsolvable puzzle: although the architect sees that it would make sense to have the three systems talking to each other this can not be done because one treats companies as phone numbers with some fields attached, the second one as a source for authentication information (several customers can operate under the same legal agreement) and the third as an entity that has to pay VAT.
How did it come to this? Apparently all of the layers were affected. Firstly, the organization was set up as a set of silos which do not talk to each other, which leads to the three different unsynchronized projects being initiated.
Secondly, the functional architecture consists of a phonebook, a list of warrants describing who can do what business with the company and an accounting system. This poor setup gives the business units no support in their quest for solving their business problems and getting money pouring in.
The technical architecture, the third layer, now has to face the situation and figure out a way to solve this. As forcing the business people back to the drawing board does not work (remember, there are silos and nobody has ever spoken to them about the concept of a unified customer view) and re-writing all existing systems would blow the budgets of all three projects all there is to do is to build three separate systems. Which, as the architect knows, will lead to an integration nightmare the moment somebody discovers it would make sense to have the ability to have the company phone number displayed along the agreement information so the legal people can conveniently place calls.
The support layer now faces even more trouble: instead of having one or two applications to deploy there is three, all of which have different availability requirements, different release cycles, different versioning schemes and so on.
In short, a problem in an upper architecture layer leads to a growing amount of issues on its way down. Actually, the same applies to the opposite direction. Imagine a setup where two different outsourcing partners (one using RUP and the other XP) are forced to work together to tightly integrate their applications as there has been a change in the organizational structure. The very least that will happen is that the applications remain separated and the business guys suffer acute schizophrenia while participating in a planning game in the morning and compiling requirement artifacts in the afternoon.
The conclusions
Following conclusions can be drawn from the layering concept:
- A poorly set up layer "radiates" issues to the neighboring layers. For example, a poor technical architecture leads to problems in deployment because of unmanageable dependencies and a weird organizational structure leads to a weird functional architecture.
- A major change in any of the layers causes changes in every layer with the impact getting weaker the further you get from the source of the change. What is interesting about this one is that it usually only applies downwards. If changes start filtering upwards, something is very badly broker somewhere as there should not be any technical change without a business cause.
- The model shows a weak spot most of the companies happily ignore: the fact that nobody is really responsible for the functional architecture layer. However, it acts as a filter between top and bottom layers and thus, if undeveloped, hinders all cooperation between them. The only conclusion to draw from here is that a system architect needs to make darn sure that part of the stack is under control taking it to him or herself if necessary.
Friday, March 02, 2007
Thursday, February 22, 2007
On history
Recent drum-beating around a certain statue in Tallinn and the statements of a certain party leader almost had me on a brink of writing a long and angry post on how evil ideologies still linger on just because they managed to kill off another evil ideology and how they affect the ability of people to see situations from another perspective.
I am not going to. There's no point. Instead, I suggest (assuming you are already familiar with the basic ideology of the Nazi party) you read up on following topics and books. Google is good, wikipedia can be altered, books by academic historians are the best.
I am not going to. There's no point. Instead, I suggest (assuming you are already familiar with the basic ideology of the Nazi party) you read up on following topics and books. Google is good, wikipedia can be altered, books by academic historians are the best.
- The White Sea Channel and its economic importance. Hint: a couple of years ago one still could buy cigarettes with that name in St. Petersburg
- The Vlassov Army
- Metsavennad (the Forest Brotherhood). Hint: the last of them in Estonia was killed in 1976 _after_ the Beatles had come and gone.
- The White Book
- The GULAG Archipelago by Alexandr Solzhenitsõn
- Resistance movement in Ukraine
- The Volga Hunger
- Katõn
- Molotov-Ribbentrop Pact
Wednesday, February 21, 2007
Chaos and agility
The organization I work for has grown tremendously over the last couple of years and I am talking more than 100% per annum in terms of headcount. This is not something one can deal easily with from the standpoint of development processes and how people think of them.
In the very beginning we had the Agile Manifesto on our fridge door. We sure as hell did not follow it but at least we knew it was there. Nowadays nobody really remembers or talks about it any more. There are committees and processes and papers and things. The funny thing is that none of it really seems to improve anything that much: we are doing pretty well as we were, the levels of frustration have not changed (the kind of them has, however), and we do not stick to deadlines not more and not less than before. There are, however, massively more people around and more projects going on which means more mistakes will be made and more deadlines missed and the _number_ of people who get bruised is bigger. Which makes the problems more obvious and hence leads to more processes.
The reason I am writing this is that I mentioned how most people mix up chaos and agility (as much as they tend to mix up bad intent with stupidity, but that's another story) and people started laughing. I dropped the same line a couple of hours later and got the same reaction. Clearly, this was not obvious to the people around me and that got me thinking. And lead to this post. Anyway.
The reason we have not managed to increase our development throughput (not that it is bad, vice versa: we spit out more innovation at higher speed than most) or keep levels of frustration under control is thinking that replacing agility with a more stringent set of regulations will help to create order and make us more predictable. Wrong. What we are actually doing is replacing development chaos with regulated chaos. Think of a bucket full of cockroaches. Now imagine you insert the internals of a wine crate (you know, the thing dividing a box into 6 sections comfortable for a bottle) into it. Do you get more order? No. You get an illusion of order but within the 6 sections, the very same fizzling and buzzing goes on.
The attitude of people does not change when you introduce processes or try to enforce more rules. They still (as a group, not necessarily as individuals) prefer a chaotic approach because they do not know better and it has served them well. Coming back to my point about chaos and agility: agile development processes have some of the most complex rules systems I have known. Look a http://www.extremeprogramming.org/. The stuff is complicated! This is why it is so difficult to pull off successfully. It sure looks chaotic to the naked eye used to clean lines of a waterfall. This is why every company who for whatever reason has not implemented a software development process can hide behind the shield of agility and say "We did agile, it did not work and now we have RUP and everybody is happy. Well, at least they know why their lives suck now."
Well, I guess what I am trying to say is that as long as one replaces an un-organized chaos with an organized one under the sign of implementing a process one can not hope any major improvements. One should focus on the people instead (Individuals and interactions over processes and tools) and see that their needs are taken care for by maybe taking the Manifesto close to ones heart. Managing processes and business is easy. Managing people is hard.
In the very beginning we had the Agile Manifesto on our fridge door. We sure as hell did not follow it but at least we knew it was there. Nowadays nobody really remembers or talks about it any more. There are committees and processes and papers and things. The funny thing is that none of it really seems to improve anything that much: we are doing pretty well as we were, the levels of frustration have not changed (the kind of them has, however), and we do not stick to deadlines not more and not less than before. There are, however, massively more people around and more projects going on which means more mistakes will be made and more deadlines missed and the _number_ of people who get bruised is bigger. Which makes the problems more obvious and hence leads to more processes.
The reason I am writing this is that I mentioned how most people mix up chaos and agility (as much as they tend to mix up bad intent with stupidity, but that's another story) and people started laughing. I dropped the same line a couple of hours later and got the same reaction. Clearly, this was not obvious to the people around me and that got me thinking. And lead to this post. Anyway.
The reason we have not managed to increase our development throughput (not that it is bad, vice versa: we spit out more innovation at higher speed than most) or keep levels of frustration under control is thinking that replacing agility with a more stringent set of regulations will help to create order and make us more predictable. Wrong. What we are actually doing is replacing development chaos with regulated chaos. Think of a bucket full of cockroaches. Now imagine you insert the internals of a wine crate (you know, the thing dividing a box into 6 sections comfortable for a bottle) into it. Do you get more order? No. You get an illusion of order but within the 6 sections, the very same fizzling and buzzing goes on.
The attitude of people does not change when you introduce processes or try to enforce more rules. They still (as a group, not necessarily as individuals) prefer a chaotic approach because they do not know better and it has served them well. Coming back to my point about chaos and agility: agile development processes have some of the most complex rules systems I have known. Look a http://www.extremeprogramming.org/. The stuff is complicated! This is why it is so difficult to pull off successfully. It sure looks chaotic to the naked eye used to clean lines of a waterfall. This is why every company who for whatever reason has not implemented a software development process can hide behind the shield of agility and say "We did agile, it did not work and now we have RUP and everybody is happy. Well, at least they know why their lives suck now."
An interception with regards to Toivo: we really did not hide behind that one back in the days. We just figured getting cool stuff out the door is more important than the ability to express exactly how we are doing it by implementing a particular methodology. And your method sure worked!
Well, I guess what I am trying to say is that as long as one replaces an un-organized chaos with an organized one under the sign of implementing a process one can not hope any major improvements. One should focus on the people instead (Individuals and interactions over processes and tools) and see that their needs are taken care for by maybe taking the Manifesto close to ones heart. Managing processes and business is easy. Managing people is hard.
Strange days
Strange days have found us. Spot the line? Yes, it's the Doors. It has been rather like that the last week or so. My health is slowly deteriorating (although very difficult to point out anything in particular), anything I do at work moves slowly and I amaze at my inability to figure things out, I can't take any decent pictures, I loose things (forgot my tripod to the woods and my laptop charger to school) which is something I have not done for ages. Shit, I think I need a vacation.
Monday, February 12, 2007
On culture
This weekend I had two pretty shattering culture-related experience and would like to share those with you.
The first one occurred on Saturday. I was driving through southern Estonia. It was about -20 degrees C, the sun was shining, the road was perfect, the country was all white and I had 320 bhp under my right foot. Even more, I had the CD from Metsatöll and RAM performing works of Veljo Tromis among others in my changer. Let me give you some background. Metsatöll is an Estonian pagan/folk metal band that has gained a considerable following in recent years. They have managed to fuse very sincere and simple, yet powerful, lyrics with oldschool metal sounds that are combined with old natural instruments. Very impressive. RAM is the only professional male choir in the world. Imagine a 50 strong party of men singing of their ancestors, old gods and harsh nordic nature. Veljo Tormis is the man solely responsible for me becoming a metal-head. This happened after I saw his The Curse Upon Iron performed by Tõnu Kaljuste and his choir on TV. If you have not had the pleasure, I suggest you imagine O Fortuna by Carl Orff. Imagine this being performed in dark winter's night by roughly 30 young people clearly enchanted by the whole thing carrying torches and singing around a fire. Insert the most powerful lyrics you can imagine. Add shaman dums. That gives roughly a third of the experience. Having all of those components - RAM, Metsatöll and Tormis - thrown together in a live performance is something that one can't put to words. They did both Litany to Thunder and Curse Upon Iron and I floored it with sun in my back and bitter cold Estonia rushing past. That was just perfect.
The other culture shock I had was related to mr. Tolkien. I got my hands on my old copy of Estonian translation of The Hobbit (1977) on Sunday. It barely resembles a book any more and wears many stains resulting from the nasty habit of reading while eating I had as a kid. The illustrations by Maret Kernumees have defined how Gollum and Smaug looks like for me (considerably different from other illustrations I have seen and totally different from the movie) and perfectly accompany the text. Also, the translation is very good (as opposed to the horror put among us with the Trilogy). I don't know whether this is because of the nostalgic value, the fact that this was the first Estonian book I have read in a long time (being put off by the same horrible translations) or the fact that this is a work of genius, but I swallowed it in a day and enjoyed every last minute of it.
In essence, I got very little done during the weekend but I still immensely enjoyed it.
The first one occurred on Saturday. I was driving through southern Estonia. It was about -20 degrees C, the sun was shining, the road was perfect, the country was all white and I had 320 bhp under my right foot. Even more, I had the CD from Metsatöll and RAM performing works of Veljo Tromis among others in my changer. Let me give you some background. Metsatöll is an Estonian pagan/folk metal band that has gained a considerable following in recent years. They have managed to fuse very sincere and simple, yet powerful, lyrics with oldschool metal sounds that are combined with old natural instruments. Very impressive. RAM is the only professional male choir in the world. Imagine a 50 strong party of men singing of their ancestors, old gods and harsh nordic nature. Veljo Tormis is the man solely responsible for me becoming a metal-head. This happened after I saw his The Curse Upon Iron performed by Tõnu Kaljuste and his choir on TV. If you have not had the pleasure, I suggest you imagine O Fortuna by Carl Orff. Imagine this being performed in dark winter's night by roughly 30 young people clearly enchanted by the whole thing carrying torches and singing around a fire. Insert the most powerful lyrics you can imagine. Add shaman dums. That gives roughly a third of the experience. Having all of those components - RAM, Metsatöll and Tormis - thrown together in a live performance is something that one can't put to words. They did both Litany to Thunder and Curse Upon Iron and I floored it with sun in my back and bitter cold Estonia rushing past. That was just perfect.
The other culture shock I had was related to mr. Tolkien. I got my hands on my old copy of Estonian translation of The Hobbit (1977) on Sunday. It barely resembles a book any more and wears many stains resulting from the nasty habit of reading while eating I had as a kid. The illustrations by Maret Kernumees have defined how Gollum and Smaug looks like for me (considerably different from other illustrations I have seen and totally different from the movie) and perfectly accompany the text. Also, the translation is very good (as opposed to the horror put among us with the Trilogy). I don't know whether this is because of the nostalgic value, the fact that this was the first Estonian book I have read in a long time (being put off by the same horrible translations) or the fact that this is a work of genius, but I swallowed it in a day and enjoyed every last minute of it.
In essence, I got very little done during the weekend but I still immensely enjoyed it.
Wednesday, February 07, 2007
London calling
It has been a while since the last post. Seems the frequency of me getting time and urge to write is correlated to the amount of work I have to do. So this must mean I have a lot to do right now, which is good. I have also been working on an article on architecture role in the organization but it is a longer post and still needs work.
So, am in London again. Firstly, let me tell you about this wonderful hotel I was staying at. And no, they are not paying me for this and this is no spam. The place really is that good, I probably had the best hotel experience anywhere in the world. The place is called Ambassador Hotel Bloomsbury. The room was very tiny but well laid out and OK for one night. It is a fairly modern place with nice design touches everywhere but unlike some places it still manages to be perfectly functional: you never have to look for anything, it's just there. To top it all up, the breakfast was astounding: very nice choice of mainly French products combined with elements of traditional English breakfast. Just perfect. The only gripe really was that there was a door close by that sent shivers through my room every time it was closed but that didn't happen that often so it was OK.
This trip has been very nice otherwise, too. The weather is beautiful with blue skies and just a little bit of frost to keep things winterly fresh. After landing in London City Airport I decided to go for train + tube instead of a taxi which takes ages and costs a small fortune due to miserable traffic in the mornings. Have not dared to do so before because of general distrust in public transport but boy was I wrong. The train arrived in 2 minutes (in perfect accordance with the posted timetable), was fast, clean and reasonably crowded. Why on earth is public transport in Tallinn slow, unreliable, smelly, always crowded to the max and you have to walk for 45 minutes before you get to it.
Anyway, the train took me through Docklands which is a mess of industrial estate, huge old residential blocks, four level junctions, playgrounds and branches of Thames. Does not sound like much but is strangely beautiful to look at. Would love to go there for pictures some time.
All in all, it has been great (Estonian Air still has a chance to mess it up but hopefully they won't) and there is a growing feeling that I need to come for a weekend and take a ton of photos.
So, am in London again. Firstly, let me tell you about this wonderful hotel I was staying at. And no, they are not paying me for this and this is no spam. The place really is that good, I probably had the best hotel experience anywhere in the world. The place is called Ambassador Hotel Bloomsbury. The room was very tiny but well laid out and OK for one night. It is a fairly modern place with nice design touches everywhere but unlike some places it still manages to be perfectly functional: you never have to look for anything, it's just there. To top it all up, the breakfast was astounding: very nice choice of mainly French products combined with elements of traditional English breakfast. Just perfect. The only gripe really was that there was a door close by that sent shivers through my room every time it was closed but that didn't happen that often so it was OK.
This trip has been very nice otherwise, too. The weather is beautiful with blue skies and just a little bit of frost to keep things winterly fresh. After landing in London City Airport I decided to go for train + tube instead of a taxi which takes ages and costs a small fortune due to miserable traffic in the mornings. Have not dared to do so before because of general distrust in public transport but boy was I wrong. The train arrived in 2 minutes (in perfect accordance with the posted timetable), was fast, clean and reasonably crowded. Why on earth is public transport in Tallinn slow, unreliable, smelly, always crowded to the max and you have to walk for 45 minutes before you get to it.
Anyway, the train took me through Docklands which is a mess of industrial estate, huge old residential blocks, four level junctions, playgrounds and branches of Thames. Does not sound like much but is strangely beautiful to look at. Would love to go there for pictures some time.
All in all, it has been great (Estonian Air still has a chance to mess it up but hopefully they won't) and there is a growing feeling that I need to come for a weekend and take a ton of photos.
Wednesday, January 31, 2007
Tuesday, January 30, 2007
How to become an arhcitect? Huh?
I was so outraged by an article referenced by TSS that I just could not help put create this post. Would you believe it, that somebody actually goes out and defines how to become an architect. What the heck is that? It's like trying to define how to become an artist or how to compose music or how to become a leader. Sure, there are technical skills to gather and you must read and have experience and all that but at the end of the day it comes down to sheer talent. Of having a vision and being able to execute on it. Anybody claiming they have guidelines on how to become one or in fact who an architect is and what it does clearly does not understand organizations and the software development process.
There, I said it. Luckily enough there is still hope as some comments on the page seem to reflect the same viewpoint.
Will go and try to calm down, promise.
There, I said it. Luckily enough there is still hope as some comments on the page seem to reflect the same viewpoint.
Will go and try to calm down, promise.
Monday, January 29, 2007
Revelations
Was in Tartu last with Mari last week for several reasons, one of which was to go to see "Kits õnge ja viiuliga", which is part of the Artists trilogy by Mart Kivastik. Although some critics say the play is no good, I must object. I have never ever had such an deep-reaching experience before. Aleksander Eelmaa managed to play the role of Elmar Kits with such a clarity and sense that I thought I was looking into a mirror. It was all there. My fears, my feelings towards things unfinished, aging, friends, desires it was all there.
During the pause I wrote the following. I meant to post it separately but figured one would need some context:
To make it short: to learn most of things about me, go and watch that piece in Tartu or Vinnistu. And Mr.-s Eelmaa and Kivistik (also Tõnu Oja) are a bunch of geniuses.
During the pause I wrote the following. I meant to post it separately but figured one would need some context:
I do not know how to deal with debt. I just keep on giving and giving and can never find a suitable time to ask for it payed back. There is not even a thought of that. Although I need it, badly. I need it.
I have never had many friends. The few there were have grown apart or have been forgotten. I don't want to forget, I still remember them but can't find a way to tell them. What would there be to say anyway?
But still I remember the friends and the times we had.
"Tardo liin, va pordumaja"
Huh, guess visiting Tartu makes me nostalgic.
To make it short: to learn most of things about me, go and watch that piece in Tartu or Vinnistu. And Mr.-s Eelmaa and Kivistik (also Tõnu Oja) are a bunch of geniuses.
Thursday, January 25, 2007
Rebellion in wonderland
Do you know the feeling that somebody asks you a question about a decision you have made and you can't remember why you made that decision? Even more, with every question your decisions seems more and more unwise. Well, I just had this experience.
I have designed (actually put down a design that a team has come up with) a system that involves separating front- and back-end systems with a layer of request-response queues to improve robustness. The system has been mostly built already and is due to go into the QA cycle when some people in operations started asking questions about why we needed these queues. Indeed, as there has been a while since I was deeply involved in the design details, I could not come up with a better answer than "This makes the system more robust" without believing it myself. We ended up giving the topic a good brainwhacking and ended up with a decision to proceed as planned.
I guess this is something every project faces: at the very end somebody questions a decision nobody actually remembers reasoning for and manages to convince enough people that a design change is necessary. The only wise thing to do at this point is to note the suggestion and proceed as planned, because the cost of (and risks associated with) change goes up exponentially as the time goes. Hence, even small changes can prove disastrous at the final phase of a project. Ah, but the temptation is big and the guy might actually be right and if you as a project manager have not noticed the rebellion early enough a lot of people might already be infected and support the change. Tough luck, this is what you get for becoming a project manager. Or an architect.
I have designed (actually put down a design that a team has come up with) a system that involves separating front- and back-end systems with a layer of request-response queues to improve robustness. The system has been mostly built already and is due to go into the QA cycle when some people in operations started asking questions about why we needed these queues. Indeed, as there has been a while since I was deeply involved in the design details, I could not come up with a better answer than "This makes the system more robust" without believing it myself. We ended up giving the topic a good brainwhacking and ended up with a decision to proceed as planned.
I guess this is something every project faces: at the very end somebody questions a decision nobody actually remembers reasoning for and manages to convince enough people that a design change is necessary. The only wise thing to do at this point is to note the suggestion and proceed as planned, because the cost of (and risks associated with) change goes up exponentially as the time goes. Hence, even small changes can prove disastrous at the final phase of a project. Ah, but the temptation is big and the guy might actually be right and if you as a project manager have not noticed the rebellion early enough a lot of people might already be infected and support the change. Tough luck, this is what you get for becoming a project manager. Or an architect.
Subscribe to:
Posts (Atom)