Opinions on this thought of mine

Question

I am actually very nervous posting this question in here as, what i think is a sensible thought may turn out to get ripped to shreds by you guys, so please be kind!
I?ve been deep in thought after a lecture we received at university a couple of months back now and wanted to pose this to you experts;
We were told that software engineering was one of the worst engineering practises around today. Basically, the lecturer said that it?s the only industry an end user can expect not to be disappointed if the goods they purchase don?t work to the correct needs, thus why we are always needing patches/ updates and so on. The problem with this he continued to say was that, after a while all this updating and patching of the software leaves it in an un-extendable state and this new software is needed to be released.
So, my query was this, if we are all driving our cars, and we all drove to the ?book? (Highway code) the chances of accident are so slim that realistically the only chance of crashing is mechanical fault, or health problems whilst driving, because every other factor would have been taken in to consideration. Can the same be said for programming? If we all programmed to the ?book? then would all of these issues be completely avoided and thus the industry as a whole would be far better at doing what it?s supposed to?
On the flip side however you could say that there is no definite book for creating software? (this is where my lack of programming experience comes in) and as such you/we are as developers and future developers still deciding what should be in the book for programmers to follow. Then that would raise the question, how are any of the programming/computing courses such as computer science actually science, if, what we are really being taught is only trial and error until a definitive approach is found?
I shall be posting this is another forum i use, not a programming one as such, one for computing students to get their reaction as well. Sorry if my question was utter **** it just seemed interesting to me
cSUG
Edited by: compSciUndergrad on Jan 14, 2009 1:42 AM

Answer 1

Your lecturer was both right and wrong.
He was right about the fact that most software out there is flawed and needs fixing after delivery, he's wrong when he states that that's the case with all software for all users.
In my experience in the industry (over a decade as a professional, nearly a decade before that as a student and consumer of products) most products work to specs for the majority of users.
But the massive diversity of environments that software needs to operate in makes testing it for all those environments impracticle if not impossible.
And that's IF it is known during construction of the software what the actual operators are going to do with it, what the requirements are.
In this field more than any the product is going to be used in situations it was never intended to be used in by people who don't have proper training in how to use it for purposes never anticipated when it was designed.
And the creators will be blamed for the problems that arise as a result. In any other industry the creator would kick back the blame by telling the customer he'd used the product without the proper training and for purposes it wasn't intended for, and the customer would both accept that and almost certainly know it in advance.
Only here do customers not accept responsibility for their own failings to do something simple like read requirements sheets and documentation.
If I have a car and have to stop at that toll booth in front of that bridge, I don't blame the manufacturer of either the car or the bridge if I lack the training to properly handle my vehicle and crash into that tollbooth because I didn't know how to apply the brakes.
If someone did the equivalent with software he'd blame the company that released the software.
For example I've seen many rants from people who bought some piece of software for platform X and failed to get it running on platform Y, or people who bought a product that is marketed as simulating something that lacks functionality A and blame the company creating that simulation for not implementing functionality A (the target audience of that specific product is supposedly well versed enough in what it simulates to know it shouldn't have that functionality, it's a highend product aimed squarely at very advanced users).
That same product on its support group gets constant complaints about people who clearly haven't read their manuals, as the complaints all have to do with a basic lack of understanding of core functionality of the product which is clearly explained in the manual (as well as the supplied tutorials).
Would you blame the manufacturer of your car if you can't find the radio on/off button (the location of which is clearly marked in the manual)?
But yes, there is room for improvement in core quality output by software development teams.
In part that's due to sloppy work by the programmers.
But also it's due in no small part due to sloppy work by those designing the system specifications, and those testing the product at its various stages.
All of those are in part (again) due to management pressure to work faster and cut corners, something that always leads to problems later on.
Back to that bridge. If the project managers there had decided to use a cheaper type of concrete and less rebar than precified in the design their bridge may also fail.
Had the designers miscalculated (or being provided with incorrect data about) planned traffic density, the bridge might not be strong enough or lack the capacity needed.
It's essentially the same thing, yet for some reason in software development it's become the standard practice to cut corners on quality in order to speed up delivery and lower cost, when in other industries it (generally) hasn't.
One factor may be the mistaken idea among many managers that software development is a manufacturing line process rather than a creative batch process, leading to the idea that output volume of programmers (and entire teams) will get higher if you just push them to work faster and/or put more people on the job (neither of which works for a reasonably well experienced team).
Another factor is that there's a huge wall between groups in this profession.
As a result the people actually implementing the system often don't know what they're implementing, and as a result can't know if what they're doing makes sense.
Say I'm implementing a financial package but I don't have the faintest idea about bookkeeping, how can I ever be expected to verify that the data my code produces from a given input is correct?
And as testers (if they exist at all, in most companies there as no dedicated testers) don't know much more, they won't catch it either.