brief introduction to software project management the...

Brief Introduction to Software Project Management

Dr. Radu Marinescu 1Lecture 1

The Cathedral and the Bazaar

! Eric S. Raymond! Famous Linux hacker! Controversial advocate of OSS

" OSS = Open-Source Software! Author of fetchmail

! Essay(1997) presents two development models! Cathedral: code available only at releases

" During developed access restricted" Also typical for proprietary code

! Bazaar: code developed via Internet



Lesson 1: See the real need

! Easier said than done…! It works when the user is the builder

! Lesson to learn: we should really understand the goal of the undertaking… or at least struggle to understand it.

Every good work of software starts by scratching a developer’s personal itch.



! Constructive Laziness! Example of Linux

! Inspired from Minix

! Crucial element in Bazaar: not to start from the scratch!It’s not always feasible

Good programmers know how to write.Great ones know how to rewrite (and reuse).

Lesson 2: Rewriting vs. Writing



! We often don’t understand a problem until after the first time we implement a solution

! This is not Fatalism! The point is that starting over with a new idea is usually more effective than trying to salvage a mess

“Plan to throw one away;You will anyhow!”

F.P.Brooks, 1975

Lesson 3: Don’t be Nostalgic



Lesson 4: Be Ready to Hand It Off

! Culture of code-sharing

! Is hardly possible to be generalized

! You really have to be sure that you hand it over to someone who is capable of continuing your effort

When you loose interest in a program,your last duty is to hand it off to a competent successor.



Lesson 5: Importance of Having Users

! Users are great because:! you have the feeling you are doing something really useful

" Microsoft will tell you the same ;-) !They might become co-developers

! Again, this applies only where users are also “hackers”!! Impossible to generalize

! There is also a danger…the heterogeneity of users’ needs

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.



Lesson 6: Linus’ Law

! Raymond’s restatement: “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly, and the fix obvious to someone”

! Different types of problems [Bezroukov, “Second Look at CatB”] :! I. Code Errors! II. Logical Errors! III. Architectural Problems

! Nice…but applicable mainly to the first two categories

“Given enough eyeballs, all bugs are shallow.”Linus Torvalds



Lesson 7: Beta-Testers Highly Valuable

! Release early and often! Grew beta list by adding everyone who asked about the product! Sent announcements whenever a release appeared

! Encouraging people to participate

! Listened to the beta-testers! Polling them about design decisions

If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.



Lesson 8: Release Early, Release Often

! All modern development processes teach this!! Raymond claims that this is against the “Cathedral” style

! As this allows users to see many bugs

! It stimulates and keeps active the community you formed around your project

Release early! Release often!Listen to your customers!



Lesson 9: Humbleness

! Usually as a result of “brainstorming” with the co-developers

! Be receptive

The next best thing to having good ideas isrecognizing good ideas from others.

Sometimes the latter is better.



Lesson 10: “Out of the Box” Thinking

! Whenever you hit a wall in development… take two steps back! To get perspective

! Have the courage the review/refine the metaphor!! Not only minor details

Often, the most striking and innovative solutions come fromrealizing that your concept of the problem was wrong


Dr. Radu Marinescu



Lesson 11: Minimalism

! “Second-System Effect”! Throw away “embellishment features”

! At the code level! Whenever it becomes better and simpler you know it’s right

“Perfection [in design] is achieved not when there is nothing more to add,

but rather when there is nothing more to take away”

Antoine de Saint-Exupéry


Dr. Radu Marinescu 14

Preconditions for the Bazaar Style



Preconditions for the Bazaar Style

! Very hard to originate a project in bazaar mode.

! Be able to provide a plausible promise to the co-developers to be! It must run and it must be evolvable into something cool in the foreseeable

future

! Must start with an attractive design! Either originating from the “project leader” (the initiator) or by applying Lesson 10

! Be aware of the “Second-system effect”

! Project initiator must have good communication and people skills



Driving Forces in the Open-Source Community

1. Principle of common understanding

! “severe effort of converging wills”! Opposed to “command and discipline” (power relations)

2. Cheap Internet # Telecollaboration [Brooks,2000]! We need to learn this too

3. “Egoboo”! Ego boosting # enhancement of one’s reputation among other fans! Connect the selfishness of individual hackers to difficult ends that can be

achieved only by sustained collaboration.! Example: Documentation in the Linux community



Lessons Learnt…

Every good work of software starts by scratching a developer’s personal itch.

Good programmers know how to write.Great ones know how to rewrite.

“Plan to throw one away; You will anyhow!”

When you loose interest in a program, your last duty is to hand it off to a competent successor.

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

“Given enough eyeballs, all bugs are shallow.”

If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.



Lessons Learnt… (ctd)

Release early! Release often! Listen to your customers!

The next best thing to having good ideas is recognizing good ideas from others.Sometimes the latter is better.

Often, the most striking and innovative solutions come fromrealizing that you concept of the problem was wrong

“Perfection [in design] is achieved not when there is nothing more to add, but rather when there is nothing more to take away”



Second Look at the Cathedral and the Bazaar (CatB)

N.Bezroukov



Vulnerable Claims of the CatB

1. Brook’s Law doesn’t apply to Internet-based distributed development

2. Linus’ Law

3. The open source-code is the key factor in the Bazaar

4. Linux does definitely belong to the Bazaar model



Claim 1: Bazaar vs. Brook’s Law

! Internet connectivity cannot improve performance of programming teams!Same level of developers, are better if geographically compact! Internet dramatically raises the quality of the pool!…but it cannot eliminate the other project constraints

! When is it possible to have Brook’s Law “suspended”?!Where a fully functional prototype already exists and !Most architectural problems are solved

" Like it was with Linux



Claim 2: Given enough eyeballs, all bugs are shallow

! Illusion of shallow bugs…

! Every 2-3 bugs removed, introduce a new bug ;-)

! Talented developers used for parallel debugging:!Brute force is a waste of skills and talent

!Bugs are not equal!

!Bug hunting is only sometimes rewarding" Works for politically or technically important bugs

!Rewriting vs. Fixing



Claim 3: The Key Element is the Availability of Code

! WRONG! The main problem: Understanding the code! Reverse Engineering techniques! Harder than writing code

! “Binarization” of code! ! Source code is not enough! ! Reading code is not feasible for large-scale systems

! Concealing architectural information can be an effective strategy for controlling an open source project!

The actual problem is program comprehension.It’s always good to have the source-code,

but the problem is that often it’s not enough!



Claim 4: Linux is Pure Bazaar Development

! CatB fails to differentiate between types of projects/activities! Kernel vs. peripherals of Linux! Size of project

! Manichaeistic view of Cathedral and Bazaar is harmful!

Open source may sound democratic; but it isn’t!Linus Torvalds

! Example: Linus must accept all patches to the kernel! Communication filtered by his lieutenants! You cannot talk directly to Linus



It’s All About Humans…

! Status Competition! Evaluation towards colleagues

! In OSS…! Those that have the power usually deny it;! Those that want to have it pretend they don’t

! Political maneuvering



Brooks Conclusions on CatB

Works when the builders are the clients (i.e. they know the requirements from personal experience)

F.P.Brooks

brief introduction to software project management the...

Documents