tut letter 301/4/2006
Posted by goose
| Announcements | Last Post | |
|---|---|---|
 |
SoC Curricula | 09/30/2017 01:08PM |
|
Demarcation or scoping of examinations and assessment | 02/13/2017 07:59AM |
|
School of Computing Short Learning Programmes | 11/24/2014 08:37AM |
|
Unisa contact information | 07/28/2011 01:28PM |
|
November 02, 2006 09:41PM |
|
November 03, 2006 07:36AM |
yip, I also received it. Have no idea what its all about...
|
November 03, 2006 10:57PM |
34435360 wrote:
> Likewise, the letter's so vague..
If it were any more vague than it is now, one could
specify anything from a uranium-235 bomb to christmas
tree lights and *still* be within the scope of the
letter .....
Forgive me, all ... I've written my last paper today
and have imbibed all the alcohol in the house.
The wife is sure in for a shock when she wakes up on
the 'morrow
good luck to each and every student unlucky enough
to have encountered UNISAs drain-bamaged examinations.
<OT>
Oh ... sometimes when I've had one too many (like now)
I long to be able to *lead* a module ... I *want* to be
able to contribute to the pool of knowledge gained by
mankind and I see so many oppurtunities to right so many
wrongs.
For example, lets take "software engineering" (the quotes
are meant to indicate sarcasm, for the slow of thought) ...
After many years in this business (formally 8 to 9, informally
I've been writing software since age 10 (yes, at age 10 I've
written 6502/6582 machine code), I have to denounce
all "software engineering' as snake-oil ....
Developing software is not an exact science. If it were,
the exams would be a lot easier. It is a mixture of
exact science (like pert/CPM/etc) and a "feel" for it that
only comes with experience (ask anyone with more than 20
years in development - they might be able to explain better).
Because it is a mixture of science and intuition, I can only
consider software development a "craft". There are no hard rules
that one can adhere to. The "organic/semi/embedded" categories
from inf308 are optimistic at best. The "prescriptive/agile"
methodologies from inf305 were all developed by people who
sold books on their favourite crap way of doing things
(Kent, I'm looking at you man ... your last update of XP
was purely to sell your book).
The various chapters of inf303 are mostly unworkable
(why the hell did we get taught about OO? OO as a database
serialisation method and OO as a data storage method sucks,
which is why the only companies using OO to access databases
in a native way are the ones who use almost *4 times* as
many resources as purely relational algebraic methods do, as
well as an army of consultants) but we learnt all their
"advantages" anyway.
The textbook for inf308 and inf305 both point out that
software must be "managed" to ensure we don't repeat the
failures of the past but they both neglect to point out that
*even by utilising what they teach* we end up with more
software failures per attempted project than ever before.
It is obvious then that the modern methods espoused by these
textbooks (and by extension, these modules) cause even more
mayhem than ever before.
Even worse, it is clear that these authors have never
ventured into the real world, where people maliciously
try to crack your system; why else would the 2nd level
inf modules specify "biometrics" as an authorisation
system? Think about it ... you cannot use fingerprints
for authorisations ... after all you leave copies of your
fingerprints everywhere and with +-$25 worth of equipment
one can copy and recreate *your* fingerprints (which
you leave on everything you touch).
Lets say your ATM card needed no PIN but used a thumbprint
as these dolts have suggested. All a thief has to do is
go to your car in the parking lot while you are at work and
lift your prints from your car door. They then make new prints
and etch them onto latex and withdraw all your money. What do
you do now?
You cannot change your thumbprint, but you can change your PIN
if the card gets nicked ... obviously the better solution
is to use PIN and *not* thumbprints/fingerprints for
indentification.
Or how about the 2nd level inf module which implied that
one of the advantages of the GUI is to be able to vaidate
the input ... as in a drop-down box, a spin-box, checkbox, etc.
As a user of the internet from 1992, I can attest that we had
all of those things (input validation) from pure text-based
systems. I know. I was there; obviously the lecturers and/or
the textbook authors were not aware of the internet until
post 1996. Try typing "lynx www.google.co.za" at the command
prompt in any present day linux distro to see what I mean.
The errors accumlate and accumulate. And then they accumulate
some more. The only reason that they self-perpetuate is because
software developers want to be taken seriously as "engineers".
Sorry; you can call yourselves engineers all you want
but *software* is not an engineering feat; rather it is
a mixture of engineering, hard sciences, math and good 'ol
common sense. This is what is commonly known as a "craft".
Therefore one should "craft" software, not attempt to engineer
it. Engineering works because of universal constants
(Pi, avogadros constant, boyles law, etc). Software works
only when the developers plan for maintenance.
Maybe I've had a *leetle* too much to drink ... maybe
I'm just bitter because even unsuccessful projects get
the limelight if the marketing is right .... Maybe I
actually care how software is developed, and want it
done the best way possible each time it is done.
Nevermind which of the above reasons are true, I intend to
change all of this. Look for my study-guide for cos340
in 2007, and by 2009 I should have completed my book
"Practical Magic" which tries to teach by example the
best way of writing a program.
I suppose I'm a little drunk (the dogs are giving me funny
looks when I weave my way to the bathroom but I also
think that I am not *totally* off-base.
Good luck for the others who stil have papers to write; I've
completed all for this year (still 2 more for next year though).
May you all remember all of the arcane and obscure pieces of
thorougly useless information that you will come across during
je course of our studies.
later
goose,
--
Learn something new - updated weekly
> Likewise, the letter's so vague..
If it were any more vague than it is now, one could
specify anything from a uranium-235 bomb to christmas
tree lights and *still* be within the scope of the
letter .....
Forgive me, all ... I've written my last paper today
and have imbibed all the alcohol in the house.
The wife is sure in for a shock when she wakes up on
the 'morrow
good luck to each and every student unlucky enough
to have encountered UNISAs drain-bamaged examinations.
<OT>
Oh ... sometimes when I've had one too many (like now)
I long to be able to *lead* a module ... I *want* to be
able to contribute to the pool of knowledge gained by
mankind and I see so many oppurtunities to right so many
wrongs.
For example, lets take "software engineering" (the quotes
are meant to indicate sarcasm, for the slow of thought) ...
After many years in this business (formally 8 to 9, informally
I've been writing software since age 10 (yes, at age 10 I've
written 6502/6582 machine code), I have to denounce
all "software engineering' as snake-oil ....
Developing software is not an exact science. If it were,
the exams would be a lot easier
. It is a mixture of
exact science (like pert/CPM/etc) and a "feel" for it that
only comes with experience (ask anyone with more than 20
years in development - they might be able to explain better).
Because it is a mixture of science and intuition, I can only
consider software development a "craft". There are no hard rules
that one can adhere to. The "organic/semi/embedded" categories
from inf308 are optimistic at best. The "prescriptive/agile"
methodologies from inf305 were all developed by people who
sold books on their favourite crap way of doing things
(Kent, I'm looking at you man ... your last update of XP
was purely to sell your book).
The various chapters of inf303 are mostly unworkable
(why the hell did we get taught about OO? OO as a database
serialisation method and OO as a data storage method sucks,
which is why the only companies using OO to access databases
in a native way are the ones who use almost *4 times* as
many resources as purely relational algebraic methods do, as
well as an army of consultants) but we learnt all their
"advantages" anyway.
The textbook for inf308 and inf305 both point out that
software must be "managed" to ensure we don't repeat the
failures of the past but they both neglect to point out that
*even by utilising what they teach* we end up with more
software failures per attempted project than ever before.
It is obvious then that the modern methods espoused by these
textbooks (and by extension, these modules) cause even more
mayhem than ever before.
Even worse, it is clear that these authors have never
ventured into the real world, where people maliciously
try to crack your system; why else would the 2nd level
inf modules specify "biometrics" as an authorisation
system? Think about it ... you cannot use fingerprints
for authorisations ... after all you leave copies of your
fingerprints everywhere and with +-$25 worth of equipment
one can copy and recreate *your* fingerprints (which
you leave on everything you touch).
Lets say your ATM card needed no PIN but used a thumbprint
as these dolts have suggested. All a thief has to do is
go to your car in the parking lot while you are at work and
lift your prints from your car door. They then make new prints
and etch them onto latex and withdraw all your money. What do
you do now?
You cannot change your thumbprint, but you can change your PIN
if the card gets nicked ... obviously the better solution
is to use PIN and *not* thumbprints/fingerprints for
indentification.
Or how about the 2nd level inf module which implied that
one of the advantages of the GUI is to be able to vaidate
the input ... as in a drop-down box, a spin-box, checkbox, etc.
As a user of the internet from 1992, I can attest that we had
all of those things (input validation) from pure text-based
systems. I know. I was there; obviously the lecturers and/or
the textbook authors were not aware of the internet until
post 1996. Try typing "lynx www.google.co.za" at the command
prompt in any present day linux distro to see what I mean.
The errors accumlate and accumulate. And then they accumulate
some more. The only reason that they self-perpetuate is because
software developers want to be taken seriously as "engineers".
Sorry; you can call yourselves engineers all you want
but *software* is not an engineering feat; rather it is
a mixture of engineering, hard sciences, math and good 'ol
common sense. This is what is commonly known as a "craft".
Therefore one should "craft" software, not attempt to engineer
it. Engineering works because of universal constants
(Pi, avogadros constant, boyles law, etc). Software works
only when the developers plan for maintenance.
Maybe I've had a *leetle* too much to drink ... maybe
I'm just bitter because even unsuccessful projects get
the limelight if the marketing is right .... Maybe I
actually care how software is developed, and want it
done the best way possible each time it is done.
Nevermind which of the above reasons are true, I intend to
change all of this. Look for my study-guide for cos340
in 2007, and by 2009 I should have completed my book
"Practical Magic" which tries to teach by example the
best way of writing a program.
I suppose I'm a little drunk (the dogs are giving me funny
looks when I weave my way to the bathroom
but I also
think that I am not *totally* off-base.
Good luck for the others who stil have papers to write; I've
completed all for this year (still 2 more for next year though).
May you all remember all of the arcane and obscure pieces of
thorougly useless information that you will come across during
je course of our studies.
later
goose,
--
Learn something new - updated weekly
|
Re: tut letter 301/4/2006 November 04, 2006 06:14AM |
I'm rather surprised at finding your post, had this exact discussion last night (also over a cold one ) but my biggest beef is with the entire software development process. It seems that between the translation of business requirement into IT requirement into development requirement and testing requirement we're doomed to failure, it's like playing telephone and expecting your system to fill its intended purpose. The high rate of software projects failing internationally is a clear indication of a boat being missed far and wide.
Oh and not to mention the fact that so many businesses think that you can take a monkey, give it a keyboard and they can whip up a software solution. Wizard based software development has allowed far too many people to fake their way as developers.
K that's my ranting for today
) but my biggest beef is with the entire software development process. It seems that between the translation of business requirement into IT requirement into development requirement and testing requirement we're doomed to failure, it's like playing telephone and expecting your system to fill its intended purpose. The high rate of software projects failing internationally is a clear indication of a boat being missed far and wide.
Oh and not to mention the fact that so many businesses think that you can take a monkey, give it a keyboard and they can whip up a software solution. Wizard based software development has allowed far too many people to fake their way as developers.
K that's my ranting for today
Sorry, only registered users may post in this forum.