The irony cup runneth over.
Posted by sleek
| 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 |
|
October 17, 2006 10:35PM |
Hello all
I suspect that this is my first post to this
particular forum, but perhaps some of you know
me from cos311, cos321 and cos340 in 2005.
I've read all the posts in this thread, and I
waited until my temper quietened down a little
before putting thoughts into words. Speaking when
one is still emotionally charged leads to arguments
of more vitriol than value.
The difficulty, in my (humble?) opinion, was
not the actual question paper. The night before
the paper I was calm and cool and collected and
told my wife that I expected to fail.
I'm not stupid (not by any stretch of the
imagination) and I rather doubt that the
lecturers are lacking in intelligence as well,
but I knew I was not able to memorise seemingly
arbitrary information from a textbook written
in such an incoherent manner.
I feared an exam much worse than I actually got,
and it was because of these reasons:
(Forgive me if I get a few details wrong, I've
not looked back on my notes since the exam).
1. Arbitrariness.
The study material is arbitrary - there is no
rhyme or reason which the material follows. In many
other modules, one can use logic to at least infer
a moderately accurate guess:
<example>list the 7 layers of the OSI stack ...
logic says that there is at least a physical layer
at the bottom and an application layer at the top.
Of the remaining 5 layers, at least one has to be
data link, and it can only perform it's function if
next to the physical layer. Then there has to be
a session of some sort ... etc.
</example>
We had no such questions were logic may have
helped us out. We had no chance in hell of remembering
arbitrary facts with a seemingly disconnect from reality.
2. Error-filled textbook.
Following the authors meanderings was a nightmare
in and off itself. Every single chapter from
3 to 12 had errors of contradiction or logical
disconnects in it.
The requirements engineering, for example, specified
a certain number of steps (in the beginning of the chapter)
such as inception, elicitation, etc ... which I dutifully
noted and left space for detail. Reading further
one finds that the author *forgets* to discuss one of
the steps.
Chapter 7 has a state diagram for an alarm system which,
if implemented, would result in a "crash" as seen from the
user (believe me, as an embedded developer with close
on to 9 years of experience designing and implementing
state machines in TheRealWorld, that diagram was broken,
and can be proved as such ... <sidenote>This year alone
I've designed *and* implemented in firmware around 5 state
machines. In firmware, it has to be correct the first time
because you will go bankrupt if an error makes it into the
field - no software patches like personal computers, see?).
All the chapters had errors of one kind or another.
3. Buzzword Bingo.
Most of the material in the textbook was filled with
meaningless jargon that added nothing except to the
authors feelings of worthiness.
The author has succeeded in the greatest attempt of
literary masturbation that I have ever had the misfortune
of being required to read. Everything he wrote was to
massage his own ego.
4. Redundancy
A lot of the material was presented more than once,
with subtle differences.
In chapter 5 I counted over 60 items (in various
lists) that had to be memorised. After cutting out
what seemed like obvious redundancies I was left with
45+. After removing the less obvious redundancies
(by rewriting the chapter into a more recognisable form)
I was left with around 30 items, all unrelated.
Of course that is going to be hard to remember for an
exam ... only 3 of the lists had KIS, and putting it
in any of the other lists would be marked wrong!
On a related note, I'd like the author to explain
what the difference is between "meaningful context" and
"context", as he uses them as two very different terms
with different meanings. My understanding of english
is that "context" makes "meaningful" redundant. That
is the entire /meaning/ of "context" -> to give meaning
to by means of placement. What the hell is "meaningful
context"? It's like saying "I went to the ATM machine,
and used my PIN number."
(expand the acronyms above to see what I mean - this
message brought to you by the department of
redundancies department!).
5. The lack of catering to a non-univ. audience.
IME, a good book is one that is begging to be
written. This book seems geared exclusively to the
univ. audience. How can I tell?
Well, it makes it easy to pick out questions from.
Just turn to a page and come up with a "write down the
7 items of ..." type of question, so these are popular
with the more unmentionable type of university; less
work for the lecturer.
Also, there is no actual way to use this book to
stage an open-book exam. The quality of a textbook
can be revealed if one does an open-book exam with it.
If the only questions that you are able to ask based on
the content of the book are memorisable-answer type
questions, then it is certainly a bad book.
The good books encourage an open book exam because
their authors know that the exam should be on how to
*apply* what you have learned, and therefore the answers
won't really be in the book anyway.
This book fails on both the above criteria.
6. The authors obvious lack of experience.
I find it surprising that someone with that
many credentials could be so staggeringly dense
in systems development. It is obvious to anyone
who has practised s/ware dev for a few years that
trying to maintain 5 lists of between 4 and 14
elements *each* is a recipe for disaster.
In summary, I could not pass because (1) the
material has no logic to follow or deduce, (2) the
number of errors assured me that the lecturers may not
be able to tell right answers from wrong, (3) the
unnecessary jargon would sooner or later trip me up,
(4) the repeats with subtle differences made it hard
to remember anything at all, (5) the book was aimed
to the lazy lecturer so that valid questions could be
lifted out of literally any page making one need a
photographic memory (this is only compounded by
the redundancies, not eliminated!) and finally (6)
lead me to believe that the quality of the answer
will not be evaluated, only the daft adherence to the
authors stupidity.
I can only hope that they change the textbook for
next year; even though this means I won't be able
to flog my existing one it will at least give the
new students (I may be one) a fighting chance at
gaining some systems development insight.
I recommend choosing a book for an open-book exam;
Microsoft press has released a few gems in their
time (rapid development, code complete, etc). Frederick
Brookes "The Mythical Man-Month" is a legend in
s/ware dev (odd that Pressman quotes from that book
so often but gets so much of it wrong).
Hell, if you give me a syllabus and a promise that my
book would be used I'd happily write a proper development
book[1]. The advantage is that it will be free to UNISA
students
.
In addition, I will be focused not on selling copies,
but on seeking to share insight and enlightenment, so
already my theoretical to-be-written book fixes much
of the faults of the current one, simply by me *seeing*
and being able to articulate the faults in the current
textbook.
NOTES:
[1]Sadly, I cannot actually do this right now, as I'm
working on a more pragmatic development book, not one
with higher levels in it, but more low-level idioms).
Later all, still have 4 more to write this year.
--
Learn something new - updated weekly
I suspect that this is my first post to this
particular forum, but perhaps some of you know
me from cos311, cos321 and cos340 in 2005.
I've read all the posts in this thread, and I
waited until my temper quietened down a little
before putting thoughts into words. Speaking when
one is still emotionally charged leads to arguments
of more vitriol than value.
The difficulty, in my (humble?) opinion, was
not the actual question paper. The night before
the paper I was calm and cool and collected and
told my wife that I expected to fail.
I'm not stupid (not by any stretch of the
imagination) and I rather doubt that the
lecturers are lacking in intelligence as well,
but I knew I was not able to memorise seemingly
arbitrary information from a textbook written
in such an incoherent manner.
I feared an exam much worse than I actually got,
and it was because of these reasons:
(Forgive me if I get a few details wrong, I've
not looked back on my notes since the exam).
1. Arbitrariness.
The study material is arbitrary - there is no
rhyme or reason which the material follows. In many
other modules, one can use logic to at least infer
a moderately accurate guess:
<example>list the 7 layers of the OSI stack ...
logic says that there is at least a physical layer
at the bottom and an application layer at the top.
Of the remaining 5 layers, at least one has to be
data link, and it can only perform it's function if
next to the physical layer. Then there has to be
a session of some sort ... etc.
</example>
We had no such questions were logic may have
helped us out. We had no chance in hell of remembering
arbitrary facts with a seemingly disconnect from reality.
2. Error-filled textbook.
Following the authors meanderings was a nightmare
in and off itself. Every single chapter from
3 to 12 had errors of contradiction or logical
disconnects in it.
The requirements engineering, for example, specified
a certain number of steps (in the beginning of the chapter)
such as inception, elicitation, etc ... which I dutifully
noted and left space for detail. Reading further
one finds that the author *forgets* to discuss one of
the steps.
Chapter 7 has a state diagram for an alarm system which,
if implemented, would result in a "crash" as seen from the
user (believe me, as an embedded developer with close
on to 9 years of experience designing and implementing
state machines in TheRealWorld, that diagram was broken,
and can be proved as such ... <sidenote>This year alone
I've designed *and* implemented in firmware around 5 state
machines. In firmware, it has to be correct the first time
because you will go bankrupt if an error makes it into the
field - no software patches like personal computers, see?).
All the chapters had errors of one kind or another.
3. Buzzword Bingo.
Most of the material in the textbook was filled with
meaningless jargon that added nothing except to the
authors feelings of worthiness.
The author has succeeded in the greatest attempt of
literary masturbation that I have ever had the misfortune
of being required to read. Everything he wrote was to
massage his own ego.
4. Redundancy
A lot of the material was presented more than once,
with subtle differences.
In chapter 5 I counted over 60 items (in various
lists) that had to be memorised. After cutting out
what seemed like obvious redundancies I was left with
45+. After removing the less obvious redundancies
(by rewriting the chapter into a more recognisable form)
I was left with around 30 items, all unrelated.
Of course that is going to be hard to remember for an
exam ... only 3 of the lists had KIS, and putting it
in any of the other lists would be marked wrong!
On a related note, I'd like the author to explain
what the difference is between "meaningful context" and
"context", as he uses them as two very different terms
with different meanings. My understanding of english
is that "context" makes "meaningful" redundant. That
is the entire /meaning/ of "context" -> to give meaning
to by means of placement. What the hell is "meaningful
context"? It's like saying "I went to the ATM machine,
and used my PIN number."
(expand the acronyms above to see what I mean - this
message brought to you by the department of
redundancies department!).
5. The lack of catering to a non-univ. audience.
IME, a good book is one that is begging to be
written. This book seems geared exclusively to the
univ. audience. How can I tell?
Well, it makes it easy to pick out questions from.
Just turn to a page and come up with a "write down the
7 items of ..." type of question, so these are popular
with the more unmentionable type of university; less
work for the lecturer.
Also, there is no actual way to use this book to
stage an open-book exam. The quality of a textbook
can be revealed if one does an open-book exam with it.
If the only questions that you are able to ask based on
the content of the book are memorisable-answer type
questions, then it is certainly a bad book.
The good books encourage an open book exam because
their authors know that the exam should be on how to
*apply* what you have learned, and therefore the answers
won't really be in the book anyway.
This book fails on both the above criteria.
6. The authors obvious lack of experience.
I find it surprising that someone with that
many credentials could be so staggeringly dense
in systems development. It is obvious to anyone
who has practised s/ware dev for a few years that
trying to maintain 5 lists of between 4 and 14
elements *each* is a recipe for disaster.
In summary, I could not pass because (1) the
material has no logic to follow or deduce, (2) the
number of errors assured me that the lecturers may not
be able to tell right answers from wrong, (3) the
unnecessary jargon would sooner or later trip me up,
(4) the repeats with subtle differences made it hard
to remember anything at all, (5) the book was aimed
to the lazy lecturer so that valid questions could be
lifted out of literally any page making one need a
photographic memory (this is only compounded by
the redundancies, not eliminated!) and finally (6)
lead me to believe that the quality of the answer
will not be evaluated, only the daft adherence to the
authors stupidity.
I can only hope that they change the textbook for
next year; even though this means I won't be able
to flog my existing one it will at least give the
new students (I may be one) a fighting chance at
gaining some systems development insight.
I recommend choosing a book for an open-book exam;
Microsoft press has released a few gems in their
time (rapid development, code complete, etc). Frederick
Brookes "The Mythical Man-Month" is a legend in
s/ware dev (odd that Pressman quotes from that book
so often but gets so much of it wrong).
Hell, if you give me a syllabus and a promise that my
book would be used I'd happily write a proper development
book[1]. The advantage is that it will be free to UNISA
students
.
In addition, I will be focused not on selling copies,
but on seeking to share insight and enlightenment, so
already my theoretical to-be-written book fixes much
of the faults of the current one, simply by me *seeing*
and being able to articulate the faults in the current
textbook.
NOTES:
[1]Sadly, I cannot actually do this right now, as I'm
working on a more pragmatic development book, not one
with higher levels in it, but more low-level idioms).
Later all, still have 4 more to write this year.
--
Learn something new - updated weekly
Sorry, only registered users may post in this forum.