I work at one of the biggest accounts our company has. It is split into more than a few portfolios and each has an architect or two trying to provide some sort of consistency to the stuff we build - often against pressure from both the client and the project managers who only care about getting it done quickly and cheaply. (But I'll leave that for another post when I can write it down more objectively).
Recently the architects across account - or at least the more senior ones - were formed into a team to allow sharing of information and cross-pollination of ideas etc. An email alias was set up and a regular fortnightly meeting was arranged but the 'team lead'. Note where I said the team was formed - the concept, purpose and membership were controlled by the one person who thought it was a good idea for us to work together. I on the principle but the way it was done is doomed to failure.
The group was imposed on the members and the only communication channel ran counter to its purpose (I'll add a little sidebar on phone meetings soon - one of the worst way so of commnuicating yet devised). Everyone was happy to let the organiser to drive things. They were there because it sounded like a good idea but no-one know what they were supposed to add. Hence the email address was only used by the organiser to send out interesting links from the web and the meetings - when held at all - tended to last about 3 minutes beacuse no-one had much of anything to say.
Now the organiser of all this has announced that his resignation and I can see that the whole thing is going to fall in a heap. Which is a pity because, as I said, the intent was laudable. Collaboration between these people would provide all of us with a much better idea of the context in which we are operating and particularly on how we can make use of what is happening in other parts of the account (something that the client themselves have very little knowledge of).
In thinking about this, what we need is not a regular time-constrained meeting, either by phone or face-to-face. What we need is a virtual meeting place where people can add information about what they are doing, comment on what others are doing and generally share their knowledge. This is what social software is all about. A discussion board tied to a wiki would be the way to go. Somewhere that the individuals could get involved in rather than just coming along on someone else's ride.
Any relevant web-link could be commented on or extended with the discussion board. The Wiki could serve as a knowledge base with each person adding a page about their particular area as and when it suits. In theory at least, the effort requried by each person should be minimal while still creating something of lasting value to the team. Since the idea is to generate a team rather than just throwing together a group, the site should be somewhat less than formal, while still providing an induction point for any new starters. Yes, I am an idealist :-)
Unfortuntely there are no suitable sites within the company to do this. For an IT company - in the software development business - we are very conservative. There are a couple of sites designed for team collaboration but they require permissions from senior management to make any changes - such as creating a new wiki (think about that for a minute - staff need high level management sign-off to talk to each other!).
None of which is truly relevant. In the spirit of getting people involved, I sent an email to the group proposing the above and asking for suggestions on how to proceed. I got one response suggesting that a fornightly meeting might be useful.
Thursday, August 14, 2008
Wednesday, July 30, 2008
Architecture?
I’m an IT Architect. This makes it fairly difficult when people ask “what do you do?”. Generally, I just say “I work with computers”, which is true, misleading and, often, all the information that is necessary to provide. If I say that I am a software architect, the common response is to ask about CAD systems and techniques for designing buildings.
There have been several attempts to define the role of architecture in the IT industry. The one that I most recently saw was IASA who are trying to get it recognised as a profession, along with things such as accountancy, medicine, teaching etc. This is a goal which carries a number of implications which I am not going to try to go into here – their web-site has details if you want to follow that line.
None of which has any impact on the normal person that you find at a suburban barbeque. They still have no idea what you are talking about. If this person does have any further interest (which is unusual but not unheard of), it is useful to have a convenient metaphor at hand.
Personally I tend to go with the obvious analogy to building architects. Most people have some idea what they do but not enough for any pre-conceived notions to get in the way. As an alternate example, using medicine – such as Brook’s surgical team analogy (from Mythical Man-Month) - leads to more confusion than anything else. Everyone *thinks* they know what a doctor does, especially when they don’t.
But an architect? The use of the construction industry as a metaphor to computing has a long and distinguished career; starting with the term “Software Engineering”. There are all sorts of points where the analogy breaks down. With software the actual building is the simplest step and is fully automated (it is called 'compiling'); the construction is not placed on the site until after it is complete; and every new construction has some significant difference from every other construction. But none of these matters when you are describing your job, in 25 words or less, to someone who is making polite conversation.
When making the analogy I tend to put something like this:
Someone putting up a garden shed can, if they are handy, do the job themselves. Building a house requires a team that includes a number of specialists (plumber, electrician, etc). It usually benefits from having an architect but a senior designer is sufficient. For a 50 storey office block, you had better have a team of architects – many of them specialising in some aspect of the construction – and a single guiding view of how the finished product will look.
Similarly, a simple web-site can be put together by an average person with a bit of computer literacy. A well designed business application requires a team including specialists such as a database expert and a UI designer. It would benefit from architectural input, especially if it interacts with any other applications, but, depending on the size, you can get away with just a technical lead. A business critical application which operates at the enterprise (read - big company) level and services thousands (millions) of people requires some serious designing and oversight – and a single conceptual view is essential.
There are a number of key differences which also be covered. The construction industry has been operating for several thousand years; the computer industry has been in existence for only a few decades. Software is enormously more tractable than hardware (hence the name) and the limits of imagination are therefore more important than the limits of the available materials.
But there are also a goodly number of similarities. I have heard a number of comments about how difficult it is to correctly estimate for software. Engineers are notoriously optimistic about how long a project will take and how much it will cost. I have read a number of articles about how this is due to the nature of software and the fact that each new project is entirely new – by definition no-one has built it before (else they would just create a copy) and therefore estimation is very difficult. I used to believe this. Recently a major upgrade occurred to the railway which connects our town with the nearest capital city. The original estimation was $80m. Apparently the final cost, after all was said and done, ended up at $750m; and took a year longer than expected. The IT industry is not the only one that has trouble correctly estimating costs!
There have been several attempts to define the role of architecture in the IT industry. The one that I most recently saw was IASA who are trying to get it recognised as a profession, along with things such as accountancy, medicine, teaching etc. This is a goal which carries a number of implications which I am not going to try to go into here – their web-site has details if you want to follow that line.
None of which has any impact on the normal person that you find at a suburban barbeque. They still have no idea what you are talking about. If this person does have any further interest (which is unusual but not unheard of), it is useful to have a convenient metaphor at hand.
Personally I tend to go with the obvious analogy to building architects. Most people have some idea what they do but not enough for any pre-conceived notions to get in the way. As an alternate example, using medicine – such as Brook’s surgical team analogy (from Mythical Man-Month) - leads to more confusion than anything else. Everyone *thinks* they know what a doctor does, especially when they don’t.
But an architect? The use of the construction industry as a metaphor to computing has a long and distinguished career; starting with the term “Software Engineering”. There are all sorts of points where the analogy breaks down. With software the actual building is the simplest step and is fully automated (it is called 'compiling'); the construction is not placed on the site until after it is complete; and every new construction has some significant difference from every other construction. But none of these matters when you are describing your job, in 25 words or less, to someone who is making polite conversation.
When making the analogy I tend to put something like this:
Someone putting up a garden shed can, if they are handy, do the job themselves. Building a house requires a team that includes a number of specialists (plumber, electrician, etc). It usually benefits from having an architect but a senior designer is sufficient. For a 50 storey office block, you had better have a team of architects – many of them specialising in some aspect of the construction – and a single guiding view of how the finished product will look.
Similarly, a simple web-site can be put together by an average person with a bit of computer literacy. A well designed business application requires a team including specialists such as a database expert and a UI designer. It would benefit from architectural input, especially if it interacts with any other applications, but, depending on the size, you can get away with just a technical lead. A business critical application which operates at the enterprise (read - big company) level and services thousands (millions) of people requires some serious designing and oversight – and a single conceptual view is essential.
There are a number of key differences which also be covered. The construction industry has been operating for several thousand years; the computer industry has been in existence for only a few decades. Software is enormously more tractable than hardware (hence the name) and the limits of imagination are therefore more important than the limits of the available materials.
But there are also a goodly number of similarities. I have heard a number of comments about how difficult it is to correctly estimate for software. Engineers are notoriously optimistic about how long a project will take and how much it will cost. I have read a number of articles about how this is due to the nature of software and the fact that each new project is entirely new – by definition no-one has built it before (else they would just create a copy) and therefore estimation is very difficult. I used to believe this. Recently a major upgrade occurred to the railway which connects our town with the nearest capital city. The original estimation was $80m. Apparently the final cost, after all was said and done, ended up at $750m; and took a year longer than expected. The IT industry is not the only one that has trouble correctly estimating costs!
Wednesday, July 23, 2008
Analogies
I’m very fond of analogies when trying to explain something – even to my self. I find it much easier to grasp a concept when I can make reference to some other related concept, even when the relationship is very loose. In this context, stretching an analogy completely out of shape may reveal connections and interactions that otherwise remain hidden.
I am not someone who finds words easy – it does not map to the way I approach the world. It is always difficult to convert my thoughts into a single flow of information, especially one as slow as words. [This is, of course, a secondary reason for writing things done. It forces me to deal with words. I recognise that communication is an essential aspect of the world and that words, talking or writing, is a key part of this. It is a short-coming which I would like to overcome or at least mitigate].
I understand that the other major mental approach to concepts is visualisation. To see a representation of the concept in the mind’s eye. I guess this would be more common amongst artists and other right brain thinkers. The distinction between these two approaches has been illustrated by what flashes through one’s mind when the word ‘cat’ is said. Do you see the letters (of course you do – you are reading at the moment, but what if someone said it out loud) or do you have an image of a puppy appear in your head?
I do neither; instead it is more a ‘feeling’ or sense of pattern. Cat-ness as a sensation which encapsulates what I know about cats. In approaching a new area, I spend of lot of time trying to get a feel for the shape of the topic and how the different aspects fit within the whole. Hence analogies. A good analogy allows one to think about a new concept through the pattern of an existing, usually well understood, thought process. It gives a basic shape to a concept which can then be adjusted as more details become available and higher resolution becomes possible. There will always be aspects in which the analogy becomes tenuous and one must always be aware that derived detail is suspect. But an initial outline, a shape for the concept, provides a basis for understanding.
The IT industry has a great many similarities to the construction industry and the analogies have been pushed for decades - deliberately so mostly, such as referring to Software development as “Engineering”. Unfortunately pushing the similarities tends to hide the differences and expectations are set which cannot be met. Multiple analogies are required to provide different insights on the area and the areas of connection need to be highlighted to indicate where each is valid.
A quite different analogy is making its way through IT at the moment. It associates the new concepts of SOA and SaaS [I won’t attempt to explain these at this time. There is lots of information out there if you are really interested] with the manufacturing industry. Mostly this analogy is implicit but several years ago I saw a presentation which made the connection explicit (Microsoft’s “Metropolis” analogy). I don’t know why this approach hasn’t been followed since because I have seen many poor attempts to explain SOA which would have benefited from making the link to something that business people can understand.
Another very good analogy specifically for management of software projects was a connection to pathfinding in uncharted territory (there is a sport in Australia called ‘rogaining’ which is essentially this but I don’t believe it has yet taken off elsewhere). I don’t remember where I saw this description but it clarified enormously the trade-off between project needs and support needs. Do you waste time making a map of the territory to make it easier next time, or do you just race to the finish line for yourself?
Analogies in other areas include the concept of technical debt – linking maintenance costs to mortgage repayments. I have written articles on the association between knowledge bases and memory systems, corporate processes and instinctive behaviour. In a previous life in the fitness industry I found it useful to describe an analogy between body fat and personal finance (stored calories are like money in the bank – it even generates interest). There are some extensions to all of these which may prove enlightening – and potentially misleading.
Which leads to the major problem with analogies: getting too attached to one can easily lead to unconscious expectations when you reach an area where the analogy breaks down, or is incorrectly extended. You must always be aware that the map is NOT the territory.
I am not someone who finds words easy – it does not map to the way I approach the world. It is always difficult to convert my thoughts into a single flow of information, especially one as slow as words. [This is, of course, a secondary reason for writing things done. It forces me to deal with words. I recognise that communication is an essential aspect of the world and that words, talking or writing, is a key part of this. It is a short-coming which I would like to overcome or at least mitigate].
I understand that the other major mental approach to concepts is visualisation. To see a representation of the concept in the mind’s eye. I guess this would be more common amongst artists and other right brain thinkers. The distinction between these two approaches has been illustrated by what flashes through one’s mind when the word ‘cat’ is said. Do you see the letters (of course you do – you are reading at the moment, but what if someone said it out loud) or do you have an image of a puppy appear in your head?
I do neither; instead it is more a ‘feeling’ or sense of pattern. Cat-ness as a sensation which encapsulates what I know about cats. In approaching a new area, I spend of lot of time trying to get a feel for the shape of the topic and how the different aspects fit within the whole. Hence analogies. A good analogy allows one to think about a new concept through the pattern of an existing, usually well understood, thought process. It gives a basic shape to a concept which can then be adjusted as more details become available and higher resolution becomes possible. There will always be aspects in which the analogy becomes tenuous and one must always be aware that derived detail is suspect. But an initial outline, a shape for the concept, provides a basis for understanding.
The IT industry has a great many similarities to the construction industry and the analogies have been pushed for decades - deliberately so mostly, such as referring to Software development as “Engineering”. Unfortunately pushing the similarities tends to hide the differences and expectations are set which cannot be met. Multiple analogies are required to provide different insights on the area and the areas of connection need to be highlighted to indicate where each is valid.
A quite different analogy is making its way through IT at the moment. It associates the new concepts of SOA and SaaS [I won’t attempt to explain these at this time. There is lots of information out there if you are really interested] with the manufacturing industry. Mostly this analogy is implicit but several years ago I saw a presentation which made the connection explicit (Microsoft’s “Metropolis” analogy). I don’t know why this approach hasn’t been followed since because I have seen many poor attempts to explain SOA which would have benefited from making the link to something that business people can understand.
Another very good analogy specifically for management of software projects was a connection to pathfinding in uncharted territory (there is a sport in Australia called ‘rogaining’ which is essentially this but I don’t believe it has yet taken off elsewhere). I don’t remember where I saw this description but it clarified enormously the trade-off between project needs and support needs. Do you waste time making a map of the territory to make it easier next time, or do you just race to the finish line for yourself?
Analogies in other areas include the concept of technical debt – linking maintenance costs to mortgage repayments. I have written articles on the association between knowledge bases and memory systems, corporate processes and instinctive behaviour. In a previous life in the fitness industry I found it useful to describe an analogy between body fat and personal finance (stored calories are like money in the bank – it even generates interest). There are some extensions to all of these which may prove enlightening – and potentially misleading.
Which leads to the major problem with analogies: getting too attached to one can easily lead to unconscious expectations when you reach an area where the analogy breaks down, or is incorrectly extended. You must always be aware that the map is NOT the territory.
Friday, July 18, 2008
Office spaces
WE are moving offices next week. The new area is very nice – right on the waterfront. It is considerably closer to the central train station, which is good for me. The whole company will be in one location; something that I haven’t seen since I started with them over 9 years ago. And, of course, a change is always good to get people focussed again.
So what’s the catch? The new layout is ‘architect designed’ – which means, of course, that a lot of time and thought has been put into common areas such as the kitchens, meeting rooms, even offices for the senior management. You know, those places that you spend about 20% of your time in. The parts of the office where you spend 80% of your time has had very little thought at all, except to minimise the personal space as much as possible.
The architect has designed a fancy kitchen (which will be very dated in a few years time) and break-out chairs (which are in full view of the rest of the office – and away from the windows). The server room is significantly smaller than we currently have but we design and maintain software – why would we need many computers? There is no storage space apparently – so if you do a stint at a client site you had better take home anything that you might want to keep. You can’t guarantee that you desk will not be re-assigned and the contents thrown out before you get back.
DeMarco and Lister pointed all this out in “Peopleware” over 20 years ago and very many people have addressed the point since.
Every study ever made into office layouts has shown that productivity increases directly with the amount of privacy each person has. In fact, lower level workers do not interact as much as more senior people and therefore require MORE privacy. So we have a situation where the office is just a sea of desks – it’s a big open space and will be holding a lot of people. The outside desks, near the windows, have been allocated to the managerial types – the ones who need to talk to everybody. While the programmers and analysts, who need quiet and isolation, are clustered near the high traffic areas. Has anyone actually thought about this?
The broacher that our ‘move team’ have put out says that the space has been designed “to allow a connected and integrated working environment that encourages teamwork and community”. Connectivity and integration in an software company come from providing the right tools on the desktop – Web 2.0 and all that. Teamwork and community come from engaging people in the company and making them feel valued. Treating them as cattle or battery hens, as interchangeable (and not very important) parts in the grand machine, simply demotivates everyone and makes it harder to actually achieve anything.
We haven’t actually moved in yet, so I am getting ahead of myself somewhat. I am trying not to be cynical (at least not in public, this blog does not count) but, based on the amount of thought given to staff here, I am not confident. I do think that the idea of having everyone at least near each other is good. The argument for combining was the travel costs between offices (taxi and tram fares) but I suspect the increased communication will have at least as big an affect on work – if the office layout does not let us down.
So what’s the catch? The new layout is ‘architect designed’ – which means, of course, that a lot of time and thought has been put into common areas such as the kitchens, meeting rooms, even offices for the senior management. You know, those places that you spend about 20% of your time in. The parts of the office where you spend 80% of your time has had very little thought at all, except to minimise the personal space as much as possible.
The architect has designed a fancy kitchen (which will be very dated in a few years time) and break-out chairs (which are in full view of the rest of the office – and away from the windows). The server room is significantly smaller than we currently have but we design and maintain software – why would we need many computers? There is no storage space apparently – so if you do a stint at a client site you had better take home anything that you might want to keep. You can’t guarantee that you desk will not be re-assigned and the contents thrown out before you get back.
DeMarco and Lister pointed all this out in “Peopleware” over 20 years ago and very many people have addressed the point since.
Every study ever made into office layouts has shown that productivity increases directly with the amount of privacy each person has. In fact, lower level workers do not interact as much as more senior people and therefore require MORE privacy. So we have a situation where the office is just a sea of desks – it’s a big open space and will be holding a lot of people. The outside desks, near the windows, have been allocated to the managerial types – the ones who need to talk to everybody. While the programmers and analysts, who need quiet and isolation, are clustered near the high traffic areas. Has anyone actually thought about this?
The broacher that our ‘move team’ have put out says that the space has been designed “to allow a connected and integrated working environment that encourages teamwork and community”. Connectivity and integration in an software company come from providing the right tools on the desktop – Web 2.0 and all that. Teamwork and community come from engaging people in the company and making them feel valued. Treating them as cattle or battery hens, as interchangeable (and not very important) parts in the grand machine, simply demotivates everyone and makes it harder to actually achieve anything.
We haven’t actually moved in yet, so I am getting ahead of myself somewhat. I am trying not to be cynical (at least not in public, this blog does not count) but, based on the amount of thought given to staff here, I am not confident. I do think that the idea of having everyone at least near each other is good. The argument for combining was the travel costs between offices (taxi and tram fares) but I suspect the increased communication will have at least as big an affect on work – if the office layout does not let us down.
Tuesday, July 8, 2008
Frist
There is a song by Tripod which goes “I always get into things just as they finish being cool”. This is sort of how I feel starting this blog. Everyone is doing it and I am not sure what more I have to add. Blogging is really a fairly narcisstic pursuit. It assumes that there is someone out there who cares what you say.
Which is, of course, not the point at all.
In my case… there are some ideas which tend to run through my head until I finally trap them in words and lock them down on the page. Since I am writing these thoughts down anyway, why not put them into a blog – just on the off chance someone else cares.
I have been reading a number of blogs lately, mostly at work since there is not much else to do [note to self: I should explain this in more detail later – it might help work out what I should do about that]. And the conversations that I have been listening in on have helped crystallise my thinking on a number of points – often in areas unrelated to the topic being discussed, but just by presenting a point of view that I had not considered before.
Consider this payback – or pay forward, whatever.
This is not likely to be a single topic blog. There are a number of areas where my mind wanders and I’d like to range around a bit. I’m most likely to be writing on the train as I travel to and from work (a trip of about 45 min). This means that I don’t have internet access during the trip and linking is going to be a bit haphazard.
So be it.
As a bit of background; I work in the IT industry as a software architect. Don’t worry if you don’t know what that means. Neither does anyone else. If you do know what it means – you’re a wanker (of course, so am I). I live in a regional centre and travel to the capital city every day for work. I would work locally but they don’t pay nearly as well and I have got used to the trip; it gives me time to unwind (or wind up going the other way).
Anything else probably doesn’t matter that much. I may or may not include it in the blog if it appears relevant – depends on how I feel. I know that some readers like to know who is talking, but I am not sure that that should affect the argument being put forward. Did I mention that I have a science background? I recently discovered that one of my favorite bloggers was a woman. I had been assuming they were male for the last two years. It doesn’t change anything. The ideas are still valid whoever they come from.
I have a backlog of ideas that I have scribbled down in a Word doc over the last year or so. Most need work to even be coherent, but I am setting myself a goal of posting a couple of times a week – or once a week at least… maybe.
Which is, of course, not the point at all.
In my case… there are some ideas which tend to run through my head until I finally trap them in words and lock them down on the page. Since I am writing these thoughts down anyway, why not put them into a blog – just on the off chance someone else cares.
I have been reading a number of blogs lately, mostly at work since there is not much else to do [note to self: I should explain this in more detail later – it might help work out what I should do about that]. And the conversations that I have been listening in on have helped crystallise my thinking on a number of points – often in areas unrelated to the topic being discussed, but just by presenting a point of view that I had not considered before.
Consider this payback – or pay forward, whatever.
This is not likely to be a single topic blog. There are a number of areas where my mind wanders and I’d like to range around a bit. I’m most likely to be writing on the train as I travel to and from work (a trip of about 45 min). This means that I don’t have internet access during the trip and linking is going to be a bit haphazard.
So be it.
As a bit of background; I work in the IT industry as a software architect. Don’t worry if you don’t know what that means. Neither does anyone else. If you do know what it means – you’re a wanker (of course, so am I). I live in a regional centre and travel to the capital city every day for work. I would work locally but they don’t pay nearly as well and I have got used to the trip; it gives me time to unwind (or wind up going the other way).
Anything else probably doesn’t matter that much. I may or may not include it in the blog if it appears relevant – depends on how I feel. I know that some readers like to know who is talking, but I am not sure that that should affect the argument being put forward. Did I mention that I have a science background? I recently discovered that one of my favorite bloggers was a woman. I had been assuming they were male for the last two years. It doesn’t change anything. The ideas are still valid whoever they come from.
I have a backlog of ideas that I have scribbled down in a Word doc over the last year or so. Most need work to even be coherent, but I am setting myself a goal of posting a couple of times a week – or once a week at least… maybe.
Subscribe to:
Posts (Atom)