Last week I realised how little things have changed in the engineering world in the last 10 years. There was a time when the desktop computer was a specialist item. People had to share them, and only used them for special activities. The opposite is true now, an engineer not using a computer is a rarity and even the most mundane activities are now carried out the computer.
This was a massive leap forward, and we are surely still dipping our toe in the water. But what has changed since the desktop computer arrived on my desk? The software is essentially the same. Productivity software has hardly changed over the years. My design spreadsheets have hardly changed over the years, they are essentially the same tools as when I first developed them. The analysis tools that I use are still the same with very few changes having taken place. Even the CAD programmes used by draftsmen appear to have changed little in terms of their fundamental functionality. Changes have been made to these pieces of software, but few of the changes are to the fundamental functionality.
This lack of changes might not be a bad thing: 'if it ain't broke, don't fix it'. And yet I see the same mistakes being made now, as were being made 10 years ago. Errors in the transfer of data between packages, mistakes in the input parameters, incorrect assumptions about the way packages are used and errors in the post-processing of the data are all common. Yet nothing seems to have been done by the software manufacturers to prevent this. Simple tools could have been added with relative ease to reduce the number of these errors.
So why have things not changed? Probably because we don't realise that they do need changing. I suspect that the most contact a software manufacturer has with their clients is when the client is trying to solve a particular problem. If the software can't solve the problem, a quick and dirty solution would be developed in the short term and modifications might be made to a future release so that the software would ultimately be able to solve the problem. This means that each release of software will focus on these specific problems few users actually have, whilst ignoring some of the more fundamental issues that have to be addressed.
We need a paradigm shift in the way our technical and productivity software is produced. Manufacturers need reach out to their users and try and understand how their software is actually used. Equally, the users must start to realise the problems that they actually have. We need to critically assess how we do things and how things can change to make our experience better.
As a last note I thought I'd mention 'Numbers', the new spreadsheet application by Apple (part of iWork 08). This could potentially be a major paradigm shift in the way that spreadsheets are developed. By having multiple tables on one sheet it becomes a much more intuitive interface. It could even lead to modular spreadsheets with a library of tables that can be joined together like a computer programme, each table having already been verified. There would then be no need to check every cell on the spreadsheet, just to check that the tables have been put together correctly. I have yet to try out this application, but I do plan to do so in the near future. I am hopeful that this might be the biggest shift in the way that we use spreadsheets in many years.
1 comment:
Thanks for leaving a comment on my blog, UrbanWorkbench.
Great post, your points about data transfer and mistakes not growing up are valid, and scary, when we are busier today than ever before, and put more trust in the software.
Keep in touch,
Mike
Post a Comment