TWiki> DICE Web>TechStrategy2009 (revision 3)EditAttach

Our strengths

We have a willing workforce which work effectively as a team. There is a good community spirit (supported by the chat-room).

We have a skills set which is broad and deep (though possibly more by chance than design) and we are good at problem solving and producing ad-hoc solutions.

We enjoy a flexible working environment.

We have responsibility for the complete life-cycle of a service (from requirements capture, through design and implementation, to service delivery).

We have an effective frontline support team which allows COs to concentrate on development.

Our technical infrastructure is considered to be solid :-

  • authentication/directory services
  • the managed linux platform
  • network
  • monitoring

Our weaknesses and where we could improve

Self Promotion

We have produced many innovative solutions and services over the years, but have often been rather weak in promoting these to our "users", to the rest of the University and out-with the University.

One possibility is to open up our technical talks to other Informatics members and perhaps even to ITPF members. It was felt that introducing short 10-15 minute one-slide "I found this cool way of doing something/piece of software/etc" would encourage more people to give more talks - the google tech talks and Alan Bundy's research group talk series were cited as good practice..

We should promote more of our locally written software to the open- source community. One perceived barrier to this is a lack of confidence in the quality of our code; code review (see later) could help here.

Another route is to give presentations at ITPF and conferences such as UKUUG and LISA.

Automation

There is general acceptance that we waste a considerable amount of skilled effort on repeatedly performing relatively manual tasks which could be automated. Perhaps we should adopt a culture where everything is automated unless there are good reasons (too difficult to implement, task is infrequent, etc) for not so doing? Of course, there is the downside that this produces more code to be maintained.

Related to this is system monitoring. We have a good system monitoring infrastructure, but have yet to take full advantage of it. As a result, we end up reacting to problems which is generally more expensive, and disruptive, than being able to act more proactively as a result of warnings issued by system monitoring.

Knowledge transfer

Generally, our current practice is that a development project will be carried out by just one individual. This has a number of issues :-

  • that individual can feel isolated and exposed
  • although design issues may be discussed with others, implementation rarely is.

These can be a barrier for knowledge and skill transfer amongst COs and can also lead to poor design and implementation decisions being taken.

One option is to have more than one individual working on any development project, even adopting pair programming. At the very least we should be considering performing code review. MPU have recently started doing this and it is proving to be a boon for improving code quality and skills transfer.

We would like to see more collaboration with other schools on development projects - this has worked well in the past (eg LCFG SL5 port). However, there is no obvious forum (other than CCPAG) for discussing what projects schools are working on. It was suggested that we need a grass-roots equivalent of CCPAG - what happened to SciCOs ?

Effort and priority

There is a general impression that we have insufficient effort for our operational and development commitments. It is unlikely that we will gain any additional staff in the short term. The only realistic way we can drop commitment is to make more use of central services. We also need to make more space for new developments (see later).

People feel like they are trying to do too much simultaneously - this can be stressful and we can lose effort through context switching. Personal time management can help here - eg setting aside certain days of a week to work purely on development work.

Perhaps the management (unit managers and CEG) is not giving sufficient direction with respect to priorities? There was a suggestion that it is maybe "too soft" on enforcing priorities where they have been given.

We currently attempt to ring-fence project and personal development time - one suggestion was that we try to ring-fence time spent on operational work to limit time spent on it.

Innovation

It was felt that, although we have produced innovative solutions in the past, we have not been so productive recently.

We all agreed that we need to be much more innovative in the future. We should have an aim of being proactive in predicting what our researchers (and teachers) will need in the future, rather than being reactive to their needs. Being more aware of what other similar organisations offer could help with this. This would lead to more "not-a-service" prototypes to test the usefulness of particular ideas; we must be prepared to develop stuff that we might have to discard.

We should be particularly wary of central services discouraging us from developing services because they claim to be developing an equivalent central service. We have suffered from this in the past - eg Euclid, Web, eDiary.

Completion

It was commonly felt that we are not good at completing projects. We have, rather too often, pushed a prototype system into service before it is fully serviceable (LCFG managed, user documentation written, procedures documented etc). Some felt that there was a culture that considered documentation etc to be a luxury.

It was suggested that management was not sufficiently rigorous in ensuring that projects are completed properly.

It was suggested that :-

  • projects should not be signed off until the deployed system has been in service for an appropriate period of time (current practice is that a project is signed off pre deployment).
  • where appropriate, project sign off should include promotion of the new service to users and support staff.
  • a project template for required documentation is produced.
  • we perform more pre-deployment testing.

There have been a number of projects that have run on and on for a number of years without much evidence of progress. We should either resource them properly or kill them off. The biannual project prioritisation review by CEG should ensure that this happens.

It was observed that we do not perform continuous improvement, in any systematic manner, of deployed systems.

Accommodation

There was unanimous agreement that there had been no improvement in working conditions in the Forum since occupation.

Alastair will arrange a meeting of COs with Dave to argue for a rationalisation of accommodation.

Miscellaneous

There is concern that we do not always have the right skills for research support - eg Java. We probably need to think more strategically about what skills we need to acquire.

We are perhaps too tied to the one platform (Redhat based Linux).

We would like to improve interaction with researchers, but have no good ideas on how to achieve this.

It was suggested that the unit structure is a potential barrier to knowledge-transfer and that it is inflexible to changing resources and effort requirements.

-- AlastairScobie - 16 Jun 2009

Flip-charts from 090527 meeting

Flip-charts from 090625 meeting

-- GeorgeRoss - 26 Jun 2009

Edit | Attach | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 26 Jun 2009 - 10:19:23 - GrahamDutton
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies