Saturday, February 26, 2005

Creating space for evolutionary design

Fowler seems to be observing what many have been using as an objection to the "let's use evolutionary design for everything". Good technical leadership (as opposed to dictatorship - do not confuse the two) is required for successful software projects, particularly those above a certain size. In one of his examples, a problem where a project had multiple solutions to the same problem was fixed by adding an 'architecture team that forged a base approach to these problems'. He then goes on to say that in fact he thinks it is "Continuous attention to technical excellence and good design enhances agility." that is needed. Well yes, and that requires the team need to be able to spot better solutions or identify unwanted divergence[1] in the existing solution. That's hard across a code base where your team can't keep it all in their heads or where the collective understanding is spread across too many teams to make a query efficient.

In larger projects that often means you need a team that addresses the macro structure. They are needed to ensure that the project establishes and looks after the load bearing walls. After all, on larger projects it is these load bearing walls that end up delineating the space within which evolutionary design can occur.

[1] sometimes you want divergence, because the original solution has reached its limits.

Thursday, February 24, 2005

Turning a plan inside out

Big plan, no idea whether it delivers what is needed, no mappings back to original stuff that needed to be done.

The (successful) approach we've taken is to turn the plan inside out thus:

Pass 1:
  • Each team to list every deliverable from the 'plan backwards' activity as a 0 day milestone.
  • Each team to connect each milestone back to the tasks which deliver it.
  • Each team to create tasks for the milestones that have no dependencies.
Pass 2:
  • Each team to disconnect dependencies on other teams tasks and reconnect them to the other teams deliverable milestones.
  • Each team to list deliverables they expected and didn't appear.
  • Each team to weave new set of deliverables, and therefore tasks, back into plan.

Pass 3:

  • Each team to remove its teams tasks from the plan, leaving only milestones and create their own workplan from the tasks.

Result

  • Management can manage by milestone.
  • Each team can manage by input/output milestone and change their plan as they see fit (modulo not moving agreed milestones)

Transparency

ss is a proponent of transparent projects, those where the management can see exactly what is going on. it has a number of advantages:


  • less management intervention as they can see what is going on without having to poke it.

  • it builds trust.

  • it encourages openness.


however, it has at least one drawback. imagine an outsource type situation. if the outsourcing (sponsor) organisation has a large and complex set of processes and metrics, and the outsource organisation does not, then the sponsor is likely to consider its own processes and metrics to be crucial elements in establishing transparency. the sponsor will wish to drive these elements and other forms of governance into the outsource organisation.

if the outsource organisation is lightweight and agile then the transparency can have a negative effect. in the agile organisation all the joints are a little loose, there is room for manouvre, a little chaos.

as the sponsor organisation drives its capital M methods and metrics into the outsource organisation it slowly removes the degrees of freedom in the outsource organisations joints. as the joints stop moving smoothly in many directions the outsource organisation starts to lose its adaptability and ability to innovate. The result will be an outsource organisation that will likely move as slowly or slower than the sponsoring organisation.

to avoid this the sponsoring organisation needs to accept that the outsource organisation is different, and is efficient because it is different. the sponsor needs to turn a blind eye[1] to the micro-level chaos and slack in the joints. it needs to allow the outsource organisation to operate in an effective, adaptable mode, recognising there will be some chaos and flex. to do this it has to ensure that measures and methods it puts in place are macro level indicators, guidance and governance.

this balance is key to successfully outsourcing to significantly smaller and adaptable organisations.

[1] or maybe observe and learn.

Thursday, February 17, 2005

Heretics and orthodoxy

http://www.ccel.org/ccel/chesterton/heretics.pdf


http://www.svots.edu/Faculty/Thomas-Hopko/Articles/postmodern.html

Orthodoxy, unexamined dogma, maybe a secular pastime in the West now. IT is particularly bad for orthodoxy and codification of guidelines into rules.

http://www.bbc.co.uk/radio4/religion/somethingunderstood.shtml sparked this off.

Extreme Pragmatism

Some people have an outlook that is focused entirely on pragmatic action, Extreme Pragmatism. Like everything, pragmatism is good in moderation. Sometimes however it can become too dominant. Often a highly dominant Extreme Pragmatic approach means that deep thinking around approach, drivers and foundations is lacking. This can lead to decisions that do not balance the tactical and strategic views correctly. The highly tactical approach can get quick results, but often at the cost of later regret work. G. K . Chesterton seems to have articulated this issue nicely, though somewhat rhetorically.

Suppose that a great commotion arises in the street about something, let us say a lamp-post, which many influential persons desire to pull down. A grey-clad monk, who is the spirit of the Middle Ages, is approached upon the matter, and begins to say, in the arid manner of the Schoolmen, “Let us first of all consider, my brethren, the value of Light. If Light be in itself good—”. At this point he is somewhat excusably knocked down. All the people make a rush for the lamp-post, the lamp-post is down in ten minutes, and they go about congratulating each other on their unmediaeval practicality. But, as things go on they do not work out so easily. Some people have pulled the lamp-post down because they wanted the electric light; some because they wanted old iron; some because they wanted darkness, because their deeds were evil. Some thought it not enough of a lamp-post, some too much; some acted because they wanted to smash municipal machinery; some because they wanted to smash something. And there is war in the night, no man knowing whom he strikes. So, gradually and inevitably, to-day, to-morrow, or the next day, there comes back the conviction that the monk was right after all, and that all depends on what is the philosophy of Light. Only what we might have discussed under the gas-lamp, we now must discuss in the dark.

I have been working on some XML stuff recently and has spent a bunch of time considering precise definitions of things, an experience I've enjoyed but found hard work. It's a shame there isn't always the luxury of time to do it more often. I believe this groundwork will at least ensure that everyone is on the same page when using their shiny ontological lego bricks. A shared understanding of the foundations behing these bricks must (surely?) contribute to more effective modelling. It could have just defined some basic rules, but it doesn't think that would have worked as well.

GK Chesterton on requirements

What is the point of begetting a man until we have settled what is the good of being a man

Sunday, February 06, 2005

Russian pavements

I went to the photo gallery on Gt Newport Street[1]. By far the best piece was Stories from Russia where the photographer had got the general public to take part in the photo shoots. She has them standing, in front of famous buildings, facing the camera. It's weird, all the people (in the main) are staring at the camera, looking almost like mannequins, and yet real. It's disconcerting. Since she sampled the general public there's a huge mix of different people, defiant trendies, tired old people, the works. Worth a look.
In the back room was a video installation. There is one person on each screen and, individually, they tell their version of the story behind the Hotel Moscow's two designs. First it is told round robin style and a central screen has the translation on it, then it merges and they all speak together and the translations are all merged together, leaving you struggling to pick any words out from the translation, in the same way that you struggle to pick out a single voice in the cacophony of them all talking at once.
Never photographing downwards, I spent some time today photographing downwards on my way into london. I've now got a collection of bits of pavement, tree trunks growing from gravel, railings, barriers and peoples feet in the crowds. I guess I#ve got to figure out what to do with it now but I suspect I'll build it into a sequence, in order of my descent into london.



[1] another weekend of lobbying failed to J of the merits of the V&A.

Friday, February 04, 2005

Initial thoughts on Project Rescue

I thinks there is a good parallel between ICU and fixing broken software projects. It's not been thought through very well but here are the, admittedly sparse, notes so far.


Tuesday, February 01, 2005

Architecture and beauty at the V&A

I discovered rather late that V&A have opened an architecture gallery.
Along with the beauty stuff V&A seems to be delivering the goods.