OPEN DEVELOPMENT, AGILE, XP AND SCRUM © University of LiverpoolCOMP 319slide 1

Linux a brief history GNU project  Richard Stallman  C compiler released in 1987 Minux  Andrew S. Tanenbaum  12,000 lines of C and 8086 assembler Linux  Linus Torvald 1991 Linux distribution today  Linux kernel (3%) + GNU software (28%) + others © University of LiverpoolCOMP319slide 2

Cathedral and the Bazaar Eric Raymond in 1997 published The Cathedral and the Bazaar He conjectured that there were essentially two ways to engineer software 1. In the cathedral, and 2. In the bazaar © University of LiverpoolCOMP319slide 3

Cathedral approach (e.g. IBM, MS) Leads to large complex programs such as operating systems These projects were worked on by teams of “high-priests/cathedral builders” The product was essentially completed when released for sale Were the province of large organisations © University of LiverpoolCOMP319slide 4

The Bazaar Approach A large network of communicating developers all interested in the solution “Release early. Release often. And listen to your customers” - Linus’ principle “Given enough eyeballs, all bugs are shallow'' - Linus' law coined by Raymond Source freely available and everyone encourage to take part as equals © University of LiverpoolCOMP319slide 5

Open source development All code open to peer review Large tester base (need to early and frequent code releases, early Linux was released daily) Open source code/testing debugging  testing frameworks  Run the code using source code debugger © University of LiverpoolCOMP319slide 6

Case study (fetchmail) Raymond set out to discover why the bazaar approach worked About increasing personal productivity About open source, open management, open goals “egoless programming” Weinberg © University of LiverpoolCOMP319slide 7

fetchmail Lessons 1-6 Personal commitment to the software Use what is available One will get thrown away The individual (interest) is central Interest is not necessarily sustained Users like helping; become developers © University of LiverpoolCOMP319slide 8

fetchmail Lessons 7-11 Release early & often. Listen to your customers Many eyes make debugging light Get data structures right, code follows Testers are your most valuable resource Recognise good ideas from others © University of LiverpoolCOMP319slide 9

fetchmail Lessons 7-11 Release early & often. Listen to your customers Many eyes make debugging light Get data structures right, code follows Testers are your most valuable resource Recognise good ideas from others © University of LiverpoolCOMP319slide 10

fetchmail Lessons Recognise your poor ideas Design perfection comes from pruning Good software is used in unexpected ways Don’t throw information away Beware of pseudo-secrets © University of LiverpoolCOMP319slide 11

Syntactic sugar is your friend public int X{ // C# get { return x; } set { x = value; } } Generics (always use if relevant!) For each Java ArrayList list=new ArrayList (); for (Person person : list) { } Make’s code tighter © University of LiverpoolCOMP319slide 12

Surgical Teams Observations on team working – Brooks Roles: surgeon, co-pilot, administrator, editor, 2 secretaries, program clerk, toolsmith, tester, language lawyer. 10 roles; around two surgeons one taking the lead and dedicated to the project Teams of 10 do the surgery © University of LiverpoolCOMP319slide 13

1970s Perspective © University of LiverpoolCOMP319slide 14 PDP 11  Max 128K RAM  Cost about £12,000 then, equivalent of around £124,000 Applications at the time  Therac-25 radio therapy  Air traffic control

The Surgeon role Involved in overall system architecture Defines functional and performance specification Writes documentation Uses HLL and CASE tools Experienced and well paid © University of LiverpoolCOMP319slide 15

Co-Pilot Role Can do whatever the surgeon can Shares in the design as a thinker, discussant, and evaluator Represents the team and acts as interface May write code but is not responsible for it Less experienced, younger © University of LiverpoolCOMP319slide 16

Administrator, editor, support Administrator deals with staff, money, space. Liaises with the rest of the organisation. Usually serves two teams. Editor generates final documentation, nurses it through to publication Clerical and secretarial support is vital for the administrator and editor © University of LiverpoolCOMP319slide 17

Program Clerk, Toolsmith Clerk maintains all technical records as a librarian and as a secretary is responsible for machine, and paper files Toolsmith is an expert who evaluates, upgrades, customises, builds tools as required by the surgeon and team © University of LiverpoolCOMP319slide 18

Tester, Language Lawyer Tester generates test cases and writes the test environment. S/he confirms that the functional requirements are met Language Lawyer is the HLL expert who thinks up neat, efficient ways to do difficult and obscure things. Will be constantly researching good technique. One lawyer serves several teams © University of LiverpoolCOMP319slide 19

Surgical team structure C21 st Software team leader and junior programmer Tester Project manager/administrator Everything else done by  IDE and debugging, re-factoring tools  OO patterns  Source control systems © University of LiverpoolCOMP319slide 20