---

I forbindelse med mit arbejde som webmaster og progrmmør på nogle portaler,
har jeg flere gange været ude for at kunderne/brugerne bliver ved med ville
have kodet stadig mere detaljerede funktioner til løsning af alt mellem
himmel og jord, også ting, som enhver bruger selv burde kunne find ud af
og/eller som kun bruges så uhyre sjældent, at det nærmest er spild af tid at
lave.

Det er samtidig min erfaring, at jo flere "hjælpefunktioner" man laver af
den ene og anden art, jo mere kompliceret bliver portalen og jo flere
brugere vil have problemer med at finde rundt i den. De bliver forvirrede og
usikre over de mange muligheder, og kan/tør ikke agere rundt som bruger.
Samtidig er det en kendsgerning, at jo mere kompliceret koden bliver, jo
flere fejl vil der opstå og jo sværere vil det være at finde disse fejl.

Jeg mener altså, at der er noget som hedder OVERKODNING, nemlig det at lave
unødvendige funktioner, som gør koden unødvendig omfattende og kompliceret
og som reelt ikke er til gavn for brugerne. Når sådan overkodning laves, er
det som regel enten fordi programmøren synes det er så sjovt at kode, at han
bare bliver ved og ved.... eller også fordi at individuelle brugere foreslår
funktioner, som de alene (og ikke andre) har brug for, uden at tænke på at
der derved skabes for høj kompleksitet.

Dette problem har ikke kun noget med PHP at gøre, men drejer sig -
formentlig - om alle programsprog, og jeg vil godt høre andre som arbejder
med webprogrammering, hvad jeres erfaringer er med dette problem.

- Hvornår har man nået grænsen, hvor der ikke bør kodes mere?
- Hvor kan man læse tekst/teori om dette spørgsmål?
- Hvad er det engelske udtryk for Overkodning??

v.h.
Jakob

---

Jakob Munck skrev:

[snip]

Godt skrevet. Du påpeker noe som egentlig er ganske vesentlig men som
altfor få overser. Faktisk fører overkoding til at prosjekter aldri blir
lansert til tross for en meget stor base med kode.

> - Hvornår har man nået grænsen, hvor der ikke bør kodes mere?

Å definere noen grense er vanskelig, men jeg vil vi at enhver portal har
et gitt mål som bør defineres før man koder en eneste linje. Når målet
er nådd er det på tide å pusse på produktet uten å utvikle ekstra
funksjonalitet med mindre man ser at det faktisk er nødvendig for produktet.

> - Hvor kan man læse tekst/teori om dette spørgsmål?

Overkoding tror jeg er det vanskelig å finne litteratur om, men man kan
godt tenke det på en annen måte.

Utviklingsmetodikk definerer hvor mye/ofte man hører på kunde og
brukere, det forteller hvordan man skal utvikle osv. eXtreme Programming
(XP) og smidig utvikling (agile development) er nok den retningen du bør
titte. For tiden tester jeg litt smidig utvikling (med fiktiv kunde), og
synes det fungerer veldig godt.

eXtreme Programming finner man masse om hvis man titter på f.eks.
Amazon, men til smide metoder vil jeg kommer med min anbefaling:

<URL: http://pragmaticprogrammer.com/titles/pad/ >

Videre vil jeg anbefale en bok alle utviklere bør lese:

<URL: http://pragmaticprogrammer.com/ppbook/ >

> - Hvad er det engelske udtryk for Overkodning??

"Too much" ;)


Jeg husker ikke lenger navn på alle de danske gruppene, så jeg overlater
til noen andre å sette FUT.


--

Vennlig hilsen

Erlend Klakegg Bergheim

---

Erlend Klakegg Bergheim wrote:

> Overkoding tror jeg er det vanskelig å finne litteratur om, men man kan
> godt tenke det på en annen måte.

Al litteratur om agile development adresserer i princippet dette
problem, dog mere eller mindre implicit.

> Utviklingsmetodikk definerer hvor mye/ofte man hører på kunde og
> brukere, det forteller hvordan man skal utvikle osv. eXtreme Programming
> (XP) og smidig utvikling (agile development) er nok den retningen du bør
> titte. For tiden tester jeg litt smidig utvikling (med fiktiv kunde), og
> synes det fungerer veldig godt.
>
> eXtreme Programming finner man masse om hvis man titter på f.eks.
> Amazon, men til smide metoder vil jeg kommer med min anbefaling:

Netop XP ligger i høj grad op til, at man tager hele pakken (alle core
practices) eller ingenting. Det er selvfølgelig tilladt at hente
inspiration, men et præmis i grundtanken bag XP er, at man overgiver sig
fuldstændig til metoden.

Jeg ville kigge lidt bredere i feltet agile development. Tag f.eks. også
et kig på UP.

Følgende to bøger giver en rigtig god introduktion til agile development:

http://www.amazon.com/Agile-Iterative-Development-Managers-Guide/dp/0131111558/sr=8-2/qid=1161854709/ref=pd_bbs_sr_2/104-6701297-2610342?ie=UTF8&s=books

http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062/sr=8-1/qid=1161854709/ref=pd_bbs_sr_1/104-6701297-2610342?ie=UTF8&s=books

--
Peter Farsinsen
fornavn@efternavn.dk

---

Jakob Munck skrev:

> - Hvad er det engelske udtryk for Overkodning?

"Adding new features".

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

"Bertel Lund Hansen" <unospamo@lundhansen.dk> skrev i en meddelelse
news:45407d55$0$4158$ba624c82@nntp02.dk.telia.net...
> Jakob Munck skrev:
>
>> - Hvad er det engelske udtryk for Overkodning?
>
> "Adding new features".
>
> --


Bestemt nej. Så må det hedde "adding too many new features", det er jo det
som er hele pointen.

v.h.
Jakob




> Bertel
> http://bertel.lundhansen.dk/ http://fiduso.dk/

---

Jakob Munck skrev:

>> "Adding new features".

> Bestemt nej. Så må det hedde "adding too many new features", det er jo det
> som er hele pointen.

Min pointe er at de new features netop ofte er too much.

For en del år siden læste jeg en bog om it-sikkerhed. Forfatteren
som var ekspert på området, skrev at 90 % af programmørernes tid
som regel gik med det som de selv kaldte "adding new features".

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Jakob Munck skrev:
>
>>- Hvad er det engelske udtryk for Overkodning?
>
> "Adding new features".

Det er feature creep, du leder efter.

Også iblandt programmører kaldet creature feeb.

http://searchcio.techtarget.com/sDefinition/0,,sid19_gci860179,00.html

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Jakob Munck skrev:
> - Hvornår har man nået grænsen, hvor der ikke bør kodes mere?

Dette er nok et spørgsmål, som der findes mange forskellige svar på.
Så dette er bare mit besyv og min mening.

Når du ikke formår, at lave nye funktioner uden at gøre det meget
uoverskueligt har du nået grænsen. Dermed forstået at du må tage
brugerne med på råd, i måden som dine funktioner skal fremstilles.

Når du ikke længere kan fremstille dine funktioner på en overskuelig
måde, så er det på tide at arbejde på dit design og din fremstilling.
Hvis det stadigvæk er forvirrende, så har du nået dine designer-mæssige
grænser, og du bør arbejde på disse og din præsentation af siden i
stedet for nye ny funktionalitet ;)

Der skulle helst være en balance i designet og funktionaliten. Dermed
ikke forstået, at du skal have et "flottere" design - blot en lettere
navigation. Ligesom at jeg nok skal til at tage lidt flere dansk-timer,
så jeg kan forklare mig bedre ;)


--
Med venlig hilsen
Kasper Johansen

---

On Thu, 26 Oct 2006 05:59:06 +0200, "Jakob Munck"
<jm2_fjern_dette@webspeed.dk> wrote:

>I forbindelse med mit arbejde som webmaster og progrmmør på nogle portaler,
>har jeg flere gange været ude for at kunderne/brugerne bliver ved med ville
>have kodet stadig mere detaljerede funktioner til løsning af alt mellem
>himmel og jord, også ting, som enhver bruger selv burde kunne find ud af
>og/eller som kun bruges så uhyre sjældent, at det nærmest er spild af tid at
>lave.
>
>Det er samtidig min erfaring, at jo flere "hjælpefunktioner" man laver af
>den ene og anden art, jo mere kompliceret bliver portalen og jo flere
>brugere vil have problemer med at finde rundt i den. De bliver forvirrede og
>usikre over de mange muligheder, og kan/tør ikke agere rundt som bruger.
>Samtidig er det en kendsgerning, at jo mere kompliceret koden bliver, jo
>flere fejl vil der opstå og jo sværere vil det være at finde disse fejl.
>
>Jeg mener altså, at der er noget som hedder OVERKODNING, nemlig det at lave
>unødvendige funktioner, som gør koden unødvendig omfattende og kompliceret
>og som reelt ikke er til gavn for brugerne. Når sådan overkodning laves, er
>det som regel enten fordi programmøren synes det er så sjovt at kode, at han
>bare bliver ved og ved.... eller også fordi at individuelle brugere foreslår
>funktioner, som de alene (og ikke andre) har brug for, uden at tænke på at
>der derved skabes for høj kompleksitet.
>
>Dette problem har ikke kun noget med PHP at gøre, men drejer sig -
>formentlig - om alle programsprog, og jeg vil godt høre andre som arbejder
>med webprogrammering, hvad jeres erfaringer er med dette problem.
>
>- Hvornår har man nået grænsen, hvor der ikke bør kodes mere?
>- Hvor kan man læse tekst/teori om dette spørgsmål?
>- Hvad er det engelske udtryk for Overkodning??
>
>v.h.
>Jakob
>


Det handler vel mere om at få defineret opgaven inden man begynder at
programmere, herefter er nye features en ny opgave som enten kan
tilføjes i det eksisterende projekt, eller der skal påbegyndes et nyt
projekt med en ny kravspecifikation.

Overkodning kan der vel aldrig være tale om. Det er vel nærmest dig
som programmør der ikke har fået defineret opgaven korrekt
Sagt på en anden måde, at du ikke har fundet ud af hvad kunden vil
have inden du programmere.

Groft sagt kaster du dig ud i programmeringen inden du ved hvad du
skal lave. (målet ikke defineret)

Steen

---

S. Hansen wrote:

> Det handler vel mere om at få defineret opgaven inden man begynder at
> programmere, herefter er nye features en ny opgave som enten kan
> tilføjes i det eksisterende projekt, eller der skal påbegyndes et nyt
> projekt med en ny kravspecifikation.

Agile development (nævnt andetsteds i tråden) er bl.a. et opgør med
netop denne påstand. Tesen er, at forudgående kravspecificering ikke
forhindrer feature overflow eller unødvendige features - snarer
tværtimod, da kunden på forhånd ikke ved, hvad denne ønsker.
Undersøgelser har vist, at 45% af de tilgængelige features i systemer
udviklet efter traditionelle metoder (med en stærk forudgående
kravspecificering) kun sjældent eller aldrig anvendes. Inden for IID er
nye features altså ikke et nyt projekt, men blot stof for en
efterfølgende iteration.

> Overkodning kan der vel aldrig være tale om. Det er vel nærmest dig
> som programmør der ikke har fået defineret opgaven korrekt
> Sagt på en anden måde, at du ikke har fundet ud af hvad kunden vil
> have inden du programmere.

Der skal selvfølgelig være en overordnet vision for projektet, men jeg
tror ikke (uden meget praktisk erfaring at fundere det i) at en stor
kravspecifikation er svaret.

> Groft sagt kaster du dig ud i programmeringen inden du ved hvad du
> skal lave. (målet ikke defineret)

Go for it ;)

--
Peter Farsinsen
fornavn@efternavn.dk

---

On Thu, 26 Oct 2006 14:03:10 +0200, Peter Farsinsen
<fornavn@efternavn.dk> wrote:

>S. Hansen wrote:
>
>> Det handler vel mere om at få defineret opgaven inden man begynder at
>> programmere, herefter er nye features en ny opgave som enten kan
>> tilføjes i det eksisterende projekt, eller der skal påbegyndes et nyt
>> projekt med en ny kravspecifikation.
>
>Agile development (nævnt andetsteds i tråden) er bl.a. et opgør med
>netop denne påstand. Tesen er, at forudgående kravspecificering ikke
>forhindrer feature overflow eller unødvendige features - snarer
>tværtimod, da kunden på forhånd ikke ved, hvad denne ønsker.

Men det er vel også her den dygtige systemudvikler skiller sig ud. Han
kan få defineret hvad kunden ønsker sig inden opgaven sættes igang.
Og ja jeg ved godt det er nemmere sagt end gjort

>Undersøgelser har vist, at 45% af de tilgængelige features i systemer
>udviklet efter traditionelle metoder (med en stærk forudgående
>kravspecificering) kun sjældent eller aldrig anvendes. Inden for IID er
>nye features altså ikke et nyt projekt, men blot stof for en
>efterfølgende iteration.

Det er vel stadigvæk ikke systemudvikleren der skal bestemme hvad
brugeren ønsker sig, det skal bare klarlægges hvad brugeren ønsker
sig. og så er det irrelevant hvor meget eller lidt en enkelt features
bliver brugt, det er brugerens problem.

Ikke ligesom før i tiden hvor systemudvikleren udviklede det system
som han troede brugeren ville have, og brugeren måtte så bare leve med
dette

>
>Der skal selvfølgelig være en overordnet vision for projektet, men jeg
>tror ikke (uden meget praktisk erfaring at fundere det i) at en stor
>kravspecifikation er svaret.
>

Hvis du ikke ved hvilke krav der er til et system, hvornår ved du så
det er færdigt, og du kan få dine penge for systemet.

Steen

---

S. Hansen skrev:

> Det er vel stadigvæk ikke systemudvikleren der skal bestemme hvad
> brugeren ønsker sig, det skal bare klarlægges hvad brugeren ønsker
> sig. og så er det irrelevant hvor meget eller lidt en enkelt features
> bliver brugt, det er brugerens problem.

Det er ikke en ansvarlig udvikler der tager 1 mio. for en
monsteropgave efter kundens ønske hvis han ved at det kunne
klares for 1000 kr. med en times arbejde.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

On Thu, 26 Oct 2006 16:13:55 +0200, Bertel Lund Hansen
<unospamo@lundhansen.dk> wrote:

>S. Hansen skrev:
>
>> Det er vel stadigvæk ikke systemudvikleren der skal bestemme hvad
>> brugeren ønsker sig, det skal bare klarlægges hvad brugeren ønsker
>> sig. og så er det irrelevant hvor meget eller lidt en enkelt features
>> bliver brugt, det er brugerens problem.
>
>Det er ikke en ansvarlig udvikler der tager 1 mio. for en
>monsteropgave efter kundens ønske hvis han ved at det kunne
>klares for 1000 kr. med en times arbejde.

Det er stadigvæk kunden der bestemmer hvad kravene er, det er
systemudviklerens opgave at definere kundens krav, ikke at bestemme
kundens krav.

Systemudvikleren definere efterflg. prisen for den ønskede løsning,
som herefter kan barberes til den pris som kunden vil betale.

Steen

---

S. Hansen skrev:

> Det er stadigvæk kunden der bestemmer hvad kravene er, det er
> systemudviklerens opgave at definere kundens krav, ikke at bestemme
> kundens krav.

Jeg vil gerne have kunder der kommer igen.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

>
> Det handler vel mere om at få defineret opgaven inden man begynder at
> programmere, herefter er nye features en ny opgave som enten kan
> tilføjes i det eksisterende projekt, eller der skal påbegyndes et nyt
> projekt med en ny kravspecifikation.
>

Jeg har endnu aldrig mødt en kunde/bruger, som var i stand til at lave en
præcis kravspecifikation, og jeg ville heller ikke selv kunne lave den.
Kravene vokser jo, når man har en velfungerende applikation og jo mere den
kan, jo flere ideer kommer der gerne til hvad den "også" burde kunne. Derfor
ser man f.eks. i dag en MS-Office, som er så overbroderet med funktioner, at
de fleste almindelige brugere ikke kan finde du af det. Og tilsvarende kan
webapplikationer dø - eller miste i værdi - p.g.a. overkodning.


> Overkodning kan der vel aldrig være tale om. Det er vel nærmest dig
> som programmør der ikke har fået defineret opgaven korrekt

En kodeopgave kan ALDRIG defineres præcis på forhånd og hvis man arbejder
med for præcis en kravspecifikation, så vil man finde ud af, at det tager
LÆNGERE tid at lave den specifikation, end det gør at kode det i praksis.
Derfor vælger man at kode det i praksis, så brugeren kan se, hvad der er
tale om.

UML var en fiasko, og det er andre abstrakte ikke-funktionelle
beskrivelsesmetoder også. De duer bare ikke, undtagen til at imponere naive
købere og til at gøre applikationerne dyrere. Men så har programmøren
selvfølgelig en genial undskyldning for ikke at lave det nødvendige, fordi
det "ikke står i UML-diagrammet".


v.h.
Jakob

---

Jakob Munck wrote:
>>Det handler vel mere om at få defineret opgaven inden man begynder at
>>programmere, herefter er nye features en ny opgave som enten kan
>>tilføjes i det eksisterende projekt, eller der skal påbegyndes et nyt
>>projekt med en ny kravspecifikation.
>
> Jeg har endnu aldrig mødt en kunde/bruger, som var i stand til at lave en
> præcis kravspecifikation, og jeg ville heller ikke selv kunne lave den.

Jeg har leveret nogle projekter hvor /alt/ var specificeret på forhånd
og der ikke blev tilføjet noget undervejs. Det er i høj grad muligt, men
kræver en masse forarbejde.

>>Overkodning kan der vel aldrig være tale om. Det er vel nærmest dig
>>som programmør der ikke har fået defineret opgaven korrekt
>
> En kodeopgave kan ALDRIG defineres præcis på forhånd og hvis man arbejder
> med for præcis en kravspecifikation, så vil man finde ud af, at det tager
> LÆNGERE tid at lave den specifikation, end det gør at kode det i praksis.
> Derfor vælger man at kode det i praksis, så brugeren kan se, hvad der er
> tale om.

Beklager. Det passer bare ikke. Nrå det gælder små og mellemstore
opgaver kan man godt specificere alt på forhånd. Det er kun et spørgsmål
om at have en dygtig teknisk projektleder, som får det gjort før
projektet starter.

> UML var en fiasko, og det er andre abstrakte ikke-funktionelle
> beskrivelsesmetoder også. De duer bare ikke, undtagen til at imponere naive
> købere og til at gøre applikationerne dyrere.

Enig. Jeg har sjældent fået noget ud af UML, andet end lige use-cases og
klassediagrammer. Men der findes sikkert projekter hvor UML er et godt
værktøj.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Jakob Munck wrote:

> Jeg har endnu aldrig mødt en kunde/bruger, som var i stand til at lave en
> præcis kravspecifikation, og jeg ville heller ikke selv kunne lave den.

Så har du ganske givet ikke været ansat i virksomheder som har store (og
mere eller mindre velfungerende) projekterings-afdelinger mv.

I øvrigt er der også mange måder at definere sine krav på - nogle gange
kan de minutiøst beskrives fordi det er vigtigt at noget fungere på en
helt specifik måde i forhold til brugerne eller andre systemer der skal
benytte funktionaliteten - andre gange kan det specificeres mere løst og
lade det være op til udvikleren at definere hvad han/hun synes er smart.

Det er omvendt i min verden lidt forenklet at tro at man kan aflevere en
kravspecifikation og ikke skal (re-)vurdere projektets fremskridt og
løsning løbende - kontinuerlig iteration omkring et projekt er i dagens
dynamiske verden meget vigtig og en ofte meget overset del af et projekt.

Krav - interne som eksterne - ændres løbende og den verden vi befinder
os i ændres konstant - bl.a. lovgivningskrav osv. - derfor vil jeg mene
det er dårlig projektledelse at tro at man kan aflevere x antal stykker
papir og derefter først kigge på opgaven igen når systemet er afleveret.

En stor del af projektledelse er jo netop at udspecificere, afdække og
klarlægge kravene til et system og få dem defineret skarpt nok til at
man kan sætte udviklerne i gang med at udføre implemenationen af disse.

Og derefter vurderes nye features, rettelser, tilretninger, bugs osv.
løbende og køres ind i projektet efterhånden som det er hensigtsmæssigt.

De fleste større projekter bør dog altid nå frem til et såkaldt
feature-freeze hvor man stopper for udviklingen af nye features og
koncentrere sig om bug-rettelser og afpudsning af den eksisterende
applikation - dette er oftest frem til en større betatest af systemet og
frem til accept-testen af at systemet lever op til de krav der blev
stillet i den indgåede aftale om levering af systemet via den stillede
kravspecifikation.

Nye features vurderes herefter af projektledelsen i et antal grader af
"nice to have", "need to have", "unødvendigt", osv. i forhold til næste
version/opdatering af applikationen såfremt en sådan er planlagt.


Men at påstå at et projekt ikke kan præcist defineres og afgrænses fra
starten synes jeg nu er forkert - det kan sagtens lade sig gøre - og som
systemudvikler må jeg da også indrømme at man må indstille sig på at
kravspecifikationer er levende dynamiske dokumenter der ganske givet
revideres flere gange i løbet af udviklings og implemantationsfasen af
en applikation.

Har man ikke forståelse for dette tror jeg ikke man overlever længe som
udvikler i nutidens udviklingsbranche.

Der er en grund til at man ofte siger at projektopstart,
projektdokumentation og analyse bør tage mindst 20-25% af tiden brugt på
den samlede projektopgave.


--
Med venlig hilsen
Geert Lund,
www.GLD.dk

---

Jakob Munck wrote:
> I forbindelse med mit arbejde som webmaster og progrmmør på nogle portaler,
> har jeg flere gange været ude for at kunderne/brugerne bliver ved med ville
> have kodet stadig mere detaljerede funktioner til løsning af alt mellem
> himmel og jord, også ting, som enhver bruger selv burde kunne find ud af
> og/eller som kun bruges så uhyre sjældent, at det nærmest er spild af tid at
> lave.
>
> Det er samtidig min erfaring, at jo flere "hjælpefunktioner" man laver af
> den ene og anden art, jo mere kompliceret bliver portalen og jo flere
> brugere vil have problemer med at finde rundt i den. De bliver forvirrede og
> usikre over de mange muligheder, og kan/tør ikke agere rundt som bruger.
> Samtidig er det en kendsgerning, at jo mere kompliceret koden bliver, jo
> flere fejl vil der opstå og jo sværere vil det være at finde disse fejl.
>
> Jeg mener altså, at der er noget som hedder OVERKODNING, nemlig det at lave
> unødvendige funktioner, som gør koden unødvendig omfattende og kompliceret
> og som reelt ikke er til gavn for brugerne. Når sådan overkodning laves, er
> det som regel enten fordi programmøren synes det er så sjovt at kode, at han
> bare bliver ved og ved.... eller også fordi at individuelle brugere foreslår
> funktioner, som de alene (og ikke andre) har brug for, uden at tænke på at
> der derved skabes for høj kompleksitet.
>
> Dette problem har ikke kun noget med PHP at gøre, men drejer sig -
> formentlig - om alle programsprog, og jeg vil godt høre andre som arbejder
> med webprogrammering, hvad jeres erfaringer er med dette problem.
>
> - Hvornår har man nået grænsen, hvor der ikke bør kodes mere?
> - Hvor kan man læse tekst/teori om dette spørgsmål?

Systemanalyse og design. Helst objektorinteret. Forkortes OOA & OOD.

> - Hvad er det engelske udtryk for Overkodning??

Begrebet findes ikke på dansk, så jeg ved ikke hvad det skulle hedde
på engelsk.

Dine problemer med overflødige funktioner er en konsekvens af manglende
struktur. Hvis der er en god og konsistent struktur, er der også plads
til mange flere funktioner (eller helst klasser), da de finder deres
naturlige plads i et velstruktureret pakkehieraki.

Udviklermiljøet omkring PHP er desværre frontløber for slamkode, der er
præget af mange programmører, som ikke har lært at lave ordenltigt
design, så de kan strukturere deres kode ordentligt. Siden du arbejder
meget med PHP, vil du også blive præget af den tankegang.

Mit tip er at du er klar til et andet sprog. Tag f. eks. et kig på Java
(eller måske endda perl). Når du har rodet med det i nogle år, kan du
vende tilbage til PHP, for så ved du mere om hvordan man kan strukturere
sin kode på en pæn måde. Supplér med litteratur om objektorienteret design.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

>
>> - Hvad er det engelske udtryk for Overkodning??
>
> Begrebet findes ikke på dansk, så jeg ved ikke hvad det skulle hedde på
> engelsk.
>

Jo, der findes et begreb på engelsk for denne normale og velkendte
problematik. Jeg har læst det, men desværre glemt hvad det hed.


> Dine problemer med overflødige funktioner er en konsekvens af manglende
> struktur. Hvis der er en god og konsistent struktur, er der også plads til
> mange flere funktioner (eller helst klasser), da de finder deres naturlige
> plads i et velstruktureret pakkehieraki.
>

Forkert. Problemet er ikke at jeg ikke kan finde rundt i koden, men at
brugerne ikke kan finde rundt i portalen, da der er alt for mange
muligheder, som de ikke kan overskue og ikke vil/gider/tør afprøve.



> Udviklermiljøet omkring PHP er desværre frontløber for slamkode, der er
> præget af mange programmører, som ikke har lært at lave ordenltigt design,
> så de kan strukturere deres kode ordentligt. Siden du arbejder meget med
> PHP, vil du også blive præget af den tankegang.
>

Man kan skam også programmere "objektorienteret" i PHP, hvis man tror at det
gør livet lettere.


> Mit tip er at du er klar til et andet sprog. Tag f. eks. et kig på Java
> (eller måske endda perl). Når du har rodet med det i nogle år, kan du
> vende tilbage til PHP, for så ved du mere om hvordan man kan strukturere
> sin kode på en pæn måde. Supplér med litteratur om objektorienteret
> design.
>

Hvis jeg havde mere tid ville jeg måske prøve et andet sprog, men det ville
jo intet ændre i kundernes evige krav om flere funktioner af den ene eller
anden art. Uanset hvilket sprog man koder i, ender det hele ude i en
browser, og der er nu engang ikke mere plads i denne, end der er på skærmen.
Det kan Java ikke lave om på.

I øvrigt hader jeg objektorienteret kodning, og mener at det er noget skidt,
som man skal holde sig fra (!!).

v.h.
Jakob







> Mvh. Michael.
> --
> Which is more dangerous? TV guided missiles or TV guided families?
> I am less likely to answer usenet postings by anonymous authors.
> Visit my home page at http://michael.zedeler.dk/

---

Jakob Munck skrev:

> I øvrigt hader jeg objektorienteret kodning, og mener at det er noget skidt,
> som man skal holde sig fra (!!).

Det lyder som om du ikke ved hvordan det fungerer når det bliver
brugt rigtigt.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

>> I øvrigt hader jeg objektorienteret kodning, og mener at det er noget
>> skidt,
>> som man skal holde sig fra (!!).
>
> Det lyder som om du ikke ved hvordan det fungerer når det bliver
> brugt rigtigt.
>

Denne diskussion er lang og omfattende, men jeg har haft fornøjelsen af at
kunne følge mennesker, som kodede "objektorienteret" og som var rigtig gode
til det. Ikke desto mindre arbejdede de langsommere og mere usikkert end jeg
selv gør det, når jeg løser tilsvarende opgaver. Objektorientering er -
efter min mening - en modestrømning, som man gør klogt i at holde sig fra.
Men dette er - det indrømmer jeg - min personlige mening, og dette er nok
ikke det rette sted at lave en større diskussion af dette emne. Enhver må jo
finde lykken på sin egen måde, også når det gælder kodning.

Men det at man arbejder med klassisk ikke-objektorienteret PHP betyder jo
ikke, at man behøver at bekende sig til den deklatoriske
(konstruktivistiske, deduktive) kodemodel. Det gør jeg ikke. Jeg går ind for
samtale, dialog og dialektik og derfor tror jeg på en dialogisk kodemodel.
Den har jeg nu lært at man kan kalde for agile-modellen.

v.h.
Jakob



> --
> Bertel
> http://bertel.lundhansen.dk/ http://fiduso.dk/

---

Jakob Munck wrote:
>>>I øvrigt hader jeg objektorienteret kodning, og mener at det er noget
>>>skidt,
>>>som man skal holde sig fra (!!).
>>
>>Det lyder som om du ikke ved hvordan det fungerer når det bliver
>>brugt rigtigt.
>
> Denne diskussion er lang og omfattende, men jeg har haft fornøjelsen af at
> kunne følge mennesker, som kodede "objektorienteret" og som var rigtig gode
> til det. Ikke desto mindre arbejdede de langsommere og mere usikkert end jeg
> selv gør det, når jeg løser tilsvarende opgaver.

Det er altid muligt at pege på en udvikler, der er dårligere end en
selv. Det omvendte kræver noget mere mod

> Men det at man arbejder med klassisk ikke-objektorienteret PHP betyder jo
> ikke, at man behøver at bekende sig til den deklatoriske
> (konstruktivistiske, deduktive) kodemodel.

Hvad i alverden mener du med "deklaratoriske kodemodel"?

> Det gør jeg ikke. Jeg går ind for
> samtale, dialog og dialektik og derfor tror jeg på en dialogisk kodemodel.

Der var endnu et begreb, jeg ikke har hørt om før. Hvad betyder
"dialogisk kodemodel"?

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

>
> Det er altid muligt at pege på en udvikler, der er dårligere end en selv.
> Det omvendte kræver noget mere mod
>

Men i det nævnte tilfælde var den person jeg sammenlignede mig med langt
dygtiger end jeg selv. Alligevel lavede han langsommere og mere usikre
løsninger end jeg selv kunne, fordi han brugte en dårlig metode, som kaldes
for "objektorienteret", i øvrigt uden at dette ord har noget som helst
seriøst indhold andet end markedsføringsgas. Efter min mening, altså.


>> Men det at man arbejder med klassisk ikke-objektorienteret PHP betyder jo
>> ikke, at man behøver at bekende sig til den deklatoriske
>> (konstruktivistiske, deduktive) kodemodel.
>
> Hvad i alverden mener du med "deklaratoriske kodemodel"?
>

Det er den hvor man tror at man kan planlægge alting i et stort skema, give
dette til en programmør og derefter få en perfekt applikation. Det kan man
ikke, og folk der hævder det modsatte taler - efter min mening - usandt. Der
er meget stor forskel på at bygge et hus og at lave et softwareprodukt. I
det sidste har brugerne nemlig stort set ikke sprog til at beskrive, hvad de
ønsker og derfor er planlægning kun delvis mulig. Man kan godt planlægge
100%, men så er man også 100% sikker på, at planen ikke vil virke. Dette
gælder både i softwareudvikling, i militær planlægning og i ægteskabet.
Deklatorisk planlægning = dumhed (min mening).


>> Det gør jeg ikke. Jeg går ind for samtale, dialog og dialektik og derfor
>> tror jeg på en dialogisk kodemodel.
>
> Der var endnu et begreb, jeg ikke har hørt om før. Hvad betyder "dialogisk
> kodemodel"?
>

Dialogo = samtale (græsk). En dialogisk kodemodel bygger på den antagelse,
at programmøren laver fejl og at rekvirenten ikke præcis ved, hvad han vil
og ikke i tilstrækkelig grad er i stand til at forklare det han ønsker. Der
er altså plads til fejl og til at man udvikler applikationen gradvis og at
man løbende inddrager nye erfaringer fra brugerne. Det er det vi dyrker her
i nyhedsgruppen.


v.h.
Jakob



> Mvh. Michael.
> --
> Which is more dangerous? TV guided missiles or TV guided families?
> I am less likely to answer usenet postings by anonymous authors.
> Visit my home page at http://michael.zedeler.dk/

---

Jakob Munck skrev:

> for "objektorienteret", i øvrigt uden at dette ord har noget som helst
> seriøst indhold andet end markedsføringsgas. Efter min mening, altså.

Det kan man ikke have en mening om. Det har et seriøst indhold.
Det kan man vide noget om eller ikke, og det kan man lide eller
ikke. Men man kan ikke bare mene et faktum væk.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Jakob Munck skrev:
>
>>for "objektorienteret", i øvrigt uden at dette ord har noget som helst
>>seriøst indhold andet end markedsføringsgas. Efter min mening, altså.
>
> Det kan man ikke have en mening om. Det har et seriøst indhold.
> Det kan man vide noget om eller ikke, og det kan man lide eller
> ikke. Men man kan ikke bare mene et faktum væk.

Det overså jeg altså også. Objektorienteret programmering er en anden
måde at udvikle på og ikke salgsgas. Til Jakob kan jeg kun sige: hvorfor
ikke sætte dig ind i hvad det er, før du kritiserer det?

Iøvrigt skulle jeg hilse og sige at det værste projekt, jeg nogensinde
har arbejdet på, var at videreudvikle en applikation skrevet i Java af
en som ikke vidste hvad objektorienteret programmering var. Var det ikke
fordi at kunden var desperat og betalte uhyrlige summer for det, var jeg
løbet skrigende væk. I den periode følte jeg mig mere som kloakarbejder
end systemudvikler.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Jakob Munck wrote:
>>Det er altid muligt at pege på en udvikler, der er dårligere end en selv.
>>Det omvendte kræver noget mere mod
>
> Men i det nævnte tilfælde var den person jeg sammenlignede mig med langt
> dygtiger end jeg selv. Alligevel lavede han langsommere og mere usikre
> løsninger end jeg selv kunne, fordi han brugte en dårlig metode, som kaldes
> for "objektorienteret", i øvrigt uden at dette ord har noget som helst
> seriøst indhold andet end markedsføringsgas. Efter min mening, altså.

Så han var dygtigere end dig, men var langsommere og lavede kode af
dårligere kvalitet? Det er vist en helt ny definition af "dygtigere".

>>>Men det at man arbejder med klassisk ikke-objektorienteret PHP betyder jo
>>>ikke, at man behøver at bekende sig til den deklatoriske
>>>(konstruktivistiske, deduktive) kodemodel.
>>
>>Hvad i alverden mener du med "deklaratoriske kodemodel"?
>
> Det er den hvor man tror at man kan planlægge alting i et stort skema, give
> dette til en programmør og derefter få en perfekt applikation. Det kan man
> ikke, og folk der hævder det modsatte taler - efter min mening - usandt. Der
> er meget stor forskel på at bygge et hus og at lave et softwareprodukt. I
> det sidste har brugerne nemlig stort set ikke sprog til at beskrive, hvad de
> ønsker og derfor er planlægning kun delvis mulig. Man kan godt planlægge
> 100%, men så er man også 100% sikker på, at planen ikke vil virke. Dette
> gælder både i softwareudvikling, i militær planlægning og i ægteskabet.
> Deklatorisk planlægning = dumhed (min mening).

Jeg er et eksempel på at det godt kan lade sig gøre. Det virker kun i
mindre og mellemstore projekter, men der virker det over al forventning.
Tricket består i at give kunden nogle værktøjer, som de har nemmere ved
at forholde sig til, end kravspecifikationer på mange hundrede sider med
tilhørende UML-diagrammer. Det holder ikke.

Normalt bruger jeg blot skærmbilleder fra en mock-up, hvor man kan se
hele applikationen. Den gennemgår man så igennem et par eller tre
heldags-sessioner med kunden, hvorefter alt bliver låst fast og
projektet sættes igang.

Selvfølgelig kan man komme må ekstra ting undervejs, men der dukker
langt mindre rettelser op, når først man har været sådan et forløb igennem.

>>>Det gør jeg ikke. Jeg går ind for samtale, dialog og dialektik og derfor
>>>tror jeg på en dialogisk kodemodel.
>>
>>Der var endnu et begreb, jeg ikke har hørt om før. Hvad betyder "dialogisk
>>kodemodel"?
>
> Dialogo = samtale (græsk). En dialogisk kodemodel bygger på den antagelse,
> at programmøren laver fejl og at rekvirenten ikke præcis ved, hvad han vil
> og ikke i tilstrækkelig grad er i stand til at forklare det han ønsker. Der
> er altså plads til fejl og til at man udvikler applikationen gradvis og at
> man løbende inddrager nye erfaringer fra brugerne.

Det bliver jo hurtigt til: "vi ved jo ikke hvad slutresultatet bliver,
så hvorfor interessere sig for det nu?", hvilket er fordyrende for
projektet. Men hvis din timeløn er lav og kundernes tålmodighed er høj,
er det jo ikke noget problem.

> Det er det vi dyrker her i nyhedsgruppen.

Aner ikke hvad du snakker om.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Jakob Munck skrev:

> Denne diskussion er lang og omfattende, men jeg har haft fornøjelsen af at
> kunne følge mennesker, som kodede "objektorienteret" og som var rigtig gode
> til det. Ikke desto mindre arbejdede de langsommere og mere usikkert end jeg
> selv gør det, når jeg løser tilsvarende opgaver.

Nogle ting kodes lettest objektorienteret, andre gør ikke. Jeg er
selvlært og er vokset op med programmering før der var nogen der
havde tænkt på OOP, så jeg får det nok aldrig ind som rutine, men
ikke desto mindre er det en fornøjelse i et Pythonprogram jeg har
lavet at jeg kun behøver tilføje én kodelinje, så har jeg
automatisk FTP fra min HD til et nyt webhotel. Jeg nedarver hele
svineriet fra et klassehierarki.

> Objektorientering er - efter min mening - en modestrømning, som
> man gør klogt i at holde sig fra.

Man gør klogt i ikke at afvise en fornuftigt tankesæt blot fordi
det har været helt vildt hypet.

> Men dette er - det indrømmer jeg - min personlige mening, og dette er nok
> ikke det rette sted at lave en større diskussion af dette emne. Enhver må jo
> finde lykken på sin egen måde, også når det gælder kodning.

Jo flere sprog man kender, og jo flere programmeringsmetoder man
kender, jo nemmere kan man overskue en opgave og finde den rette
løsning.

> Men det at man arbejder med klassisk ikke-objektorienteret PHP
> betyder jo ikke, at man behøver at bekende sig til den
> deklatoriske (konstruktivistiske, deduktive) kodemodel. Det
> gør jeg ikke. Jeg går ind for samtale, dialog og dialektik og
> derfor tror jeg på en dialogisk kodemodel. Den har jeg nu lært
> at man kan kalde for agile-modellen.

Det har ikke spor med OOP eller det modsatte at gøre (bortset fra
at jeg heller ikke kender de der hypegloser du slynger om dig
med).

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Jakob Munck wrote:

> Den har jeg nu lært at man kan kalde for agile-modellen.

Nu sludrer du altså. Agile development er en fællesbetegnelse for en
række (primært iterative inkremeltelle) systemudviklingsmetoder, så som
XP, UP, Scrum og crystal methods, der alle har afsæt i Agile Manifesto
(agilemanifesto.org).

"Agile-modellen" er langt mere end blot en model. Hvis du vil påråbe dig
at udvikle agilt, vil jeg foreslå, at du læser en af de bøger, jeg har
linket til tidliger. Desværre må jeg skuffe dig - de er spækket med OOP ;)

--
Peter Farsinsen
fornavn@efternavn.dk

---

>
>> Den har jeg nu lært at man kan kalde for agile-modellen.
>
> Nu sludrer du altså. Agile development er en fællesbetegnelse for en række
> (primært iterative inkremeltelle) systemudviklingsmetoder, så som XP, UP,
> Scrum og crystal methods, der alle har afsæt i Agile Manifesto
> (agilemanifesto.org).
>
> "Agile-modellen" er langt mere end blot en model. Hvis du vil påråbe dig
> at udvikle agilt, vil jeg foreslå, at du læser en af de bøger, jeg har
> linket til tidliger. Desværre må jeg skuffe dig - de er spækket med OOP ;)
>

Agile (af mig kaldet dialogisk udvikling) har intet med objekt eller
funktionsorienteret kodning at gøre, helt rigtigt. Det er blot et tilfælde
at vi her har fået blandet de to størrelser sammen. Uanset om man er til
objekt- eller funktionsorienteret kodning, så er Agile det helt rigtige
udviklingssyn, efter min mening. Jeg kendte bare ikke dette navn før.

Læs:

http://agilemanifesto.org/

v.h.
Jakob




> --
> Peter Farsinsen
> fornavn@efternavn.dk

---

Jakob Munck wrote:
>>>- Hvad er det engelske udtryk for Overkodning??
>>
>> Begrebet findes ikke på dansk, så jeg ved ikke hvad det skulle hedde på
>>engelsk.
>
> Jo, der findes et begreb på engelsk for denne normale og velkendte
> problematik. Jeg har læst det, men desværre glemt hvad det hed.

Der findes et begreb kaldet "overloading", men det er noget helt andet.

>>Dine problemer med overflødige funktioner er en konsekvens af manglende
>>struktur. Hvis der er en god og konsistent struktur, er der også plads til
>>mange flere funktioner (eller helst klasser), da de finder deres naturlige
>>plads i et velstruktureret pakkehieraki.
>
> Forkert. Problemet er ikke at jeg ikke kan finde rundt i koden, men at
> brugerne ikke kan finde rundt i portalen, da der er alt for mange
> muligheder, som de ikke kan overskue og ikke vil/gider/tør afprøve.

Det er bare dårligt design.

>>Udviklermiljøet omkring PHP er desværre frontløber for slamkode, der er
>>præget af mange programmører, som ikke har lært at lave ordenltigt design,
>>så de kan strukturere deres kode ordentligt. Siden du arbejder meget med
>>PHP, vil du også blive præget af den tankegang.
>
> Man kan skam også programmere "objektorienteret" i PHP, hvis man tror at det
> gør livet lettere.

Ja. Men det er kun nu ved at blive udbredt.

>>Mit tip er at du er klar til et andet sprog. Tag f. eks. et kig på Java
>>(eller måske endda perl). Når du har rodet med det i nogle år, kan du
>>vende tilbage til PHP, for så ved du mere om hvordan man kan strukturere
>>sin kode på en pæn måde. Supplér med litteratur om objektorienteret
>>design.
>
> Hvis jeg havde mere tid ville jeg måske prøve et andet sprog, men det ville
> jo intet ændre i kundernes evige krav om flere funktioner af den ene eller
> anden art. Uanset hvilket sprog man koder i, ender det hele ude i en
> browser, og der er nu engang ikke mere plads i denne, end der er på skærmen.
> Det kan Java ikke lave om på.

Enig. Hvis problemet er "feature creep" - at man bliver ved med at
stille nye krav til systemet - og måske også ud over hvad der er teknisk
muligt (som i "nej det er ikke muligt at vise alle siderne fra
telefonbogen på en enkelt skærmside), så er det ikke teknologien, den er
gal med.

> I øvrigt hader jeg objektorienteret kodning, og mener at det er noget skidt,
> som man skal holde sig fra (!!).

Fint. Så meget desto mere vil jeg opfordre dig til at lære det.

Hvis du partout vil undgå det, så find nogle bøger om struktureret
analyse og design. Det er håbløst umoderne og de fleste vil nok synes at
du er lidt mærkelig, men det er en af måderne man kan lave pæne systemer
uden objekter.

I mine øjne mener jeg at du snyder dig selv for at udvikle dine evner,
hvis du undgår at lære om OOP. Det er idag så vigtigt at det er ekstremt
svært at undgå, hvis man vil leve af at programmere.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

>
> I mine øjne mener jeg at du snyder dig selv for at udvikle dine evner,
> hvis du undgår at lære om OOP. Det er idag så vigtigt at det er ekstremt
> svært at undgå, hvis man vil leve af at programmere.
>

Det skal jeg heldigvis heller ikke. Jeg er - og forbliver - kun en flittig
amatør, som dog har et par faste kunder, som betaler for mine ydelser. Men
desværre stiller de for store krav til produktet og til min tid, set i
forhold til det, som de vil betale for det. Og det er jeg utilfreds med.

v.h.
Jakob




> Mvh. Michael.
> --
> Which is more dangerous? TV guided missiles or TV guided families?
> I am less likely to answer usenet postings by anonymous authors.
> Visit my home page at http://michael.zedeler.dk/

---

Jakob Munck wrote:
>>I mine øjne mener jeg at du snyder dig selv for at udvikle dine evner,
>>hvis du undgår at lære om OOP. Det er idag så vigtigt at det er ekstremt
>>svært at undgå, hvis man vil leve af at programmere.
>
> Det skal jeg heldigvis heller ikke. Jeg er - og forbliver - kun en flittig
> amatør, som dog har et par faste kunder, som betaler for mine ydelser. Men
> desværre stiller de for store krav til produktet og til min tid, set i
> forhold til det, som de vil betale for det. Og det er jeg utilfreds med.

Jeg tror du vil få mest ud af at bruge tid på at lære lidt om teknisk
projektledelse.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

On Thu, 26 Oct 2006 20:06:46 +0200, "Jakob Munck"
<jm2_fjern_dette@webspeed.dk> wrote:

>Jo, der findes et begreb på engelsk for denne normale og velkendte
>problematik. Jeg har læst det, men desværre glemt hvad det hed.

Bloatware måske.

>Forkert. Problemet er ikke at jeg ikke kan finde rundt i koden, men at
>brugerne ikke kan finde rundt i portalen, da der er alt for mange
>muligheder, som de ikke kan overskue og ikke vil/gider/tør afprøve.

Nu kan portaler jo også være mere eller mindre brugervenlige, jeg tror
godt du kan presse en del funktioner ind i en portal hvis de er
placeret de rigtige steder, men ja, det handler også om at begrænse
sig.

Nu siger du at du har flere kunder, og jeg vil så gå ud fra at du har
et eller andet system du bruger til dine kunder og i dét har problemet
med bloat.

Dér handler det jo nok meget om at du skal lave muligheden for at man
kan slå funktionalitet til/fra, alt efter hvilket behov kunden har, og
endnu bedre flytte rundt på de forskellige ting, så de fremtræder der
hvor det er logisk, alt efter kontekst.

>Man kan skam også programmere "objektorienteret" i PHP, hvis man tror at det
>gør livet lettere.

Efter min erfaring kan man ihvertfald gøre livet lettere ved, også i
PHP, at bruge flere af principperne indenfor objektorienteret
programmering.

>Hvis jeg havde mere tid ville jeg måske prøve et andet sprog, men det ville
>jo intet ændre i kundernes evige krav om flere funktioner af den ene eller
>anden art. Uanset hvilket sprog man koder i, ender det hele ude i en
>browser, og der er nu engang ikke mere plads i denne, end der er på skærmen.
>Det kan Java ikke lave om på.

Bloatware er selvfølgelig et generelt problem, men efter min mening
kan det næsten altid løses ved at omstrukturere på sit webdesign/GUI.

Har du et konkret eksempel på et af dine portaler der kan for meget og
er for uoverskueligt for dine brugere?

>I øvrigt hader jeg objektorienteret kodning, og mener at det er noget skidt,
>som man skal holde sig fra (!!).

Det var da noget af en mening, hvad bygger du den på? Og hvad mener du
alternativet er?

--
Med venlig hilsen,
Martin Mouritzen.
http://www.siteloom.dk

---

>
> Det var da noget af en mening, hvad bygger du den på? Og hvad mener du
> alternativet er?
>

Nej, jeg slutter nu, ellers kommer det for langt ud.

Tak for debatten :)

v.h.
Jakob




> --
> Med venlig hilsen,
> Martin Mouritzen.
> http://www.siteloom.dk

---

"Jakob Munck" <jm2_fjern_dette@webspeed.dk> writes:

> - Hvad er det engelske udtryk for Overkodning??

Creeping featurism.

--
// Wegge
Min begrundelse for at betragte Arne Wilstrup som en paphat:
<http://wiki.wegge.dk/Usenet_personligheder>
Bruger du den gratis spamfighther ser jeg kun dine indlæg *EN* gang.

---

"Anders Wegge Jakobsen" <wegge@obelix.wegge.dk> skrev i en meddelelse
news:m3k62mzyd3.fsf@obelix.wegge.dk...
> "Jakob Munck" <jm2_fjern_dette@webspeed.dk> writes:
>
>> - Hvad er det engelske udtryk for Overkodning??
>
> Creeping featurism.
>
> --

Bingo, det var begrebet. Tak for det. Læs her:

http://en.wikipedia.org/wiki/Creeping_featurism


v.h.
Jakob



> // Wegge
> Min begrundelse for at betragte Arne Wilstrup som en paphat:
> <http://wiki.wegge.dk/Usenet_personligheder>
> Bruger du den gratis spamfighther ser jeg kun dine indlæg *EN* gang.

---

Jakob Munck wrote:
> I forbindelse med mit arbejde som webmaster og progrmmør på nogle portaler,
> har jeg flere gange været ude for at kunderne/brugerne bliver ved med ville
> have kodet stadig mere detaljerede funktioner til løsning af alt mellem
> himmel og jord, også ting, som enhver bruger selv burde kunne find ud af
> og/eller som kun bruges så uhyre sjældent, at det nærmest er spild af tid at
> lave.

Nu er det jo næppe alle dine kunder, der kan finde ud af at kode vel :)

Jeg er netop igang med en version 3 af en webshop, og denne gang er jeg
begyndt at omskrive det meste af koden. Meget af den kode jeg brugte i
version 1 er "oldnordisk" selvom det blev lavet for 1½ år siden. Så må
man indrømme at jeg har lært en hel del siden, og jeg nærmest griner
hvergang jeg for omskrevet nogle klasser/funktioner/etc.

I de 1½ år, er der en hel del features som er hobet sig om, som jeg
mente ville være vanskelige / tage for langtid at indføre i systemet i
den nuværende form.

Og jeg må give dig ret i at nogle af tingene er avanceret ting, som kun
skulle bruges til 1 kunde, men her mener jeg faktisk at de er disse
opgaver/features der er de sjoveste at lave, fordi det er noget specielt.

> Det er samtidig min erfaring, at jo flere "hjælpefunktioner" man laver af
> den ene og anden art, jo mere kompliceret bliver portalen og jo flere
> brugere vil have problemer med at finde rundt i den. De bliver forvirrede og
> usikre over de mange muligheder, og kan/tør ikke agere rundt som bruger.
> Samtidig er det en kendsgerning, at jo mere kompliceret koden bliver, jo
> flere fejl vil der opstå og jo sværere vil det være at finde disse fejl.

Enig!
Her gør jeg så det at jeg starter med at fjerne alle funktioner, også
har jeg en dialog med kunden om kundens ønsker, og disse funktioner slår
jeg så til. Så bliver kunden så sat ind i disse ting, og intet andet.

Kunden har dog så muligheden for selv at slå ekstra funktioner til - Dog
er det faktisk ret sjældent at kunder går ind og gør dette. Ikke fordi
det ikk er nemt, men fordi de nok enten ikke har tid, eller lyst.

Da version 2 blev færdig, der satte jeg en "ikke computer nørd" (med
stort IKKE) til at udforske de mest benyttede funktioner - Dengang
fandtes der hverken manual eller noget som helst til. Jeg sagde bare til
ham at "du skal åbne en webshop med produkter osv osv." - 2 dage efter,
var det hele så overstået, og jeg havde ikke hjulpet ham, men han havde
sørme lagt omkring 100 produkter og 600 varianter i webshoppen, slettet
og redigeret dem en hel del gange.

Samt oprettet en masse brugerdefineret sider, med både link sektion,
nyheds sektion, gæstebog sektion osv osv.

Så jeg mente at webshoppen var ganske brugervenlig.

Jeg vil så lige sige at hele designet og html koder - køres 100% bagved,
uden nogen form for at brugeren kan gå ind og rette i dette (jo, hvis
han kan PHP og HTML selvfølgelig, ellers ikke) - Grunden er simpelthen
at vores designerer i firmaet ikke ønsker at kunder går ind og laver
mærkelige dimser, knapper osv. og ødelægger designet, da det netop er
dette at vores firma går op i. Stilrent og flot design.

> Jeg mener altså, at der er noget som hedder OVERKODNING, nemlig det at lave
> unødvendige funktioner, som gør koden unødvendig omfattende og kompliceret
> og som reelt ikke er til gavn for brugerne. Når sådan overkodning laves, er
> det som regel enten fordi programmøren synes det er så sjovt at kode, at han
> bare bliver ved og ved.... eller også fordi at individuelle brugere foreslår
> funktioner, som de alene (og ikke andre) har brug for, uden at tænke på at
> der derved skabes for høj kompleksitet.

Det lyder som om du smider ALT ind i alle portaler.
Prøv at kigge lidt på fx. hvordan Typo3 gør det.

Altså laver en mappe med ALLE de funktioner der nu findes, og kun smider
de funktioner som kunden ønsker findes i hans webportal.

Ja, programmører koder ligeså tosset som de har lyst, det er vel også
det de får deres løn for :)

Jeg er gået det ekstra step at lærer lidt mere om brugervenlighed (og
nej her mener jeg ikke for blinde, da jeg næppe tror at det er muligt at
lave en webshop brugervenlig med alle de funktioner der nu skal til, no
offense)

Men det er en kanon idé at finde en som godt kan finde ud af at trykke
på et tastatur, og tør trykke på forskellige knapper, bare for at finde
ud af hvad den gør, men så heller ikke mere kendskab til computer, de er
svære at finde - men gode at kende :)

> Dette problem har ikke kun noget med PHP at gøre, men drejer sig -
> formentlig - om alle programsprog, og jeg vil godt høre andre som arbejder
> med webprogrammering, hvad jeres erfaringer er med dette problem.
>
> - Hvornår har man nået grænsen, hvor der ikke bør kodes mere?

Når kunden er tilfreds, og ikke før!

> - Hvor kan man læse tekst/teori om dette spørgsmål?

Jeg mener en der huserer i html gruppen, er gået et ekstra skridt ind i
"brugervenlighedsverdenen", men hvem det er kan jeg ikke lige huske.

> - Hvad er det engelske udtryk for Overkodning??

Overkodning findes ikke!
Kun programmører, som ikke kan gøre deres ting overskuelige :)

---

Martin wrote:
> Enig!
> Her gør jeg så det at jeg starter med at fjerne alle funktioner, også
> har jeg en dialog med kunden om kundens ønsker, og disse funktioner slår
> jeg så til. Så bliver kunden så sat ind i disse ting, og intet andet.

Nu så jeg lige <http://en.wikipedia.org/wiki/Image:MSWord.PNG> billedet
af MS Word med alle toolbars slået til.

Ja, der er mange toolbars, og sikkert mange flere end de fleste
overhovedet vidste var der.

Der er en grund til at MS Word er installeret med de "normale toolbars"
men de ekstra toolbars er der, hvis der er behov.

Pointen lyder vel noget ala - Slå alle ekstra ting fra, og kun have de
mest basale fremme, og lad kunderne/brugerne selv slå de ting til som de
nu selv ønsker.