art-ikon - platform Archives

The long, flat base

2009-10-03T16:50:59Z

Notice how pyramids, as such, are functionally useless, and are not part of a modern construction repertoire, by which I do not mean pyramid shaped buildings, but actual pyramids. But emblematic they are and rightfully so. Engineering is more about bridges, road and rail lines of communication and various sorts of buildings, depending on function.
Pyramids, though, are emblematic of human structures, not without reason. The repetitious work is greatest at the base, hardest higher up. Slavery is equal at any point. How many are ground to dust to prevent the remains of one of two hidden in its midst from being ground to dust? Large companies are similar, unless they are very skilful in their people management.

]]> The broader the base the more pointless and tedious each component task, because each task at the base withstands a huge amount of pressure from above.
This is not intelligent design.
The pyramid, itself, is not an intelligent structure. But even if it were a bridge there are trade-offs between one massive bridge and several small ones. For instance one massive bridge would never have worked as a solution for bridging the Thames in London.
But this is what government does with IT, completely unnecessarily given IT's flexible and scalable nature.
These solutions have three disastrous consequences.
They cannot be efficient solutions.
They cannot be optimum solutions because they squeeze creativity out of those at the bottom who must implements them.
They cannot be economically competitive because they distort the market and deprive smaller companies of opportunity. What competition there is is at the expense of the first two points and this is ultimately disastrous for any policy that is meant to promote intellectual capital in this country.

From the top

2009-10-03T15:31:25Z

Image by art_ikon via Flickr

I realise that I am never going to fit in to my work environment.
I don't think that I can blog about this impartially. But, perhaps, usefully?
Before the work specific let's set the scene.
We have a government that wants to grow and promote the intellectual capital of this country.
How are we doing?
The answer is probably surprisingly well despite, not because of, the government.
This applies particularly to my field of IT.
Translating requirements into an application is one thing, but translating efficiently, creatively and offering true value for money is something entirely different.
It is quite clear that government has no criteria for the later, and therefore, no depth of understanding of subtle consequences of their decisions that ensue from contractual arrangements downwards.
Largely the government, in their many IT endeavours are ensnared by large IT companies who make it their business to justify the highest possible costs over the short and medium term.
Because they cannot show net profits above around 5% in the public sector they find other ways to make money, the most common pattern is that of over complicating requirements gathering and elongating the length of time it takes to fulfil and item of work. Attendant patterns are non-cooperation with IT partners and back loading costs to non IT ancillary services.
All of this comes about because the Civil Service is inattentive of contractual detail and under manned and skilled in their oversite roles. They also consistently chose large suppliers rather than a series of small suppliers.
Let's look at the consequences of this.
The government could be promoting exemplary projects, and it would be important if they did so.
Three truths
IT is a fluid field with much to learn, new ways of doing things on every level of the project. Experimentation coupled with uncertainty is the norm. This is so much the case that it cannot be said that further experimentation necessarily increases risk (within some parameters). Experimentation, trying things where results are uncertain, can reduce risk.
This truth is fundamental to understanding good IT governance.
The second truth is that top down governance is intrinsically flawed. The larger the pyramid the larger the mass of detail that is essentially unknown and, hence, contains hidden risk.
The third truth is that large pyramids are intrinsically unstable and dangerous when one needs to interact with another, at what ever level up or down the pyramid.

movabletpe, MTOS 4.3 or pro?

2009-08-31T16:03:16Z

...
Tangentially, the situation with MT is certainly confusing.
These are observations rather criticisms. I assume that the more thought and discussion I am involved with on this topic the better I will finally understand it.
Let me explain -
The project I work on professionally is a pretty large government funded web site and I have just been working on the 'software refresh' - I think that name reveals plenty about where this is all going. 'Software refresh' really wasn't in the sense that there is a large content driven web site that surface many nodules of discrete functionality through bespoke code. Each nodule is still part of the whole, and the normal way would be to see them as packages that have a set of dependencies that vary according to version.
I think you know where I'm going.
If you substitute perl for the server scripts in ant and shell the situation conceptually may be similar to that of the movabletype codebase?
Perl has CPAN and associated tools, Java also has some tools. But it is very difficult to apply these tools retrospectively.
For instance Byrne keeps old versions of Photo Gallery linked - and this is a different type of decision as to whether the link should be removed, than publishing version and version dependencies for Photo Gallery. It is a different (logical) order of decisi

Image by art_ikon via Flickr

on.
An equivalent example from my professional life would be broken links to public content - how should they be mended? This is in control, and of a refresh remit. But, in terms of different order of decision, another example is where the whole code base of a particular project might be better worked in a different directory structure.
Since we are talking about dozens of discrete projects, you may imagine this is an intimidating proposition. And I have come to the conclusion that no-one quite knows their way around these issues.
It is not quite knowing how to deal with this sort of thing that I am assuming applies to the MT codebase, OS and commercial, as well.
So when I complain that the situation around MT is confusing I, at the same time, imagine that the reason is because the situation is complex.
Now I do have something to add to this though. This is that there is a similarity in approach to creating a large web site where many intrinsic bits of code exist in various scripts and have been placed there over the years in, what is described as, an organic way, to what must happen in a community such as MT, both OS and commercial, over the years.
It seems that the only way out is to either ensure that each atom of change works with every other part of the system or enforce categories of code within which change may take place. At the moment most, Java, Perl or other, do a bit of both. Further, by insisting to the extreme either alternative I don't think there is anyone who would be able to say this would evaporate all the problems I have outlined. However, it maybe that there is such a way. What do you think?