![Theory transcends documentation
in at least 3 essential ways
• How are affairs of the world mapped into the
program text? For any aspect of the world the
programmer can state its manner of mapping into
the program text. [AOSD]
• Can support the program text with some
justification.
• Is able to respond constructively to any demand
for a modification. Similarity of new demand to
similarities already in the system.](https://image.slidesharecdn.com/agilesoftwaredevelopment-221008121008-2e8a9e56/85/Agile-Software-Development-ppt-40-320.jpg)
Agile Software Development.ppt
- 1. Agile Software Development Alistair Cockburn Addison Wesley
- 2. Three Levels of Learning • Learning new skills – Following: “one procedure that works”, “at least this thing works” – Detaching:”when does it break down?” “learn limits of procedure”, “adapt it”, “when is it appropriate?” Survey paper. – Fluent:”irrelevant whether following a particular technique”, ”knowledge has become integrated”.
- 3. The Three Levels and Methodology • Methodology: a series of related methods and techniques (Miriam-Webster) • Level 1: processes, techniques and standards in detail. Detailed templates in RUP servel level 1 audience. Big methodologies of Accenture (anderson Consulting).
- 4. Three Levels of Methodology • Level 2/3: The Pragmatic Programmer: identifies techniques that a practitioner uses. A useful library of ideas but the beginner finds it lacking specific rules. • Avoid level mixup! It confuses.
- 5. Shu-Ha-Ri • Three levels are known in other skill areas: Aikido (self defense technique) • Shu: learn. Build technical foundation for the art. Single instructor. • Ha: detach. Understand meaning and purpose; not just repetitive practice. • Ri: transcend. Practitioner; original thoughts
- 6. A Cooperative Game of Invention and Communication • A fruitful way to think about software development. • Games used by mathematicians and corporate strategiests. • Kinds of games: zero-sum, positional, competitive, cooperative, finite, …
- 7. Software Development • Group game • Non-zero-sum: multiple winners and losers. • Better not viewed as a positional game: state is recorded. • Cooperative • Goal-seeking • Finite
- 8. Infinite Games • Infinite games: organizations, corporations and countries, a person’s profession. • Do well in one game to be well positioned for the next one.
- 9. Software and Rock Climbing • Best comparison partner • Cooperative and goal seeking – How well they climbed together – How much they enjoyed themselves – Reach the top? • Load bearing – Climbers must support their weight. Software must run.
- 10. Software and Rock Climbing • Team • Individuals with talent • Skill sensitive • Training • Tools • Resource-limited: before nightfall or the weather changes.
- 11. Software and Rock Climbing • Plan • Improvised
- 12. A Game of Invention and Communication • Software development: group game which is goal seeking, finite and cooperative • Team: sponsor, manager, usage specialists, designers, testers and writers • Next game: maintenance, build an entirely different system
- 13. Cooperative Game of Invention and Communication • Measure of quality as a team: how well they cooperate and communicate during game. • What are the moves of the game: – There is nothing in the game but people’s ideas and the communication of those ideas to their colleages (including the sponsor) and to the computer.
- 14. Emotions, wishes and thoughts • The task facing the developers: – They are working on a problem they don’t fully understand and that lives in emotions, wishes and thoughts and that changes as they proceed. – They need to understand. • Problem space. • Imagine some mechanism in a viable technology space. • Express in an executable language which lacks many features of expression to a system that is unforgiving of mistakes.
- 15. What is software development? • Software Development is a resource- limited) cooperative game of invention and communication. – The primary goal of the game is to deliver useful, working software. – The secondary goal of the game is to set up for the next game. The next game may be to alter or replace the system or to create a neighboring system. Not many people have articulated this before
- 16. Software and Engineering • Considering software development as a game with moves is profitable. – Gives us a way to make meaningful decisions on a project. • In contrast: speaking of software development as engineering or model building does not help.
- 17. Engineering • People mostly use engineering to create a sense of guilt for not having done enough of something, without being clear of what that something is. • Dictionary: The application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to man (Webster’s Dic.).
- 18. What is “doing engineering” • In my experience: involves creating a trade- off solution in the face of conflicting demands. • Also applies to software development.
- 19. Confusing act and outcome • Outcome: The factory, which is run while specific people watch carefully for variations in quantity and quality of the items being manufactured. • Act: ill-defined creative process the industrial engineer goes through to invent the manufacturing plant.
- 20. More like Engineering? • When people say: “Make software development more like engineering” they often mean, “Make it more like running a plant, with statistical quality control”. • But: running the plant is not the act of doing engineering.
- 21. Look up previous solutions • The other part of “doing engineering” • Civil engineers are not supposed to invent new structures. – Take soil samples and use the code books to look for the simplest structure that handles the required load over the given distance building on the soil at hand. – Centuries of tabulation of known solutions
- 22. Fits marginally • This only fits marginally the current state of software development • We are still in the stage where there is competition between designs. • Technologies are changing fast that few code books exist • Today there are more variations between systems than there are commonalities.
- 23. Return • Return to consider engineering as thinking and making trade-offs.
- 24. Software and Model Building • Ivar Jacobson: “software development is model building” • Leads to inappropriate project decisions
- 25. Interesting part not in models • If software development were model building, then the valid measure of the quality of the software or of the development process would be the quality of the models (fidelity, completeness)
- 26. But successful project teams say • The interesting part of what we want to express doesn’t get captured in those models. The interesting part is what we say to each other while drawing on the board. • We don’t have time to create fancy or complete models • Paying attention to the models interfered with developing the software
- 27. Sufficiency • The work products of the team should be measured for sufficiency with respect to communicating with the target group. • It does not matter if incomplete, incorrect syntax, … if they communicate sufficiently to the recipients.
- 28. Modeling as team communication • Can be too much or too little. • How much modeling to do? Subject of this book.
- 29. What is software development? • Software Development is a resource- limited) cooperative game of invention and communication. – The primary goal of the game is to deliver useful, working software. – The secondary goal of the game is to set up for the next game. The next game may be to alter or replace the system or to create a neighboring system. Not many people have articulated this before
- 30. Programmers as Communications Specialists • Game of communication: different light on programmers … • Stereotyped as noncommunicative individuals who like to sit in darkened rooms • High acceptance of programming in pairs … Programmers thought they would not like it but they like it! (Extreme Programming)
- 31. Game of invention • So far not as a game of communication • Interest of programmers to discuss programming matters gets in the way of them discussing business matters with sponsors, users and business experts.
- 32. Universities • Can reverse the general characteristics by creating software development curricula that contain more communication-intensive courses • Attracts different students (University of Aalborg, Denmark).
- 33. Gaming Faster • We should not expect orders of magnitude improvement in program production. • As much as programming languages may improve, programminvg will still be limited by our ability to think through the problem and the solution.
- 34. Analogy • Two other fields of thought expression – Writing novels – Writing laws: Lawyers won’t get exponentially faster at creating contracts and laws!
- 35. Diminishing Returns • Because a software development project is resource limited, spending extra to make an intermediate work product better than it needs to be for its purpose is wasteful. • Work products of every sort are sufficien
- 36. Peter Naur Programming as Theory Building From Computing: A Human Activity (1992, ACM Press)
- 37. What goes on in software development? Intro. • Most accurate account • Quality is related to the match between the theory of the problem and the theory of the solution. • The designer’s job is not to pass along the design but the theories that drive the design.
- 38. What is programming • Should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. • Not as a production of a program and other texts.
- 39. Programming and the Programmer’s Knowledge • Programming = the whole activity of design and implementation • Programming = building up knowledge • What kind of knowledge? • A theory: a person who has or posses a theory knows how to do certain things and can support the actual doing with explanations, justifications and answers to queries.
- 40. Theory transcends documentation in at least 3 essential ways • How are affairs of the world mapped into the program text? For any aspect of the world the programmer can state its manner of mapping into the program text. [AOSD] • Can support the program text with some justification. • Is able to respond constructively to any demand for a modification. Similarity of new demand to similarities already in the system.
- 41. Problems and Costs of Program Modifications • Cost savings by modifying existing program rather starting from scratch. • Cheaper? Not supported by other complicated man-made constructions: bridges, buildings, etc. Often demolish and rebuild is most economical. • Program modification is just text editing?