KEY ISSUES IN ISD
ASPECTS OF PROGRAMMING
Here I have written some passages and present them as I would
expect in the assignment.
*** WARNING - All the passages below are ficitious and purely
made up for this assignment. Also, all the references are fictitious.
Do NOT copy them. If you copy any of these you will get no marks
for them. You should treat them only as examples of the kinds of
thing I expect, and examples of aspectual analysis of programming.
***
(Though fictitious, the passages are in fact based on good practice.)
In determining the aspect under which to categorise the passage, you
will often find several aspects. You must try to work out the main
thing the passage as a whole is saying, and treat the others as
secondary, serving the main one. But you can then mention them.
Tip: Try to get a feel for what it is the passage says is good or bad,
and then determine in which aspect it is good or bad.
Notice the structure of each entry:
"The passage in double quotation marks".
The reference (author, date, title of article, source, with page
number)
Explanation of why you have placed it under this aspect, and
mention of secondary aspects and why they are not the main
ones.
ISD = Content of IS, Anticipating Use, Creating IS, Whole Project -
which multi-aspectual human ISD activity this is.
1 The quantitative aspect concerns discrete amount.
"Number ranges have ends. It is at the ends that errors often occur.
For example, if time of day is a number, then errors often occur at
11:59:59 or 0:00:00."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 56
Quantitative aspect because it is to do with numbers. But there is
also a bit of formative aspect in the mention of errors.
ISD = creating IS.
2 The spatial aspect concerns continuous extension.
3 The kinematic aspect concerns flowing movement.
4 The physical aspect concerns energy and mass.
5 The biotic aspect concerns life functions and the integrity
of organisms.
6 The sensitive or psychic aspect concerns sensing, feeling
and emotion.
7 The analytical aspect concerns distinction, abstraction,
logic, analysis and clarity.
"Separate the code you are working on from its surroundings,
especially in a large application."
Basden, A (1999) 'How to program well'.
http://www.basden.salford.ac.uk/programming/clearcoding.html
accessed 9 March 2009.
Analytic because of making distinction between the current
problem area and its surrounding code.
ISD = creating IS.
"Keep code clean and out in the open. Clean code means not messy.
Out in the open means be very clear in what variables you use."
Banks V., Goggings T. (2012) The way to program well. Publishing
House, Surrey. p. 12
Analytic because 'out in the open' and 'clean' refers to clarity
and keeps different things in your program distinct.
ISD = creating IS
"Do not trust anyone who says that a piece of code is too hard for
anyone else to understand. It will be too hard even for the original
author to maintain. All such code must be simplified."
Greystone, B. (2007) Programmer as Apprentice. Blackill
publishing. p.54.
Analytic because simplification.
ISD = creating IS
"Keep asking Why. Keep questioning until you understand the root
of the issue. Asking why can help you separate out what's
important."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 74
Analytic because it is questioning, i.s. making distinction
between what is said and what is really meant.
ISD = content of IS.
"When asking users about what the software must do, allow them to
say 'I don't know'. They may not have thought that far ahead yet
and might need to see it in action before they can say. Advise them
as well as possible, and prepare code for what you think is best, but
expect it to change."
Klein, V.R. (2008) Systems Analysis Methods. Practical Books,
New York. p. 112.
Analytic because it's to do with analysis of future IS use. But
there is also an element of ethical generosity here, in being
prepared to do work that might have to be changed later.
ISD = anticipating use.
8 The formative aspect concerns deliberate shaping and
achieving; history, culture, technology, expertise.
"Develop bit by bit. Release the software with small, yet usable,
pieces of functionality. When developing each increment, use an
iterative cycle of a couple of weeks."
Fox, C.R. (1997) Agile Programming Explained. Southampton
University Press, UK. p. 33.
ISD = Whole Project.
"It's been a long time since the last code review, so we're going to
review everything all this week. Also, it's time we made a release of
the software, so get it ready for three weeks from Tuesday."
Klein, V.R. (2008) Systems Analysis Methods. Practical Books,
New York. p. 75.
Formative because it's about planning. NOTE: This is what
NOT to do. Arbitrary plans like this are bad. Things like
releases and reviews should be tied to substance of the project not
arbitrarily chosen times.
ISD = whole project
"Bug fixes create more bugs, which create more bug fixes, and the
whole program comes crashing down. What we need is a constant
feedback to make sure the code hasn't deteriorated and continues to
work well."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 84
Formative because it is to do with 'working well', and trying to
achieve this.
ISD = creating IS
"To keep up with changing technology, you don't have to become an
expert at everything. Stay aware of the direction the industry is
taking, and plan so your system will still work for the users when
things change."
Ahmad M,H. (2004) The Technological Environemnt of
Programming. http://www.london.ac.uk/albright/papers/ecis06.pdf
accessed 9 March 2009
Formative because it's about technology, and also about
planning, and also about becoming expert.
ISD = anticipating use.
"Even with a well-planned design, some surprises will occur.
Remember that the design you come up with is based only on your
current understanding of the requirements. Once you start coding
things might change. Expect designs, and the code that implements
them, to be always evolving."
Banks V., Goggings T. (2012) The way to program well. Publishing
House, Surrey. p. 77
Formative because of design and changes.
ISD = anticipating use and/or creating IS
"Determine their needs first, and then evaluate the technologies suited
to those specific problems. Don't just fix on a technology because
you or the client likes it. Critically question the use of any
technology, and be honest in answering them. Does it really solve
the problem? Does the technology actually solve the particular
problem you're facing? Or are you relying on what marketing claims
about the technology, or on secondhand opinions about it? Make sure
it does what you want without any bad side effects."
Bellweather J.F. (2001) Good Practice in ISD. Floggle Inc, Los
Angeles. p.12
ISD = anticipating use
Formative because of technology.
"Always use the latest copy of the source code and compile and test
against that. Very often, someone else has made a change that's
incompatible with the one you are making, and problems occur."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 102
Formative because it is to do with changes that someone made,
and your change. But it could be aesthetic aspect of harmony. It
involves lingual aspect of coding.
ISD = creating IS.
9 The lingual aspect concerns symbolic signification.
"Testing of each unit provides instant feedback. Unit tests generate
good documentation."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 132
Lingual because to do with information: feedback and
documentation.
ISD = creating IS
"Your code must clearly communicate your intent and must be
expressive. If you do this, your code will be readable and
understandable. If your code is not confusing, some potential errors
can be avoided."
Banks V., Goggings T. (2012) The way to program well. Publishing
House, Surrey. p.44
Lingual because it is to do with being understandable.
ISD = creating IS
"Comment to communicate. Using well-chosen, meaningful variable
names. Use comments to describe their purpose and what constrains
them."
Fox, C.R. (1997) Agile Programming Explained. Southampton
University Press, UK. p. 112.
Lingual because to do with telling us about the program.
ISD = creating IS.
10 The social aspect concerns social interaction,
relationships, roles and institutions.
"If you discover a problem in someone else's code, don't keep it to
yourself. Be sensitive about hurting their feelings in how you
mention it, but do mention it. If that someone else happens to be
your boss, be respectful, but don't hesitate to point out the error."
Basden, A (1999) 'How to program well'.
http://www.basden.salford.ac.uk/programming/clearcoding.html
accessed 9 March 2009.
Social because it concerns relationships and role and status
(boss), and respect.
ISD = creating IS, but partly whole project
11 The economic aspect concerns frugality, skilled use of
limited resources.
"Unit tests take too much time and effort, and will just delay the
project. You're a wizard programmer and you always get your code
right first time, so tests are just a waste of time. Anyway, we're
already late."
Economic because it's to do with time limits. But it's also pistic
(negative: arrogance). NOTE: This is *NOT* the attitude we
should take!
Fowler, J.S. (2010) Programming for Poopers. Salford University
Press, UK. p.23
ISD = creating IS
"I was writing a program to send different types of files to another
process and had to write code for another type of tile. That shouldn't
be hard. But when I looked at the code, I found that the code to
handle each type of tile was duplicated. So I took the easy route and
just copied and pasted a hundred lines of code, changed two lines in
it, and got it working in minutes. But I felt bad. It was not good
working practice to do that. It would have been better to rewrite all
the file-handling routines to combine the common code. We did that.
Within a week, we saw the benefit of that effort when we had to
make some changes to how files were handled - only now, the change
was easy to make because the code to be changed was not spread all
over the system but in one place."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 59
Economic aspect because it is to do with avoiding superfluity -
waste of code. But it's partly also aesthetic, to do with elegance.
ISD = creating IS
"Always be aware of how much work is left. Don't measure
irrelevant stuff. Measure the backlog of work you still have to do."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 87
Economic aspect because it is to do with limited time left.
ISD = whole project.
"Many project failures occur because of feature bloat - the accretion
of extra features one by one as the user says 'It would be nice to have
xxx'. ... It's easy to get sucked into the 'just one more feature'
mentality. Tracking requirements can give a clearer picture that 'just
one more feature' is really the 77th new feature added this month."
Bellweather J.F. (2001) Good Practice in ISD. Floggle Inc, Los
Angeles. p. 47
Economic aspect because the main problem is limited resource of
time, and the tendency to waste time. But there are other aspects
here, such as ethical aspect of being generous to users (beware
this!), lingual aspect of tracking requirements, and analytic aspect
of clearer picture. But the main aspect is the economic.
ISD = anticipating use and content of IS
12 The aesthetic aspect concerns harmony, beauty, surprise,
fun.
"Bring all your modules together early and often. Code integration is
a major risk, but this can be mitigated if you begin integration early
and do it regularly throughout."
Wallace D. (2005) Best Programming. Practical Books. p. 34.
Aesthetic because it's to do with harmony of all the modules
working together like instruments of an orchestra.
ISD = creating IS
"Projects cannot be successful unless the people on the team work
effectively together. How they interact, and how they manage their
activities together is vitally important."
Ahmad M,H. (2004) The Technological Environemnt of
Programming. http://www.london.ac.uk/albright/papers/ecis06.pdf
accessed 9 March 2009
Aesthetic, because to do with working together.
ISD = whole project
"Try to delight the users. Not scare them, but delight
them. Give them that little bit more than they were expecting. The
extra effort it takes for you to add some extra feature to the system
will generate goodwill."
Fowler, J.S. (2010) Programming for Poopers. Salford University
Press, UK. p.59.
Aesthetic because of delight. But also ethical generosity in
service of this delight. But beware of feature bloat (an economic
issue) above.
ISD = creating IS
"Build documentation in, don't bolt it on"
Fox, C.R. (1997) Agile Programming Explained. Southampton
University Press, UK. p. 83
Aesthetic because it is to do with harmony of documentation,
even though documentation itself is lingual.
ISD = creating IS.
13 The juridical aspect concerns 'to each, their due': rights,
responsibilities, restitution.
"Fixed-price contracts are bad when you are doing agile
development. Agile ISD is a continuous, iterative and incremental
activity. When someone comes along and wants to know ahead of
time how long it will take and now much it will cost, and keep you to
that, then this is a real problem, because at the same time they
probably do not really know what they want. A fixed price
guarantees a broken promise."
Fox, C.R. (1997) Agile Programming Explained. Southampton
University Press, UK. p. 9.
Juridical because it is speaking about contracts. But also because
it is speaking about something inappropriate. Promise is also a
juridical thing.
ISD = Whole project
"What everyone does must be relevant to the whole project. But
also, each individual action affects the project context."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 22
Juridical because to do with appropriateness.
ISD = whole project
14 The ethical aspect concerns self-giving love, generosity.
"Let the client actually work on the current project, to get realisitic
estimates. Give the client control over both features and budget."
Wallace D. (2005) Best Programming. Practical Books. p. 123.
Ethical aspect because we are giving away control to client.
Estimation itself is quantitative, and 'realistic' is juridical, but
main message is ethical.
ISD = whole project
"Suppose you've been working on a piece of code for a while.
Suddenly you realise that you've been doing it all wrong. You really
should begin again and redo the work. Worried about confessing the
problem to your team and telling them it'll take more time or asking
for help? Don't try to cover up the issue. Do what's right and say,
'I now realise what I've done so far is not the right approach. Here
are some ways to fix it - if you have more ideas, I'd like to hear
about them - but it's going to take more time.' By doing this, you
have clearly indicated that you're interested in finding a solution, and
have asked people to work with you on it. The others will be
motivated to work with you in solving the problem. They may help
and give you a hand. In this, you've shown your honesty and
courage - you've earned their respect."
Carly J. (2004) Real life programming. McGraw-Hall Publishing
Co, Glasgow, Scotland. p. 230
There are lots of aspects here. e.g. trust is faith aspect, 'more
time' is economic aspect, 'cover up' is juridical aspect, 'ways to
fix it' is formative. But the whole thing is about no protecting
yourself, letting yourself be vulnerable, and in turn it is likely
that people will be generous.
"Users are always complaining. Don't worry: it's not your fault;
users are just too stupid to read the manual. It's not an error; they
just don't understand. Users should know better."
Fowler, J.S. (2010) Programming for Poopers. Salford University
Press, UK. p.83.
Ethical because a selfish attitude. Note: this is NOT the attitude
to take!
"Give them that little bit more than they were expecting. The extra
effort it takes for you to add some extra feature to the system will
generate goodwill."
Fowler, J.S. (2010) Programming for Poopers. Salford University
Press, UK. p.59.
Ethical generosity pays off!
ISD = creating IS
15 The faith/pistic aspect concerns faith, commitment and
vision of who we are.
"Sometimes even the best plans fail, because of lack of courage.
Despite the dangers - the possibly pitfalls and problems that you fear -
you need to forge ahead and do what's right."
Wallace D. (2005) Best Programming. Practical Books. p. 63.
Faith because it's to do with courage, and with doing what we
firmly believe deep down.
ISD = creating IS
"Get the team excited about the techniques and methods that will
benefit your project."
Bellweather J.F. (2001) Good Practice in ISD. Floggle Inc, Los
Angeles. p. 39.
Faith because it's to do with belief in these technologies and
techniques.
ISD = whole project.
"Users usually come with some vision of what they want. Not just of
a problem to solve, but with some solution they favour. Their vision
might be incomplete, inconsistent, or even impossible, but it is
theirs. Like the child on their birthday, uses have some
emotion invested in it. You cannot just ignore it. You must give it
respect."
Banks V., Goggings T. (2012) The way to program well. Publishing
House, Surrey. p.105.
Faith aspect because it's to do with vision, and what people are
committed to. The mention of 'emotion', which seems to be
psychic aspect, is not so; it is metaphorical use of 'emotion'.
ISD = anticipating use.
*** WARNING - These are just examples. They are fictitious. Do
NOT copy them. ***
Copyright (c) 2009 Andrew Basden.