0% found this document useful (0 votes)
288 views

Code Simplicity Open Source Design

This document discusses principles of software design in open source projects. It outlines seven principles: focus on the future rather than the present; assume code will change over time; the chance of defects increases with larger code changes; maintain simplicity; resolve uncertainties through comments and user expectations; bugs come from complexity and misunderstandings; and extensive testing is needed. It notes challenges of open source like limited review processes, developer time, and communication. Solutions include maintaining extreme consistency, brief communications, extensive documentation, and surveying users. The overall goal is to provide information to help make design decisions.

Uploaded by

Vaibhav Mule
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
288 views

Code Simplicity Open Source Design

This document discusses principles of software design in open source projects. It outlines seven principles: focus on the future rather than the present; assume code will change over time; the chance of defects increases with larger code changes; maintain simplicity; resolve uncertainties through comments and user expectations; bugs come from complexity and misunderstandings; and extensive testing is needed. It notes challenges of open source like limited review processes, developer time, and communication. Solutions include maintaining extreme consistency, brief communications, extensive documentation, and surveying users. The overall goal is to provide information to help make design decisions.

Uploaded by

Vaibhav Mule
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

Code Simplicity: Software Design In Open Source Projects

Max Kanat- lexander max!codesimplicity"com

#efore $%e S%ow


I tal& 'uic&ly Stop me if you don(t understand


lso stop me if you need examples )uestions or disagreements at end More detail on e,eryt%ing at my *log: %ttp:--www"codesimplicity"com-

Points will *e fast+ *ut still important

Some of t%ese t%ings you may already &now+ w%at matters is pointing t%em out as important"

.%o am I/

ssistant Project 0ead for #ug1illa .riter of Code Simplicity 0ong-time programmer and system administrator 2xperience programming and designing

Data comes from:

#ug1illa 3experiment4

Inter,iewing many programmers 5eading extensi,ely wit% analysis

Data collection is difficult *ecause of t%e timeframe of software projects"

I spea& ,ery definitely+ *ut please ma&e up your own mind a*out t%e t%ings I am saying"

.%at Is Software Design/

dministrati,e Decisions

.%at programmer to put w%ere De,elopment timeframes etc"

Coding Technical Decisions


.%at language to use .%at tec%nologies to c%oose etc"

$%ere Is 6o Science of Software Design

Science re'uires:

0aws Proof 5esults 3.aterfall4 3 gile4 etc"

Many met%odologies+ no science:


6ot going to pro,e anyt%ing today+ just s%ow

Can pro,e+ t%oug%+ in ,arious ways

$%ere are similar ideas out t%ere+ *ut t%ey are not t%e same as w%at I am going to tal& a*out

0argely t%ey are not low-le,el enoug%

Se,en Principles:
%ttp:--c7"com-cgi-wi&i/Se,enPrinciplesOfSoftwareDe,elopment

$%ey tell you what to do+ I only %elp you ma&e decisions for yourself and try to tell you why" I did not deri,e from any of t%ese met%odologies+ *ut t%e *its of t%em t%at wor& could *e deri,ed from w%at I am going to tell you"

.%y 8a,e a Science of Software Design/


8elp Ma&e $ec%nical Decisions Why do some t%ings 3wor&4 and ot%ers don(t/

5esults

#ug1illa Impro,ed My Own Programming

5esol,ed e,ery 'uestion

#roug%t no,ices to understand why 2xplained difficulties and 3war stories4 of experienced programmers

6ot #rainwas%ing or Mar&eting

6ot going to tell you w%at decisions to ma&e+ just going to gi,e you information t%at will %elp you ma&e t%em

$%is differs from met%odologies

#u11word-free

9OSS ,s" Proprietary

$%e *asics are t%e same+ *ut application can *e different"

Purpose Of Software

To help people

6e,er 3to %elp t%e computer4 Specific software is 3$o %elp people :*la%;4 S%ort Simple Specific 6eeded 9ollowed 2xactly

Stated purpose s%ould *e:


<oals of Software Design


#e as %elpful as possi*le Continue to *e as %elpful as possi*le Ma&e decisions t%at ma&e it easy to *e :and continue *eing; as %elpful as possi*le

Primary 0aw: 9uture

$%ere is more future t%an present

9uture is composed of infinite series of presents

$%e future is more important t%an t%e present 2ffort spent on design s%ould *e proportional to %ow muc% future time t%ere is in w%ic% you expect t%e software to exist

Planning to re-write is unnecessary

9uture: Known ,s" =n&nown


Known =n&nown

9ar 9uture 6ear 9uture 9uture 5e'uirements Conse'uences

Software %as long time lines

0aw Of C%ange

$%e longer your software exists+ t%e more pro*a*le it is t%at any piece of it will %a,e to c%ange

Means t%at as time goes on+ every piece is li&ely to c%ange

0aw of Defect Pro*a*ility

$%e c%ance of introducing a defect into your program is directly proportional to t%e si1e of t%e c%anges you ma&e

Perfection is impossi*le

.rite as little code as possi*le Don(t fix w%at isn(t *ro&en 2xplains re-use

0aw Of Simplicity

$%e ease of maintenance of any piece of software is directly proportional to t%e simplicity of t%e indi,idual pieces

6ot of t%e w%ole system+ just t%e indi,idual pieces

Stated differently+ is in,erse to t%e complexity" Simplicity is relati,e+ largely to ,iewpoint 8ow simple do you %a,e to *e/

Perspecti,e of anot%er programmer w%o(s ne,er seen your code

#e consistent

.%at Is a #ug/

Programmer(s Intentions

=ncertainties can *e resol,ed *y:


Comments Spec 35easona*le programmer4 ssume %e-s%e meant to do w%at is *est for t%e user

=ser 2xpectations

Specs t%at ,iolate user expectations are spec *ugs If t%ere(s a conflict+ it(s 3majority rules4

>ou can also add a preference+ *ut t%at adds complexity

.%ere Do #ugs Come 9rom/

Complexity

$%e *ox wit% a million unla*eled *uttons Particularly of language words+ sym*ols+ functions+ etc"

Misunderstandings

30aw4 of $esting

>ou don(t &now it wor&s unless you(,e tried it"

pplication in 9OSS

Must be more hardcore

0argely pro*lems wit% geograp%ic distri*ution

8ere(s w%ere I tell you some t%ings to do+ *ut you s%ould still ma&e up your own mind"

Difficulties of Design in 9OSS

Speed of c%ange can *e limited


5e,iews C%ec&in Procedures 0ac& of Some*ody to $al& $o :I5C %elps; Designer(s $ime

$ime a,aila*le can *e limited

8a,e to communicate designs 'uic&ly 8a,e to *e a*le to read design 'uic&ly

Implementer(s $ime

Communication *andwidt% is limited


8a,e to type to communicate design 6o w%ite*oard+ etc" <roup pro*a*ly won(t all *e t%ere at once 2it%er to de,elopment in general or just your project"

6o,ices

Desire for consistency ,s" desire for de,elopment speed Disconnection wit% users =ser re'uirements ? My re'uirements/

De,elopers pic& w%at to wor& on


May not want to conform to design May not want to wor& on refactoring

<etting out releases for testing

Solutions

2xtreme consistency

If you can(t communicate a design+ it %elps if t%e existing code already wor&s t%e rig%t way

#rief communications Code re,iews 2xtensi,e de,eloper documentation 0ots of attention to new*ies

#e nice

5ead support mail 5ead *logs a*out your product

#ut don(t e,er let your detractors write your re'uirements"

Sur,ey your users 8a,e some*ody w%o lo,es refactoring

$%e 2nd: ) @

%ttp:--www"codesimplicity"commax!codesimplicity"com

You might also like