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.