OPEN DEVELOPMENT, Agile, xp AND SCRUM

OPEN DEVELOPMENT,Agile, xp AND SCRUM COMP 319

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 COMP319

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 COMP319

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 COMP319

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 COMP319

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 COMP319

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 COMP319

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 COMP319

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 COMP319

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 COMP319

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

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 COMP319

1970s Perspective • 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 COMP319

The Surgeon role • Involved in overall system architecture • Defines functional and performance specification • Writes documentation • Uses HLL and CASE tools • Experienced and well paid COMP319

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 COMP319

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 COMP319

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 COMP319

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 COMP319

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 COMP319

OPEN DEVELOPMENT, Agile, xp AND SCRUM