Bloglines - Everything Is Relative

Bloglines user adam.saltiel has sent this item to you.


Everything Is Relative

By Rat Outzipadd

I have thought long and hard about this. I realise that I do, in fact, have to mention my employer and many of the details of what I have found wrong with the approach to IT being taken in the specific.
I shall explain why this is, starting first with my motivation.
As I point out in the title, everything is relative, but I think that people who are prepared to voice their opinions can, sometimes, make a slight difference to the way things are done.
The broad aim is to improve the way things are approached in this country so that -
1. things are done more efficiently in IT result:- increase in sense of purpose
2. consequent on 1. - money is saved. result:- more money for other things, allowing prioritisation of spending flexibility.
3. Systemic and structural changes are facilitated such that IT in this country has a chance of expanding creatively and unfettered by the growth of dark practices. result:- growth of intellectual capital in this area that can, as in a multiplier effect, be made use of in a flexible way across many different technological domains.

Reasons for mentioning my particular experience.
1. With concrete examples I can illustrate a few general points with some measure of conviction for the reader.
2. Mentioning one company name is far more likely to draw attention since there is an actual contract involved, parties to which having legitimate concerns.
3. My own words would soon melt into nothing and my ideas be forgotten by me before being expressed without the aid memoir of actual events to draw upon.
I consider this to be the missing link.
These arguments are well rehearsed and really devolve around the ideas of top down against bottom up.
The issue really is how is flexibility enshrined in legal arrangements. This is the area in which it seems to me government has shown the least understanding and total ineptness. Government repeatedly shows itself most happy when dealing in aggregate, as if commissioning large works such as battleships, hospital buildings with all ancillary services and so on.
It is clear that government in this country has not understood the significance of open source.
However, I cannot make that my plank here, it is a detailed argument for elsewhere.
What comes before a consideration of open source is the nature of software itself, and how best to reflect that nature in contract.
Here are some principals.

  • Software is never complete - so do not think of it as a product that is ever fully delivered.
  • Maintenance need not be end of cycle - an inflexible demarcation at this point means assessments have to be made about fitness for purpose, reassessed requirements and re-builds all focussed around a narrow point.
    Rather maintenance should meld into development phases which in turn should entail constant requirements reassessment.

So how can an activity that has, by definition, incomplete requirements and an ill defined end be held in a contract?

  • Key word - flexibility.

The contract will hold measures of flexibility. This means that requirements changes can be seen to have limited financial impact as against no requirements change in the same broad domain over the same period of time.

  • Key word - quality.

Quality has to be thought of differently. It is no longer just a case of testing against requirements and performance criteria. Quality is also a term applied to continual maintenance, that is readiness and ability to upgrade, as well as ability to substantially refactor (at every level from architecture through design to implementation), that is take out or substitute identifiable components.

  • key word - interchangeability.

This is another aspect of refactoring. A component may be taken out and replaced with another internal component or it may be replaced with an external component where a communication channel exists between the internal and external services.

All of these issues are well thought out and worked through, including the benefits of open source as well as service oriented solutions. There is no question that the approach needed to best capture the benefits could be applied to most, if not all, IT projects.
It therefore, becomes crucial to see the extent to which this is not the case and to understand why a suitable structure for IT is not being applied.

I have said everything is relative - the waist of money that I have seen in the context of my work is small compared to the the overall spend on IT. The waist of money that I have direct experience of is tiny compared to that, and it is that very small base I am extrapolating from.
If I were making a claim of malfeasance I would be restricted to a small set of hopefully supported facts. This isn't my point.
My point is that bad practice is systemic and it really is in the hands of the customer, government, to do something about this which would ultimately be to the benefit of us all.