Summary Points – The itemised summary of Section 1 given in the course material. What I will do is list the summary points here and give a brief analysis, interpretation and example of same. I plan to do this for each section in the course, so a reasonable overview of the material will be produced.
1. Software may not have brought about the economic benefits nationally that we could have anticipated
One of the understatements of the century, no matter what perspective you look at it from. Software is generally touted as the all-singing all-dancing answer to all of life’s prayers, but frequently falls short of user/stakeholder expectations. Coming from a developer’s point of view I can easily understand this. I know how my software works, the limitations and capabilities, technical caveats and so on, but a non technical person could have real trouble. “Why doesn’t it do this?”. “Because of XXXXXX”. “… Thats a bit rubbish isn’t it..?”.
An example given is of productivity vs investment in IT over time. Studies by Landauer and others show that there was a marked drop in productivity as more and more investment in IT rolled out, but doesn’t really give much more on it than that. One thing we can infer here is that if we can make the graph go the other way, i.e. productivity rising, then we can safely assume that correct methods of software design, production, and equally as importantly use, have set in.
2. Software can fail in service often with disastrous results
Also very true. In service here meaning any production environment. If software is not correctly designed, requirements not properly and systematically elicited, if production is sloppy, testing non-existant, and without input from all relevant stakeholders, then failure is assured.This is a no-brainer. It will happen, no ifs buts or maybes.
The example given is of the Therac Radiation machines, but I prefer this one: The great Zune fiasco of 2008. Whereby someone in Microsoft had coded a specialised calendar check into the Zune software, and basically forgot about the existence of such things as leap years. In this case I’m not (solely) blaming the coder, that snippet should have been reviewed ten ways form Sunday, especially considering there’s already a trolley load of date and time functions out there.
3. Software is important in the automation of clerical functions, justified by the saving of labour costs and the increased accuracy and reliability of results
No, really? Software is not important, its critical. Not just for the automation of tasks, but for the error checking that comes with this. One tired and bored clerical officer can do the same process for the same set of files 4/5 times and come out with different answers each time. Machines don’t have this problem. If the software is told how to do it right the first time, then it will do it right the first time, and the second, and the third…
Its not so much that the cost of is justified, more that is essential..
4. Software offers new opportunities for enterprises to deliver their services and products more effectively and more efficiently, and even create new products and services
This is true – in the modern world the average business or even home cottage industry type person can get themselves online and trading away with world wide exposure for about €100. And that includes the costs of the web hosting. Without the services built on software, they wouldn’t be of particular use, but them they are invaluable.
5. Stability cannot be relied upon – change is always with us, but has become more intense the advance of technology and the globalisation that accompanies it
This is a good thing rather than anything else – the more the market/industry/scene/whatever changes, the more we will see new and innovative ways of creating and using software, often in ways never dreamed of before. Software, automation, call it what you will, it has busted its way on to the scene and has now taken complete control. It is at the core of every business (or should be), and the world economy would collapse without it.
6. Rational and scientific approaches to developing software have their limits, limits that are matched in other areas of human activity and marked as postmodern
I consider this a bit of a contentious one – there is always a lot to be said for the human approach, etc, but at the end of the day it should still all boild down to a rational approach to your process. If your methods or results can’t be analysed in some way (and I’m including as yet uncovered methods of analysis here..) then I would think that it probably isn’t all that effective. I’m not a big believer in the “limited” idea.
