|
![]() |
Homepage / Publications & Opinion / Archive / Daily Telegraph: Harddrive![]() No handbooks - learn For as long as I can remember I have also refused to read books on software programming or attend courses on the subject. So far I have become reasonably proficient with desktop applications, and have attained some skill with the common languages by unpicking the constructs of others. My other routes to success include watching and talking to experienced practitioners, and, I must confess, the occasional sneaky look in the book when really desperate. Software manuals are not good bedtime reading, and always seem to be as perverse as the products they describe. On most occasions I fail to find what I am searching for and resort to consulting an expert. Another useful mechanism is the serendipitous flash of realisation. Recently these seem to have been arriving thick and fast, in sympathy with a spate of application upgrades by everyone around me. When I first started writing this column, each 600-word item required a reasonably standard 16K of hard disk space. After about three months I received a software upgrade and suddenly the storage demand for my 600 words increased to 24K or more. With the latest upgrade I have seen an increased demand to at least 46K, and the article that prompted me to unpick the software had grown to 150 kilobytes. Now 150K for 600 words is 250 bits per word. Assuming that my words are, on average, five characters plus a space, at eight bits a character, I should need only 48 bits a word. Punctuation and formatting information might increase the total by 10 per cent or so, but that hardly dents the unaccounted waste. This prompted me to start playing, and I soon discovered that every modification is recorded but hidden from view. So, a virgin draft document will accumulate all the modifications of later editing. Looking over my texts, I discovered that the easy documents to produce were compact, while anything with multiple contributors and edits could be four or five times bigger than logic would predict. A simple solution came to mind. I saved the 150K monster as an earlier version of my package and it reverted to only 8K. What a saving. Incidentally, 8K is the smallest file size on my machine and dictated by the memory allocation structure. Another interesting feature of this investigation was the existence of a class of virus that embeds itself in the macros of the package. This can be overcome by disabling the macros if not required. Alternatively, saving down a couple of application versions does a good job. Further investigation showed similar problems in my spreadsheet and presentation pack. But nowhere in the documentation could I find adequate explanations or warnings. The final score: engineering instinct 1, handbooks 0. Peter Cochrane holds the Collier Chair for the Public Understanding of Science & Technology at the University of Bristol. His home page is: |
![]() |
||
![]() |
|