Work - 23rd March

This was my last day in the office on the work experience programme. I was extremely complimented to be told that I was obliged to come back in the summer term to arrange a farewell event. My colleagues have consistently made me feel welcome, useful and praised my abilities – this reflects my work and their good nature. My work this week was finishing the spread sheet I started the week before. This became the now fairly familiar task of tidying up the edges, writing the last few formulae and proofing it to check that everything works. Error identification is always tricky in a large project and I was glad that it was being worked on by several other people – if I missed any mistakes they will be likely to catch them before the project goes ‘live’.

I used my notes from last week to make a list of all the elements of the spread sheet and based my first round of error checking on this. It is always important to have a systematic process to ensure that nothing is missed; randomly looking will not do the job. I caught a few minor errors and corrected these. Having checked everything in the order that I created them I went through the spread sheet as if I was a user. I checked that entering data into the sheet worked, and that it behaved as I expected. This revealed a slight flaw with the maths, which I also corrected.

My final error checking method was to ‘try’ to break the sheet. I deliberately entered incorrect values in all the boxes and made sure that the programming could cope with this. At this stage I also realised that I had not put in any data validation. Data validation checks the data being entered by a user and makes sure that it is within a defined range, or form. For example ‘In a spread sheet detailing personal information and qualifications data validation would be used to prevent users from entering a date of qualification earlier than their date of birth. Alternatively it could be used to prevent letters being entered into a numerical field.’ In addition it is possible to ‘protect’ some cells so that you cannot edit them without a password.

To me it was essential that all the fields had data validation and protection where it was necessary – without it users can modify the spreadsheet. If the sheet is complex this can often cause it to stop working, causing more work for the person who wrote it originally – they are normally the ones asked to fix it. I asked K if she wanted me to add these protections, and she was confused about the reasons they were important. It illustrated a divide between people who create complicated spreadsheets, databases and other digital projects and the people who use them. Creators – programmers, data analysts and similar people – often don’t trust the end user. They assume that the user will be likely to break the spreadsheet and then not be able to use it properly. This motivates them to make it very hard for anyone to change their project without authorisation. They then find themselves at odds with skilled users who want to be able to customise the project but can’t because it is locked. I have found myself on both sides of this debate; when I create something I want to protect it and when I use something I want it to be unprotected.

In the case of this sheet I persuaded K to allow me to add the protection. I felt that since it was to be used by the sustainability team to assess the performance of other departments that the whole university must work from the same spread sheet. Allowing multiple versions to be created would only make using the data after it had been collected much harder. Producing a sheet in this way is the equivalent of a form in Adobe PDF. It is important that everyone gets the same version and that the owners can be sure no one has edited the wording.

In the general case – I feel that I would trust myself with my own project. I would also trust some other people. However, when I don’t know the audience that I am distributing a product to I feel it should always be protected and locked. There are also people I would always lock my work before allowing them to use it – it all boils down to trust.