OPEN DEVELOPMENT,AGILE, XP AND SCRUM

© University of LiverpoolCOMP 319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 10

fetchmail Lessons 12-17• 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 LiverpoolCOMP319 slide 11

Syntactic sugar is your friendpublic int X{ // C# get { return x; } set { x = value; }}•Generics (always use if relevant!)•For each JavaArrayList <Person> list=new ArrayList <Person>();for (Person person : list) { }Make’s code tighter

© University of LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 13

1970s Perspective

© University of LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 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 LiverpoolCOMP319 slide 19

Surgical team structure C21st

• 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 LiverpoolCOMP319 slide 20