Mandeår
vagnk
regnskabssystem. Jeg havde et skud om dagen og fejlrettelser tog en
dag i hullestuen. Så en glemt parantes betød 2 dage før næste skud.
Sproget var COBOL, som ikke var det mest kompakte sprog i verden. Det
fyldte omkring 4-500 linjer og jeg var omkring et halvt år om at
programmere det. Nu var det ikke sådan at jeg sad i to dage og
trillede tommelfingre. Vi havde altid 5-6 skibe i søen.
I dag ville jeg kunne lave en råbalance på 10 minutter, hvis
regnskabet lå i en struktureret DB og jeg havde en ordentlig
ReportWriter. Mindre end en dag hvis jeg selv skulle kode en php-side.
Nu er jeg for længst pensioneret, men skal overbevise min organisation
om at phpBB ikke er et lille bær, selvom det tager mindre end en time
at installere og konfigurere det. Jeg har talt kodelinjerne i phpBB3
til 9887 linjer, men det siger ikke ledelsen en bønne, når jeg taler
om 200-250 A4 ark. Et tydeligt mål ville være mandetimer/år.
Hvor mange linjer kan en gennemsnitlig kodekarl lave om dagen i OOP i
et tilfældigt programmeringssprog med test, fejlrettelser, ændringer
og omprogrammeringer? Min egen fornemmelse er at når vi taler om sådan
et bær ville 15-20 linjer i gennemsnit være rimeligt. Hvis jeg bruger
det skulle det betyde, at jeg ville være et par år om at lave det. Er
jeg helt i skoven?
Adam Sjøgren
> Nu er jeg for længst pensioneret, men skal overbevise min organisation
> om at phpBB ikke er et lille bær, selvom det tager mindre end en time
> at installere og konfigurere det.
(Hvordan ser phpBB's sikkerhedshistorik ud?)
> Jeg har talt kodelinjerne i phpBB3 til 9887 linjer, men det siger ikke
> ledelsen en bønne, når jeg taler om 200-250 A4 ark. Et tydeligt mål
> ville være mandetimer/år.
> Hvor mange linjer kan en gennemsnitlig kodekarl lave om dagen i OOP i
> et tilfældigt programmeringssprog med test, fejlrettelser, ændringer
> og omprogrammeringer?
En nem mulighed er at køre David Wheelers SLOCCount på koden og se hvad
den giver:
SLOCCount (pronounced "sloc-count") is a suite of programs for counting
physical source lines of code (SLOC) in potentially large software
systems (thus, SLOCCount is a "software metrics tool" or "software
measurement tool"). SLOCCount can count physical SLOC for a wide number
of languages; listed alphabetically, they are: Ada, Assembly, awk,
Bourne shell, C, C++, C shell, COBOL, C#, Erlang, Expect, Fortran,
Java, lex/flex, LISP (including Scheme), Makefile, Modula3,
Objective-C, Pascal, Perl, PHP, Python, Ruby, sed, SQL, Tcl,
Yacc/Bison.
SLOCCount can automatically determine if a file is a source code file
or not, and if so, which language it's written in. As a result, you can
analyze large systems completely automatically. SLOCCount also includes
some report-generating tools to collect the data generated and present
it in several different formats.
- http://www.dwheeler.com/sloccount/
Men hvad er det du skal overbevise dem om? At det ikke er værd at bruge
tiden på at bygge en kopi selv?
Mvh.
Adam
--
"Dansk, dette unikum af artikulatorisk økonomi." Adam Sjøgren
as...@koldfront.dk
Stig Johansen
> Sproget var COBOL, som ikke var det mest kompakte sprog i verden. Det
> fyldte omkring 4-500 linjer og jeg var omkring et halvt år om at
> programmere det.
Det er billigt sluppet - de COBOL ting jeg har lavet starter med ~ 800
linier inden man kommer til forretningslogikken.
> Nu var det ikke sådan at jeg sad i to dage og
> trillede tommelfingre. Vi havde altid 5-6 skibe i søen.
Nu var jeg så heldig, at en kompilering af et 'simpelt' program 'kun' tog
20-30 minutter.
> I dag ville jeg kunne lave en råbalance på 10 minutter, hvis
> regnskabet lå i en struktureret DB og jeg havde en ordentlig
> ReportWriter.
Teknik og indhold.
Der er forskel på at lave et 'teknisk' udtræk, og regnskabsmæssige korrekte
oplysninger.
> Mindre end en dag hvis jeg selv skulle kode en php-side.
Hvorfor gør du så ikke det ?
> Nu er jeg for længst pensioneret, men skal overbevise min organisation
> om at phpBB
Undskyld jeg spørger - men hvad har phpBB med regnskaber at gøre ?
> Jeg har talt kodelinjerne i phpBB3
> til 9887 linjer
Kvalitet og kvantitet hænger ikke sammen.
> Hvor mange linjer kan en gennemsnitlig kodekarl lave om dagen i OOP i
> et tilfældigt programmeringssprog med test, fejlrettelser, ændringer
> og omprogrammeringer?
Afhænger af værktøjer, og inden for 'kodekarle' er der en voldsom stor
performacefaktor > 1:100
> Min egen fornemmelse er at når vi taler om sådan
> et bær ville 15-20 linjer i gennemsnit være rimeligt. Hvis jeg bruger
> det skulle det betyde, at jeg ville være et par år om at lave det. Er
> jeg helt i skoven?
Det afhænger af performancefaktoren, i bunden af skalaen, kan du forudsætte
at en given kodekarl kan lave ~ 20 linier, men en anden kodekarl i toppen
af skalaen ville kunne lave ~ 2000 linier.
--
Med venlig hilsen
Stig Johansen
vagnk
Nogen har bildt dem ind at de kan lave et debatforum på 150 timer. Jeg
har prøvet at fortælle ledelsen at det kan etableres på et par timer,
men det lyder åbenbart så vanvittigt i deres ører at der må være noget
galt. Ingen fra ledelsen har en dyt check på it.
Vagn
On Dec 24, 10:10 am, a...@koldfront.dk (Adam Sjøgren) wrote:
> En nem mulighed er at køre David Wheelers SLOCCount på koden og se hvad
> den giver:
>
> SLOCCount (pronounced "sloc-count") is a suite of programs for counting
> physical source lines of code (SLOC) in potentially large software
> systems (thus, SLOCCount is a "software metrics tool" or "software
> measurement tool"). SLOCCount can count physical SLOC for a wide number
> of languages; listed alphabetically, they are: Ada, Assembly, awk,
> Bourne shell, C, C++, C shell, COBOL, C#, Erlang, Expect, Fortran,
> Java, lex/flex, LISP (including Scheme), Makefile, Modula3,
> Objective-C, Pascal, Perl, PHP, Python, Ruby, sed, SQL, Tcl,
> Yacc/Bison.
>
> SLOCCount can automatically determine if a file is a source code file
> or not, and if so, which language it's written in. As a result, you can
> analyze large systems completely automatically. SLOCCount also includes
> some report-generating tools to collect the data generated and present
> it in several different formats.
>
> -http://www.dwheeler.com/sloccount/
>
> Men hvad er det du skal overbevise dem om? At det ikke er værd at bruge
> tiden på at bygge en kopi selv?
>
> Mvh.
>
> Adam
>
> --
> "Dansk, dette unikum af artikulatorisk økonomi." Adam Sjøgren
Adam Sjøgren
> Nogen har bildt dem ind at de kan lave et debatforum på 150 timer.
Alt efter hvad det skal kunne, så er det vel ikke specielt urealistisk?
Det er immervæk en hel måned.
> Jeg har prøvet at fortælle ledelsen at det kan etableres på et par
> timer, men det lyder åbenbart så vanvittigt i deres ører at der må
> være noget galt. Ingen fra ledelsen har en dyt check på it.
Så må du prøve at uddanne dem lidt om Fri Software.
Mvh.
Adam
P.S. Hvor kommer udtrykket "et bær" som software fra? Det har jeg aldrig
hørt før.
--
"Mr. Lambada, rejser kun charter Adam Sjøgren
Sidder i baren og sælger falske anparter" as...@koldfront.dk
dk_sz
> af skalaen ville kunne lave ~ 2000 linier.
Hele humlen bliver naturligvis når med medregne teste,
debug osv. Det kan jo engang imellem tage sindsygt lang
tid, fx ved massivt tråede programmer hvor man et eller
andet åndsvagt sted har gjort en fejl... Og endnu værre hvis
der er fejl i et standard bibliotek der kun sjældent popper op.
Den slags dage tæller virkeligt ned i effektivitet :-)
mvh
Thomas
Stig Johansen
> Hele humlen bliver naturligvis når med medregne teste,
> debug osv.
Ja, jeg mener vi altid har haft den tommelfingerregel, at 80% af et projekt
er kommunikation og design, og kun 20% kodning.
Hvis det også skal dokumenteres plejer vi at sige det tager ca lige så lang
tid som udviklingen.
> Det kan jo engang imellem tage sindsygt lang
> tid, fx ved massivt tråede programmer hvor man et eller
> andet åndsvagt sted har gjort en fejl... Og endnu værre hvis
> der er fejl i et standard bibliotek der kun sjældent popper op.
Ja, eller endnu værre hvis den ikke popper op.
Det er ikke så lang tid siden jeg havde en åndsvag fejl i en multithreaded
(NPTL) applikation.
NPTL er sindsygt hurtigt i forhold til Windows/traditionel Linux threading,
men til gængæld har den de egenskaber, at den
a) fryser hele lortet, incl hovedtrådenq
eller
b) den pågældende tråd 'vaporizer' uden noget spor.
> Den slags dage tæller virkeligt ned i effektivitet :-)
Ja, heldigvis var mit projekt kun et hobbyprojekt, så jeg behøvede ikke at
tælle LOC's/hour - jeg er heller ikke sikker på jeg vil kende det :-)
Iøvrigt har jeg aldrig kunnet forstå LOC's skulle være en brugbar målemetode
til noget somhelst.
Netop ved at bruge tid på at tænke reuseability, og 'standardisere' koden er
det i virkeligheden det omvendte der gør sig gældende: Jo færre LOC's til
sammen funktionalitet, jo bedre.
Stig Johansen
> Nogen har bildt dem ind at de kan lave et debatforum på 150 timer. Jeg
> har prøvet at fortælle ledelsen at det kan etableres på et par timer,
Pas på med at fokusere ensidigt på installationstiden.
Hvis det skal 'brandes' i forhold til organisationen/marketing, kan der
hurtigt gå tid med design/grafik/layout m.m.
vagnk
Stig skrev:
>Ja, jeg mener vi altid har haft den tommelfingerregel, at 80% af et projekt
>er kommunikation og design, og kun 20% kodning.
>Hvis det også skal dokumenteres plejer vi at sige det tager ca lige så lang
>tid som udviklingen.
I min tid som projektleder brugte jeg en tommelfingerregel jeg kaldte
Keops estimat. Den sagde: Tag et realistisk skøn og gang med 2 og gå
derefter op til nærmeste højere tidsenhed. Et to-ugers job ville udfra
dette vare 4 måneder.
Med den i baghovedet fik jeg splittet projektet så meget op og huskede
alle de ting man altid glemmer, så mine projekter kom næsten altid til
at passe. Alt efter temperament kan man synes det er sørgeligt,
morsomt eller realistisk. Faktum er at en styregruppe eller kunde
hellere vil have et estimat de kan regne med end at blive
præsentetreet for evindelige forsinkelser og udsættelser.
>Iøvrigt har jeg aldrig kunnet forstå LOC's skulle være en brugbar målemetode
>til noget somhelst.
Enig. Efter at have kigget på "SLOCCount" kan jeg ikke se at den kan
noget jeg ikke selv kan.
Adam skrev:
>Hvor kommer udtrykket "et bær" som software fra? Det har jeg aldrig hørt før
Det var vist noget der bare opstod i 80-erne på en talfabrik med 400
ansatte. Vi arbejdede en overgang ikke med projekter eller programmer.
Alt blev relateret til frugter - mere eller mindre rammende.
>Så må du prøve at uddanne dem lidt om Fri Software
Jeg prøver og prøver.
Det er som I sikkert kan forstå 15-20 år siden jeg var inde i rigtig
programmering. Som jeg forsøgte at antyde i mit første indlæg er der
sket en hel del på programmeringsfronten siden 70-erne, men der er
sandelig osse sket en del bare indenfor de sidste 10 år. Jeg havde
håbet på nogle realistiske (eller bare modige) skøn. Jeg tror jeg
holder mig til min egen fornemmelse.
Tak for jeres kommentarer.
Vagn
Adam Sjøgren
> Jeg havde håbet på nogle realistiske (eller bare modige) skøn.
Så har du godt nok fået formuleret dit spørgsmål dårligt.
Du bad om et bud på antal linier per dag per programmør. Hvilket er ret
meningsløst (jævnfør variationen i svarene).
Efterfølgende virkede det slet ikke som det du egentlig havde brug for.
> Jeg tror jeg holder mig til min egen fornemmelse.
Mon ikke du havde gjort det under alle omstændigheder?
:-),
Adam
--
"You've got skills you can make it look good Adam Sjøgren
And unbroken from the root to the fruit" as...@koldfront.dk
Stig Johansen
> On Dec 25, 6:58 am, Stig Johansen <wopr...@gmaill.com> wrote:
>
> Stig skrev:
>>Ja, jeg mener vi altid har haft den tommelfingerregel, at 80% af et
>>projekt er kommunikation og design, og kun 20% kodning.
>>Hvis det også skal dokumenteres plejer vi at sige det tager ca lige så
>>lang tid som udviklingen.
> I min tid som projektleder brugte jeg en tommelfingerregel jeg kaldte
> Keops estimat. Den sagde: Tag et realistisk skøn og gang med 2 og gå
> derefter op til nærmeste højere tidsenhed. Et to-ugers job ville udfra
> dette vare 4 måneder.
Jeg har altid brugt 'ingeniørkonstanten'.
Den siger: Tag et realistisk skøn og gang med PI.
Dog har jeg gennem tiden udvidet den lidt.
Hvis det handler om projekter i forbindelse med Grønland, så skal man bruge
PI^2, og hvis det er projekter inden for det offentlige, så er det PI^2 +
bureaukratiseringsfaktoren - sidstnævnte kan dog variere fra institution
til institution.
> Alt efter temperament kan man synes det er sørgeligt,
> morsomt eller realistisk.
Det er realistisk. Folk har det med at undervurdere opgaven, så et
'realistisk' skøn vil altid være for lavt.
> Faktum er at en styregruppe eller kunde
> hellere vil have et estimat de kan regne med end at blive
> præsentetreet for evindelige forsinkelser og udsættelser.
Her rammer du hovedet på sømmet.
Min erfaring siger det samme - kunderne er fløjtende ligeglade med om det er
om 6 måneder, 8 eller 10 måneder, bare det HOLDER (tid og budget).
> Det er som I sikkert kan forstå 15-20 år siden jeg var inde i rigtig
> programmering. Som jeg forsøgte at antyde i mit første indlæg er der
> sket en hel del på programmeringsfronten siden 70-erne,
Nu har jeg kun været med siden '80, men jeg synes ikke der overordnet set er
sket noget særligt på programmeringsfronten, andet end computerne er blevet
hurtigere.
Eksempelvis arbejdede vi rimeligt intensivt med, som den første nation i
verden, at indføre elektroniske(digitale) obligationer for 26 år siden.
Fuld integration, og en kompleksitet der langt, langt overgår det forsøg man
har lavet med 'eFaktura'.
> men der er
> sandelig osse sket en del bare indenfor de sidste 10 år.
Jeg synes nu ikke der er sket noget særligt inden for de sidste 10 år, andet
end 'computere' bliver billigere og billigere, og dermed mere udbredt.
> Jeg havde
> håbet på nogle realistiske (eller bare modige) skøn. Jeg tror jeg
> holder mig til min egen fornemmelse.
Jeg synes ikke du har formuleret en problemstilling der kan bruges til et
skøn.
Et skøn vil afhænge af opgaven, og hvor meget man 'har på lager'.
Hvis man stort set har det hele 'på lager', så kan man vha lidt
klippe/klistre og rettelser kunne fabrikere en ikke uanseelig mængde LOC's
pr dag.
Skal man derimod strate med Adam og Eva, og genopfinde krudtet og den dybe
tallerken, vil LOC's pr. dag nok være meget lille.
Og når vi snakker genbrug, er der tale om 'færdigtestede'
procedurer/funktioner/objekter/klasser, så 'finpudsningen' vil være
minimal.
Edward Jensen
news:9a427bf7-ac7e-4799...@l33g2000pri.googlegroups.com...
>Nu er jeg for længst pensioneret, men skal overbevise min organisation
>om at phpBB ikke er et lille bær
Bær?
>Min egen fornemmelse er at når vi taler om sådan
>et bær ville 15-20 linjer i gennemsnit være rimeligt.
Bær?
Et slangudtryk jeg ikke er bekendt med?
vagnk
>Nu har jeg kun været med siden '80, men jeg synes ikke der overordnet set er
>sket noget særligt på programmeringsfronten, andet end computerne er blevet
>hurtigere.
tekstbaserede terminaler. Tit og ofte var der særlige
kompileringstider i maskinstuerne. COBOL, FORTRAN og PL1 var tunge at
arbejde, især med i IBMs klodsede editorer. Jeg tror FORTRAN-
compileren hos DEC var den første der fik optimizer, ellers skulle der
kodes i assembler, hvis det skulle være rigtig effektivt. Klippe/
klistre foregik ved at inkludere en fil og slette det der ikke var
brug for. C var et gennembrud mht. et relativt lille, men kompakt
sprog og store function-libraries og stilen er videreført i dagens
programmer. En detalje vi kæmpede med når der skulle compileres og
linkes, var at vi rodede rundt i den rigtige rækkefølge og tit glemte
at få alt med, men så kom "make". I de første grafiske terminaler
skulle vi selv lave de widgets vi havde brug for. I dag har vi
generelt gode IDE'er og nogle steder med WYSIWYG. Helt specielt holder
jeg meget af Kubuntu.
Jo, jeg synes der er sket meget.
>Jeg har altid brugt 'ingeniørkonstanten'.
>Den siger: Tag et realistisk skøn og gang med PI.
Interessant. Jeg går ud fra at "ingeniørkonstanten" ikke er den med
cirkelforholdet? Kan du beskrive den lidt mere? Eller er jeg bare dum?
Edward skrev:
> Bær?
>
> Et slangudtryk jeg ikke er bekendt med?
Jeg svarede i et tidligere indlæg:
Det var vist noget der bare opstod i 80-erne på en talfabrik med 400
ansatte. Vi arbejdede en overgang ikke med projekter eller
programmer.
Alt blev relateret til frugter - mere eller mindre rammende.
Jeg har osse været tømrer og der hed søm under 5 tommer "stifter" og
alt over hed "et bær". Når jeg tænker tilbage, har jeg vist ikke været
uskyldig i at udtrykket opstod på min gamle arbejdsplads.
Adam skrev:
>Så har du godt nok fået formuleret dit spørgsmål dårligt.
>Du bad om et bud på antal linier per dag per programmør. Hvilket er ret
>meningsløst (jævnfør variationen i svarene).
Læg mærke til at jeg skrev "gennemsnitlig", og jeg relaterede til et
rimeligt stort og komplekst system med OOP.
Jeg var såmænd ude efter nogle bud fra folk med erfaring fra tiderne i
dag.
>Mon ikke du havde gjort det under alle omstændigheder?
Nej Adam - Jeg kastede et ganske vist svært spørgsmål op i luften, men
intentionen var skam at lytte til folk. Jeg må da osse sige at jeg har
fået noget ud af det.
Jeg tor at vi idag nok har bedre programmeringsværktøjer, men til
gengæld er opgaverne blevet mere komplekse - henfør til indlæg om
tråde her i diskussionen. Så konklusionen er nok noget med at vi laver
ligeså mange kodelinjer, som for 30 år siden, men det vi laver er
meget, meget mere komplekst og effektivt.
Men hvis vi skal lidt videre vil jeg da godt lægge en hypotese på
bordet:
Afhængig af systemets/programmets kompleksitet koder en gennemsnitlig
programmør mellem 15 og 25 linjer om dagen. Møder, test,
omprgrammering, ændrede krav og alt det gylle er inklusive.
En gennemsnitlig programmør laver ikke spaghetti og sætter oplysende
kommentarer (som osse er kodelinier) i sin kode, som er rimeligt
strultureret.
Så mangler vi bare at definere kompleksitet.
Et program der skal tage hensyn til asynkrone hændelser er mere
komplekst end en død HTML-side uden DB og forms. Store systemer med
mange funktioner, rutiner og mange filer er mere komplekse end et
stand alone. Så skal vi bare have sat faktorer på mellem 0 og 1. Vi
kan statrte med at sætte 0 lig med ingen kode og 1 er kompleksitet der
er umuligt at programmere.
Hvis jeg sætter et system som Linux til 0.9 og 20 linier HTML til 0.1
er vi begyndt at indsnævre.
Kan det bruges?
Lige min yndlingsaversion: M$ XP er skrevet så knudret at det har en
kompleksitet på 1.5 hvis det skal rettes!
Vagn
Stig Johansen
> Stig skrev:
>>Nu har jeg kun været med siden '80, men jeg synes ikke der overordnet set
>>er sket noget særligt på programmeringsfronten, andet end computerne er
>>blevet hurtigere.
> Du kom på efter hullestuerne, men du har været med da vi sad med
> tekstbaserede terminaler.
Jeg arbejde for HP dengang, og der havde vi både tekstbaserede og grafiske
terminaler/workstations.
De tekstbaserede var var intellligente terminaler, og ikke dumb terminals
(bortset fra konsollen).
[snip struktur]
Ud over includes havde vi på HP maskinerne både usl (user segmented library)
og sl (segmentet library)
usl filerne indehold kompilerede funktioner uafhængigt af sprog, og blev
prep'et (aka link aka bind) ind i det færdige program.
sl filerne derimod indehold kompilerede funktioner, der blev linket runtime.
(som .dll (windows) eller .so(Linkux).
> skulle vi selv lave de widgets vi havde brug for. I dag har vi
> generelt gode IDE'er og nogle steder med WYSIWYG.
Det er måske lidt af en provokation, men når vi lavede programmer på HP'en,
så:
1) Starte 'form editoren', hvor man 'tegnede' skærmbillede, og markerede
felter, samt noget 'clientside' validering.
2) I overensstemmelse med skærmbilledet definerede man en buffer
indeholdende feltdefinitioner.
3) Når man skulle kommunikere med terminalen, foregik det med ca.
pseudokode.
Initialize buffer
PERFORM PutForm
... vent på bruger trykker send
PERFORM Getform
... opdater database
Bemærk her, at data og præsentation er adskilt. Man kunne rette lige så
tosset man ville i skærmbillederne, bare feltlængder var de samme.
Data til og fra 'formen' er kun feltindholdet.
Med disse ting in mente, spørger jeg:
Hvad er den funktionelle forskel på en HTML form med Javascript og denne
struktur ?
Jo jo grafik, farver bip og båt - men funktionelt?
> Helt specielt holder
> jeg meget af Kubuntu.
Jeg bruger SuSE, men det var baseret på et 'first-fit' valg.
>>Jeg har altid brugt 'ingeniørkonstanten'.
>>Den siger: Tag et realistisk skøn og gang med PI.
> Interessant. Jeg går ud fra at "ingeniørkonstanten" ikke er den med
> cirkelforholdet? Kan du beskrive den lidt mere? Eller er jeg bare dum?
Det er rent slang, og husker ikke præcist hvorfor vi kaldte den
ingeniørkonstanten. Men som du selv er inde på, handlede det om en mere
eller mindre statistisk faktor man skal gange med for at konvertere bedste
skøn til et realistisk skøn.
Du er selv kommet to 2, hvor jeg nok ville bruge 3.
3 er bare et for kedeligt tal, så vi valgte PI som udtryk for faktoren.
Jeg tror det med 'ingeniørkonstanten' var lidt at gøre nar af ingeniører,
der tilsyneladende altid regner forkert, så større anlægsarbejder (broer,
veje osv) altid bliver dyrere end forventet.
Adam Sjøgren
> Adam skrev:
>> Så har du godt nok fået formuleret dit spørgsmål dårligt.
>> Du bad om et bud på antal linier per dag per programmør. Hvilket er ret
>> meningsløst (jævnfør variationen i svarene).
> Læg mærke til at jeg skrev "gennemsnitlig", og jeg relaterede til et
> rimeligt stort og komplekst system med OOP.
Ja, og hvad mening giver gennemsnittet givet den variation du har set i
svarene her? Næppe meget.
Så jeg tror du skulle have spurgt om noget andet, tættere på hvad det er
dit projekt konkret går ud på.
> Jeg var såmænd ude efter nogle bud fra folk med erfaring fra tiderne i
> dag.
Vi regner ikke i antal linier per dag, i dag.
Jeg har ikke set det mål brugt til andet end "Høhø, det var da sjovt, vi
har N linier kode i subversion nu".
Eller når Poul-Henning Kamp på sin weblog på Version2 brokker sig over
at diverse biblioteker er større end hans seneste projekts samlede
kodebase.
> Jeg tor at vi idag nok har bedre programmeringsværktøjer, men til
> gengæld er opgaverne blevet mere komplekse - henfør til indlæg om
> tråde her i diskussionen. Så konklusionen er nok noget med at vi laver
> ligeså mange kodelinjer, som for 30 år siden, men det vi laver er
> meget, meget mere komplekst og effektivt.
I det konkrete tilfælde med et debatforum er opgaven ikke mere kompleks
end den var da usenet blev født (snarere mindre, alt den stund at et
webforum typisk kun involverer en maskine) - og der er f.eks. ikke tråde
involveret.
> Men hvis vi skal lidt videre vil jeg da godt lægge en hypotese på
> bordet:
> Afhængig af systemets/programmets kompleksitet koder en gennemsnitlig
> programmør mellem 15 og 25 linjer om dagen. Møder, test,
> omprgrammering, ændrede krav og alt det gylle er inklusive.
Jeg er bange for jeg ikke forstår hvorfor du anser antal linier per dag
for et brugbart mål til noget som helst formål.
> Så mangler vi bare at definere kompleksitet.
[...0 .. 1...]
> Kan det bruges?
Til hvad?
Mvh.
Adam
--
"Nightmares in the daytime Adam Sjøgren
When everything is as it seems" as...@koldfront.dk
Adam Sjøgren
> Jeg tror det med 'ingeniørkonstanten' var lidt at gøre nar af ingeniører,
> der tilsyneladende altid regner forkert, så større anlægsarbejder (broer,
> veje osv) altid bliver dyrere end forventet.
Måske kan det også hænge sammen med at broer o.l. normalt dimensioneres
til at kunne klare en faktor N (større end 2) større belastning end
forventet maksimum?
Jeg er bange for at IT-folk generelt ikke skal stikke næsen for langt
frem hvad angår budgetter...
:-),