Hvad en god udvikler kan

Broder Makholms indlæg om hvad en god udvikler skal kunne har irriteret min brokkekirtel og det er efterhånden ved at krystalisere sig hvorfor.

Listen som Makholm henviste til, havde som usagt forudsætning at vi udvikler samme slags applikationer på samme måde af samme årsag i fremtiden.

Vi er nået til et punkt hvor en af Europas ledende leverandører af rullende transportmateriel ikke mere kan finde ud af at sammenkoble to togvogne fordi computerne "ikke vil".

Problemet er natuligvis ikke microcomputere med korslagte ben, men en kravspecifikation der burde have været kastet i pejsen inden den nogen sinde blev renskrevet.

Det vigtigste en god idvikler skal kunne er hverken imperative sprog eller genbrugelige framworks, men at sige fra.

I dag er den største udfordring ikke at implementere IT systemer, men at vide hvornår man skal lade være eller hvor lidt af dem der faktisk er brug for.

Den fremtidige helteudvikler ser C-teamet i øjnene og siger "det var faktisk en bedre forretning at lade være med at lave det her IT system".

For bonus point forklarer hun om 90/10 reglen og siger "hvis jeg må skære 10% af funktionaliteten, så falder prisen til under det halve.

Nej, ikke til en tiendedel; It folk er notorisk dårlige til at estimere tid&penge, så lidt konservatisme hører med til profilen af en god udvikler.

En sand nationalhelt af en udvikler, forklarer Folketinget at millimeterdemokrati er utrolig dyrt at indføre og forklarer hvor meget der kan spares ved at nøjes med centimeterdmokrati[1].

En god udvikler kan se, som tandlægerne så det for 50 år siden, at det er bedre at undervise i tandbørstning,end at sælge guldkroner til rådne tænder.

phk

[1] Skatteministeriet koster 100mio i drift om året.

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Søndergaard

En sand nationalhelt af en udvikler, forklarer Folketinget at millimeterdemokrati er utrolig dyrt at indføre og forklarer hvor meget der kan spares ved at nøjes med centimeterdmokrati

Det er en af mine kæpheste! Jeg forstår dog ikke, hvorfor det skal være en udvikler, der skal forklare dem det. Det er jo mere et spørgsmål om lovgivning end software. Et grundkursus i software^H^H^H^H^H^H^H^Hlovgivnings-entropi burde være obligatorisk for alle folketingspolitikere.

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

  • 0
  • 0
Ole Elkjær Christensen

Det vigtigste en god idvikler skal kunne er hverken imperative sprog eller genbrugelige framworks, men at sige fra.

Jeg kunne som sådan ikke være mere enig, lige med undtagelse af at det kan koste en fyreseddel.
Jeg har tidligere prøvet dette fordi jeg sagde fra og ikke ville lyve over for kunder omkring fremdrift på projekter. Min daværende chef sagde til kunderne hvad det passede ham, og jeg nægtede at bakke ham op, når jeg viste det ikke var rigtigt. Det blev betragtet som værende iloyalt, hvilket det måske også var set fra hans synspunkt.

Derfor kom jeg i betragtning første gang der var resursemæssige justeringer, som det hedder i ledelsen, da ordet fyring giver en ubehagelig klang af at der er mennesker involveret :-)

Jeg har lært en ting af dette. Hvis jeg skulle komme i den situation igen, så holder jeg mund og finder nyt arbejde hurtigst muligt !!!

Men som sagt er jeg klart enig i at det er udviklerens opgave at påpeje tåbelige projekter og lignende som du nævner. Det er der også rigtig mange udviklere der gør, med fare for at de bliver sat i en bås som værende umulige pessimistiske mennesker der ikke kan se perspektiverne i fremtiden og i udnyttelsen af de store systemer.

/Ole

  • 0
  • 0
Henrik Størner

Jeg siger fra, når det er nødvendigt. Det er det, når jeg føler min "professionelle ære" krænket; hvis jeg ikke vil bryde mig om at blive kendt som "ham der var med til at lave X".

I mit første job som software-udvikler havde jeg en fornuftig direktør. Han mente at software-udvikling skulle ses som et håndværk, og at vi havde ansvar for at levere "godt håndværk" hele vejen igennem. Hvis en murer bygger noget skidt falder det fra hinanden; hvis man laver dårlige programmer bliver det noget møj - uanset om det så skyldes inkompetence hos programmøren eller hos den der specificerer opgaven.

Hvis du ikke kan stå inde for dit håndværk, så sig fra. Og hvis det sker for tit, så er det nok værd at overveje om man nu også bryder sig om at være der, hvor man er.

  • 0
  • 0
Peter Nørregaard Blogger

Millimeterdemokrati er ikke om at spare penge men at sikre retfærdighed – og det har ikke meget med it at gøre.

Men det koster! Sociallovgivningen inkl. bekendtgørelser og den slags i fyldte i 70’erne ét ringbind – og omkring år 2000 fyldte den 10 bind, jeg har ladet mig fortælle. Hvad den fylder i dag ved jeg ikke, men jeg frygter det værste. Men vi går muligvis i for små sko hvad angår retfærdighed, det skal jeg ikke afvise.

  • 0
  • 0
Peter Nørregaard Blogger

Det vigtigste for en udvikler at kunne er at forstå formålet med det der skal laves – uden den forståelse er det små hvad der kan opnås af resultater.

Ang. at sige fra, så jeg har tænkt over at sige fra hvis jeg blev allokeret et bestemt og problematisk projekt for en kunde. For det går imod min overbevisning at være med det sådan noget. Uden at nævne navne handler det om saldo-metoden og retsvirkning, som måske fortæller den indviede hvad jeg mener.

Konsekvensen ville så bare være at min arbejdsgiver fandt en anden til den opgave.

  • 0
  • 0
Ole Elkjær Christensen

It folk er notorisk dårlige til at estimere tid&penge, så lidt konservatisme hører med til profilen af en god udvikler.

Det er efter min mening ikke helt rigtigt at IT folk er dårligere end andre fagområder til at estimere tid & penge. Jeg tror bare at det er en hel del mere besværligt inden for IT området.

Man prøver som regel at ramme et bevægende mål og ikke nok med det, så forandrer omgivelserne sig også. Det er faktisk nemmere at bygge et hus på fast grund efter en klar tegning, selv om det også sagtens kan gå galt (Læs DR byen :-) ) .

IT folk skal estimere et projekt, hvor det, man gerne vil have ofte ændrer sig i løbet af projektet. Primært fordi virkeligheden, hvor forretningen arbejder, ændrer sig og derfor opstår der nye/ændrede behov. Af denne grund er store IT projekter ofte dømt til at overskride estimater eller skal have en fase 2 med tilrettelser.

Jeg har dog lært et par simpel ting omkring estimering af projekter.
Planlæg altid med at der skal være en fase 2 og evt. fase 3 projekt efter det primære projekt og at de ikke skal estimeres fra starten. Det betyder at det primære projekt næsten altid vil kunne komme til at overholde den primære tidsramme og budget. I stedet nedjusterer man de opgaver man skulle have løst inden for det primære projekt og udsætter dem til fase 2 eller fase 3 projektet, som jo ikke er estimeret endnu. På denne måde vil man være færdig ”on time and budget” hver gang.

Det er vel det der hedder en ”Win – Win Situation” :-) .

/Ole

  • 0
  • 0
Rasmus Morten Helbig Hansen

Nu vi heldigvis er inde på nogle lidt mere generelle kvaliteter, som man som udvikler bør besidde, så vil jeg også lige sige "være en god kollega". Jeg vil da sige at det er langt vigtigere at kunne indgå i en konstruktiv dialog med kolleger end noget andet. Det betyder selvfølgelig også at man skal have modet til somme tider at sige nej, men så længe man ikke opfører sig som en arrogant jubelidiot, fordi man hakkede hele raden af i kolonne 3, så er der vel plads til det. Endnu bedre hvis man kan tage fejl en sjælden gang, indrømme det, og komme videre. Eller at rose en kollegas arbejde eller evner i ny og næ.

For faen, jeg ville da nok også selv ryste lidt i bukserne, hvis jeg skulle arbejde sammen med Hr. 3-i-snit, og han ikke lavede andet end at skyde sine kollegers arbejde ned. Der skal jo også være plads til folk, som har et ganske almindeligt liv.

Så det var en stemme for at være lidt jovial og gennemsnitlig. ;-)

  • 0
  • 0
Jens Madsen

En god udvikler kan se, som tandlægerne så det for 50 år siden, at det er bedre at undervise i tandbørstning,end at sælge guldkroner til rådne tænder.

Er det bedste ikke, at investere i forskning, således man bliver i stand til at vaxinere mod huller tænder? Derved undgås undervisning i tandbørstning (som for længst har vist sig ikke fungerer), og guldkroner undgås også.

Det ses ofte, at forskning kan løse problemer. Har du et problem, er der to muligheder: At finde en løsning, f.eks. vaxination. Det kan være, at udvikle systemer, der forhindre uheld. Softwarescannere, der kan sikre, at et program er korrekt, inden det kompileres. Og sprog, der giver resultateter der er deterministiske, og uden fejl, og hvor softwarefejl kan reproduceres, fordi sproget er deterministisk, og har mulighed for logning af data og inputs. Ofte er muligt, at udvikle sikkerhedssystemer, der forhindrer uheld.

Har du en virksomhed, kan du investere i et sådant system - eller du kan undervise medarbejderne i, at ikke begå fejl. Det sidste viser sig, at ikke fungere. Det som fungerer, er automatiske systemer, der garanterer høj sikkerhed og kvalitet. Også indenfor softwaren. Det betyder, at man forsker i, og opfinder metoder, og automatiske systemer, samt compilere, der kun vil give et svar, hvis at softwaren er korrekt. Naturligvis, kan man ikke opnå 100% sikkerhed, men hvis der opnås 99%, er det langt nemmere, at klare de resterende 1% ved god undervisning.

Derfor, er aldrig godt, at "undervise" i god tone, og god opførsel. Det er ikke godt, at man skal have undervisning i, hvordan programmering skal gøres, og ikke gøres korrekt. Det rigtige er, at compilerne skal være i stand til, at sikre programmeringen er i orden, og at der ikke opstår nogle fejl. Som eksempel, kan compilerne tvinge udviklerne, til at skrive testvektorer, således de beviser, at de har tjekket softwaren, og dets resultat. Og de kan verificere, at testvektorerne er tilstrækkelige, til at enhver linie, og enhver retning som koden kan køre i, ved branches, er udført af test vektorerne. Ligesom i virksomheder, kan du investere pengene i automatiske systemer, der garanterer kvalitet, og sikrer at der ikke er fejl - eller du kan uddanne medarbejderne til at ikke begå brølere. Aldrig, har det sidste, være en brugbar løsning. Kun i de få tilfælde, hvor det er tale om direkte sabotage, og ikke uheld, har uddannelse og trusler om pisk, bøde (mindre løn), og fængsel kunnet virke. Og det kan være meget godt, hvis programmører er terrorister.

Metoden, som fjerner fejlene, er at forske i automatiske metoder, der fjerner fejl fra software. Det kan være kompilere, eller verificeringsteknik.

Man kan udvikle værktøjer, der er ikke fører til fejl, så nemt som andre tools. Mange problemer, er i virkeligheden mangel på tools, der er gode nok. Fejl udbreder sig, som ringe i vand. Medfører et sprog, eller et operativsystem fejl, så vil mange tools, der anvender dette sprog, også få fejl. Og de medfører tilmed fejl i de programmer og applikationer, som de bruges til at udvikle.

Hvis problemer som sammenkobling af tog, skulle beskrives i et program, vil det kræve at de to protokoller "passer sammen". Passer de ikke sammen, vil komme en fejl, eller der kan automatisk vælges en protokol som passer, hvor "typerne" passer til.

Ved eksterne grænseflader, som f.eks. sammenkobling af tog, er naturligvis meget vigtigt, at beskrive protokollen grundigt. Det er en fordel med en standard, og at holde denne standard simpel, men grundig. Den må ikke være "for simpel", men kun så simpel som mulig. Som altid, skal tingene være så simpel som muligt - men IKKE mere simpelt end muligt. De fleste, gør det præcist omvendt. Laver tingene så kompleks som muligt, og ikke grundigt nok, til at fungere. Eller de mangler at overveje vigtige egenskaber, såsom sikkerhed, strømforbrug og instruktionsantal, ramforbrug, store O og kompleksiteten osv. Det er både for simpelt, og for kompleks, på éen gang.

Her kan undervisning også være vigtigt: Mange ser ikke ud til, at have lært, at tingene skal være så simple og logiske som muligt. Fordi, at man derved undgår fejl, og opnår større sikkerhed. Laves ting ens, som er ens, så vil man opdage, når noget er forkert, fordi det ikke er ens. Og man tvinges til, at overveje, hvor det er, at det er gået galt. Beskrives ens ting forskelligt, så opdages ikke, hvis de ikke håndteres ens, fordi det opskrives som selvstændige forskellige cases. Derved opdages ikke konsistensfejlene. Ofte, er selv ens ting, forskellige med hensyn til følsomhed for fejl. Og derfor, lægges fejlene typisk ind forskellige steder - fordi de lægges, hvor det ikke sker tit. Er det konsistent, og ens, så vil det være langt sværre at lægge fejl ind, og sandsynligheden for fejl øges. Laves eksempelvis en tæller, kan du ikke få den til at fejle på 5'te ciffer, da den så også fejler på 1'ste ciffer. Bruges samme sorteringsrutine overalt, i stedet for 7 forskellige, så kan du ikke udføre en eneste sortering korrekt, uden alle sorteringsrutiner er i orden. Bruges forskellige, er stor sandsynlighed for deffekt, i en der er af "mindre betydning". Og samtidigt, bliver softwaren større, og mere kompleks, fordi man skal sætte sig ind i mange forskellige rutiner, der gør det samme.

Problemet søges løst ved at "bygge på", og som oftest uden held. Kompleksiteten vokser. Softwarens størrelse øges, når fejlene skal rettes, og man forsøger at rette de enkelte fejlsorteringer. Teorien er, at hvis kompleksiteten øges, så vil den på et tidspunkt blive tilstrækkeligt til, at problemet løses. Erfarringen viser dog, at dette næppe sker, og kompleksiteten vokser. Før eller siden erkendes problemet, som at man ikke kan stoppe udvikling.

Hvem vil hævde, vi kan undgå programopdateringer i dag?

I nutiden findes videnskaben ikke. Der findes kun beta.

Virksomhederne arbejder ikke på ensartethed, og standarder. De arbejder på forskellighed, og inkpomatibilitet. Logik, og simpelhed accepteres ikke - det er for ligetil at "kopiere". Hvis noget er logisk, er det nemt at forstå, og nemt at kopiere. Det er nemt at indsé eventuelle fejl, og det er svært at hive penge ud på videnskaben, at rette en dum fejl.

I stedet for at tillade virksomhederne tjener på, at begå brølere - skulle vi måske gøre det til en udgift for virksomhederne. På den måde, vil de gøre mere for, at investere i forskning, så de undgår at begå fejl.

  • 0
  • 0
Poul-Henning Kamp Blogger

Er det bedste ikke, at investere i forskning, således man bliver i stand til at vaxinere mod huller tænder? Derved undgås undervisning i tandbørstning (som for længst har vist sig ikke fungerer),

Det var dog en utrolig verdensfjern påstand, hvorfra har du påstanden at undervisning i tandbørstning ikke virker ?

Og med hensyn til din "vaccinerings" forslag imod carries, så er IT analogien at vaccinere imod dumhed, god arbejdslyst med forskningen. :-)

Poul-Henning

  • 0
  • 0
Ole Elkjær Christensen

For faen, jeg ville da nok også selv ryste lidt i bukserne, hvis jeg skulle arbejde sammen med Hr. 3-i-snit, og han ikke lavede andet end at skyde sine kollegers arbejde ned.

Der er nok ikke nogen grund til at ryste i bukserne, for en der er så fantastisk har nok travlt med at forsøge at gå på vandet :-) .

Du har dog en væsentlig pointe med at man skal være en god kollega. Det tror jeg de fleste er eller prøver på at være. Jeg tror også at de fleste gode kollegaer accepterer at man siger nej, hvis man ikke har tid eller hvis man synes løsningen ikke hænger sammen.

Det er som regel heller ikke over for ens kollegaer problemet med at sige nej opstår. Det er som regel over for dem med tidsrammerne og budgetterne. De har en helt anden opfattelse af ordet nej end vi andre har.
Jeg har prøvet at lave en lille udvikler til projektleder oversættelse af ja/nej opfattelsen på spørgsmålet:
Kan du lave denne XX opgave på 30 timer?

Udvikler Ja > Projektleder opfatter Ja og det inkluderer test og produktion.
Udvikler Måske > Projektleder opfatter Ja og det inkluderer test.
Udvikler Nej > Projektleder opfatter Ja.
Udvikler NEJ > Projektleder opfatter Ja, men skal have allokeret tiden hos udviklerens chef.
Udvikler NEEEJ > Projektleder opfatter nej, men kun til i morgen, hvor han kommer igen med en revideret plan med 35 timer og så inkluderer det test og produktion.
Udvikler NEEEEJ &¤#%/&##%%¤# > Projektleder opfatter Nej og tænker at udvikleren nok er lidt stresset. Må hellere finde et hjernelamt konsulentfirma der vil lave det som et fastpris projekt.

Sådan kan det godt opleves når man siger nej som udvikler :-)

/Ole

  • 0
  • 0
Joakim Recht

Det er vældigt at sige nej, men der er lige et problem hvis kunden ikke lader sig overbevise, hvilket absolut ikke er sjældent set (det er især udbredt hvis kunden har et par whitebord-arkitekter til at assistere med projektledelsen).
I det tilfælde kan jeg som udvikler sige nej til at løse opgaven, og så kan der ca ske to ting: 1) Min leder er enig, og kunden får at vide, at vi ikke er enige i at opgaven skal løses og 2) min leder er ikke enig.
I tilfælde 1 kan det gå så vidt som til at vi som leverandør stopper samarbejdet. Den eneste konsekvens det har er formentligt, at kunden finder en anden leverandør, der ikke siger nej. Og så får vi i øvrigt ikke flere opgaver derfra. Tilfælde 2 resulterer i, at jeg kommer af projektet, og der bliver fundet en anden.
Ingen af tilfældene betyder, at selve opgaven bliver droppet, som ellers ville være det eneste fornuftige. Derfor bliver det ofte sådan, at i stedet for at sige nej, prøver man at trække opgaven i en anden retning, hvilket nogle gange går godt, og andre gange går det knap så godt. Under alle omstændigheder lader det til, at der er en del tilfælde, hvis det som udvikler er stort set umuligt at påvirke det endelige resultat.

  • 0
  • 0
Jens Madsen

[quote]Er det bedste ikke, at investere i forskning, således man bliver i stand til at vaxinere mod huller tænder? Derved undgås undervisning i tandbørstning (som for længst har vist sig ikke fungerer),

Det var dog en utrolig verdensfjern påstand, hvorfra har du påstanden at undervisning i tandbørstning ikke virker ?[/quote]
Mængden af plumper, er i dag nærmest voksende, trods man underviser i tandbørstning. Tandlægerne har stadigt job, og undervisningen har ikke LØST problemet. Meget tyder på, at det i de senere år, efter at plast plumper er opfundet, endog er sket en stigning i anvendelsen af plumper, og at behovet for kroner, også er forøget. Det er udført forsøg med at vaxinere mod huller i tænderne - problemet er lidt som at vaxinere mod forkølelse. Der er mange forskellige bakterier, og svært at gøre det. Men det er muligt, at lave nogle bredspektrede vaxineringer, som fungerer, men skal gentages med jævne mellemrum, da bakteriefloraen ændres. Dog "tøver" man lidt med at indføre det, på grund af der ikke helt kendes konsekvenserne.

Og med hensyn til din "vaccinerings" forslag imod carries, så er IT analogien at vaccinere imod dumhed, god arbejdslyst med forskningen. :-)

Det er korrekt at vaxination mod dumhed er muligt. Tænk på dengang, hvor du skulle manuelt oversætte maskinkode til hex kode, og oversatte i hånden uden brug af assembler. De fleste lavede fejl, i enten oversættelse, jumps, eller talte forkert ved relative jumps. De skulle bare tælle korrekt. Men, alle gjorde fejl. Asssembleren, løste mange af disse problemer. Højniveau sprog, løste også problemer. Typetjek, fandt mange fejl. Selv overgangen fra C++ til Java, viste sig for nogle programmører, at "rette fejl". Dette er eksempler på, at det i den grad, er nødvendigt - og en god idé, at vaxinere mod dumhed.

På nogle måder, kan vi sige, at Makholms indlæg, rummer mange gode ting, som en udvikler skal kunne. Problemet er dog, at en god udvikler, også skal kunne mere end det som der undervises i, og som står på skemaet. Hvis vi ser på problemerne i nutidens programmer, så skyldes de måske ikke, at programmørerne ikke har de evner, der er på listen. Det kan skyldes, at de ikke bruger dem - og at compilerne de bruger ikke "motiverer" dem til det. Tager vi et eksempel som rød-sort træer, og også andre former for data strukturer, så er det områder, at compilere selv kunne implementere, og derved gøre det til den normale måde at bruge. Hvor, at programmørerne i dag føler det "besværligt", og finder det nemmere, at implementere dårlige algorithmer. Beder du om en god algorithme, får du at vide, at det koster. Vi kan eksempelvis tage s[tal]:=5 - vi har en array, som vi lægger data i. Kunne vi, som index, bruge andet end et index fra 1..n, f.eks. floats, strenge osv. så vil være muligt, at oprette en database, der sammenknytter indexnavn med data. Var denne feature impelementeret i compilerne, så vil programmørerne automatisk anvende de strukturer, og derved anvende gode datastrukturer. Naturligvis, kan det også gøres, med et eksternt bibliotek, men typisk gør programmørerne ikke det. Du ser også ofte, at programmører anvender "bobbelsort". Ønsker du, at det ikke tager tid med sortering, og at data anbringes i sorteret orden, hvor der ikke bruges væsentligt tid på indsættelsen, får du at vide, at det er umuligt, eller vil koste ekstra. En bobbelsort, er billigere, end fletsort. Og derfor, bruger udviklerne ofte bobbelsort. Først, når det ikke er godt nok, bruges fletsort, og du får programmer, der ofte har implementeret forskellige sorteringsalgorithmer, afhængig af, hvad som er "nødvendig" for opgaven. Var sorteringsproblemet, databaseproblemer, og mange andre "typiske" problemer, implementeret som del af et sprog, vil det ikke kræve, at programmøren ved noget om disse ting, for at lave et godt program.

Konklusionen er, at selvom Makholms liste, viser mange interessante ting, som skal kunnes, så er det ikke nødvendigvis de rette kvalifikationer, og behovet kan måske ændre sig i fremtiden.

Jeg mener selv, at det er vigtigt, at programmører holder styr med kompleksiteten af deres algorithmer og software. Skal du eksempelvis teste et produkt, er umuligt at få at vide, at svaret kommer en gang i fremtiden. Hvornår, ved ingen. Det er nødvendigt, at du har oplysninger om hvordan forsinkelserne hænger sammen, således vi kan "gætte" os til, hvor længe vi behøver at vente, før svaret kommer. Ved vi ikke, hvor længe vi skal vente på svar, så kan vi ikke opsætte et automatisk test system. Normalt, får du bare fra programmørene svaret, at problemet er uhyre kompliceret, og at du ikke har ventet lang tid nok. At problemet er så kompliceret, er vigtigt indgår i dokumentationen, da det måske enten er løst forkert, eller softwaren er totalt ubrugelig, fordi det ved store opgaver, har for store (uendelige) svartider.

Giver vi en programmør en opgave, som at "finde" fejlene i et programmeringssprog - altså de "fejl" der medfører programmører gør fejl, så er denne opgave ganske svær. Uanset, at du har gode kvaliteter som programmør, er det ikke sikkert, at du kan indsé fejlene, i det software, som du selv bruger. Mange C++ programmører, troede nærmest, at C++ var fejlfri, og de selv var årsag til dumhederne, indtil de fik Java. Så var det pludseligt nemmere at undgå, at lave visse typer fejl. En dygtig programmør, bør måske også kunne se, de "problemer" der kastes over dem, f.eks. ved dårlige sprog, og dårlige operativsystemer.

Opdager du et problem, med pointerstrukturer, skyldes det måske i virkeligheden, at pointerstrukturer ikke er en metode, der er godt at bruge, ved kodningen af software. Oftest, vil programmøren tro, at det er ens egen dumhed, som er årsag. I virkeligheden, var problemet måske langt nemmere at deffinere, og strukturen med dynamisk lager, kunne deffineres mere logisk, og struktureret. Og hvis metoderne, for de mest normale dataopbevaringsmetoder, er indbygget i sproget, vil du måske undgå fejlen, og samtidigt kunne beskrive problemet overskueligt i koden. Pointerstrukturer, er måske i virkeligheden, en meget ustruktureret måde, at opbevare dynamiske variable, nærmest svarende til at gemme alt i et rod i et rodkatalog, og den manglende struktur i sprogets måde at opbevare dynamiske data og datastrukturer, er måske i virkeligheden en årsag, til at pointere viser sig at føre til problemer.

Det er ikke nok, at kunne konkludere, at pointere er dumt, fordi det ikke dur. Vi skal også kunne komme med forslag til, hvordan sprogene kunne være lavet, og kunne analysere såvel problemer, som vores forslag til løsninger. Evnen, til at netop finde ud af gode løsninger, er det som er vigtigt for en programmør, og ikke nødvendigvis, at have lært en række metoder udenad. Vi skal til gengæld, gerne "tvinges" til, at gøre tingene ordentligt, ved at compilere og redskaber, leder os til dette, og ved de eksempler, som vi udsættes for, f.eks. i litteraturen for de compilere og redskaber vi bruger, også gør det korrekt. Vi lærer, af vores omgivelser - og ikke mindst de ting, som vi bruger, og synes er godt. Derfor, er vigtigt, at gøre meget ud, af de ting, som alle bruger - typisk compilere, og deres dokumentation.

  • 0
  • 0
Jesper Louis Andersen

Her er min pet peeve:

En velmenende medarbejder har faaet en god ide, og ze boss synes ogsaa det er en god ide, saa han tager fat i udvikleren og spoerger om det kan loeses. Udvikleren, der elsker at kvase problemer begynder saa at taenke saa det knager. Efter noget tid siger han: ``Ja, det kan godt lade sig goere, men der er visse ting som skal laves...'' Dernaest foelger saa en laengere teknisk udredning af hvilke forbehold som goer sig gaeldende. Udvikleren har faaet konstrueret en loesning, men den er ikke simpel og der skal foretages mange aendringer for at faa problemet loest.

Men en person som ikke har viden om IT hoerer stort set kun ``Ja, ...'' og saa en masse som vedkommende ikke forstaar. Det kan altsaa lade sig goere! Nu skal vi bare forhandle os frem til en deadline og eventuelt en pris.

Jeg tror at lidt erfaring faar een til at vaere i stand til at "lyve" og sige at ting over et vist niveau af kompleksitet bare skal stryges med det samme.

  • 0
  • 0
Jens Madsen

Nu skal vi bare forhandle os frem til en deadline og eventuelt en pris.

Ofte sker dette, før man endnu helt ved, hvad opgaven indebærer...

Jeg tror at lidt erfaring faar een til at vaere i stand til at "lyve" og sige at ting over et vist niveau af kompleksitet bare skal stryges med det samme.

Det vigtige er, at holde kompleksiteten lav. Samme problem, kan ofte løses, med forskellige kompleksitet. Evnen, til at gøre det simpel, er utrolig vigtigt. Evnen, til at gøre det komplex, giver gysser. Komplexitet, skal helst ikke være at finde i softwaren - men holde sig til det der bruges, i forbindelse med overbevisning af kunden om opgavens store sværhed.

Der er meget stor forskel på mennesker - og programmører. Nogle programmører, er enormt hurtige og dygtige, men klarer kun opgaver, der ikke er enormt svære. Andre, er måske langsommere, og evner ikke at blive hurtig færdig. De evner måske, at have tålmodighed, og evne til, at løse opgaver, der kræver dybere tænkning og forskning. Det kan tage sin tid - men er opgaven vigtig nok, betyder det mindre.

Problemet idag, er at mange er bange for svære opgaver. I stedet for, at se det som en udfordring, så "tør" de ikke tage opgaver, der kan løses på under få uger. Det at løse en sådan opgave, kræver måske ikke kun hurtig kodning - det kræver forskning, dokumentation, undersøgelse af mange muligheder, for at finde den bedste, og mest korrekte. Kodningen, kommer som en mindre del til sidst, og hvor det udgør mindre, jo bedre det indledende er gennemtænkt. Typisk, er det dataloger, og ikke programmører, der arbejder med den type forskning. Og mange virksomheder har ikke ansat dataloger - kun "kodere". Og de er måske ikke uddannet til, at forske i store opgaver.

Der er tendens til, at store opgaver, ofte løses enormt simpelt, hvis dem der arbejder med det, bruger den tid som er nødvendig. Resultatet er flere års forskning, og få siders kode.

Det ses ofte, at hvis der arbejdes grundigt med problemerne, så kan såvel brugergrænseflader, som algorithmerne bag, blive mere overskuelige, mere simple, og få lavere kompleksistet. En opgave, der startes med, at skulle gennemlæse en tekst n gange, ender måske med, at kun behøve at gennemlæse teksten 1 gang, eller log(n) gange. Årsagen er kun, at der indsés hvordan opgaven løses, ved hjælp af algorithmer, der ikke har stor kompleksistet.

Er ikke muligt, at få kompleksisteten ned til et lavt niveau, kan det mest rigtige være at droppe projektet. Ellers virker softwaren for sløvt, til nogensinde at blive brugt.

  • 0
  • 0
Ole Elkjær Christensen

Problemet idag, er at mange er bange for svære opgaver. I stedet for, at se det som en udfordring, så "tør" de ikke tage opgaver, der kan løses på under få uger.

Dette er simpelt hen noget vrøvl. Der er masser af store opgaver, men de opdeles i mindre projekter, inden de uddeles, for at minimere risiko. Der er masser af svære opgaver og masser til at løse dem og tro mig, det er ikke nødvendigvis dataloger der løser dem. Det er det ikke af den simple grund at de fleste virksomheder skal bruge et færdigt produkt og ikke en 1000 sider teoretisk rapport om hvordan produktet evt. kan laves.

Typisk, er det dataloger, og ikke programmører, der arbejder med den type forskning. Og mange virksomheder har ikke ansat dataloger - kun "kodere".

Wonder Why ? Måske af samme årsag som ovenstående. De har brug for praktisk arbejde samt konkret problem løsning. De har ofte ikke konkret brug for forskning i hvordan et problem generet løses.

Nu siger jeg ikke at virksomheder ikke generelt set ikke har brug for forskning, men ofte vil det så være i samarbejde med er konkret forsknings institution som f.eks. et universitet. Meget få danske virksomheder er i virkeligheden store nok til at have sin egen ”stand alone” forsknings afdeling.

Noget af det første der sprang mig i øjnene, da jeg læste den oprindelige liste, var faktisk at man praktisk taget skulle være universitets uddannet for at være level 3 udvikler, for der var flere af level 3 tingende man aldrig vil se uden for at universitet.
At man har gået på universitetet betyder ikke at man er en god udvikler, og det betyder heller ikke at man er en god forsker.
Det betyder bare at man har gået på universitetet !!!

Alle det ting der nævnes et værktøjer, men der er de individuelle evner hos den enkelte der afgør om man er i stand til at bruge dem. Hvis man ikke har evnerne til at være udvikler, forsker eller noget andet, nytter viden ikke. Viden kan dog gøre en middelmådig inden for et område, men ikke unik.

Jeg mindes bl.a. en lærer jeg havde på en af mine uddannelser. Han var totalt håbløs til at undervise. Så blev han sendt på pædagogisk grundkursus. Faktum var, at efter dette, var han stadig håbløs til at undervise, men nu brugte han farvet kridt på tavlen. Han var blevet teknisk bedre, men stadig håbløs :-)

Jeg har til gengæld også haft lærere der var fantastiske til at undervise, men som teknisk set ikke var de bedste. De havde til gengæld en evne til at få folk til at lytte og folk fattede hvad de sagde.

/Ole

  • 0
  • 0
Jens Madsen

Vi er helt enige om, at mange større opgaver, kan opdeles i mindre. Problemet er, at opdele opgaverne korrekt. Gøres det forkert, risikeres, at opgaven bliver uoverskueligt, og overblikket mistes. En opgave, kan "pustes op", til at være mangedoblet, ved forkert analyse af opgaven, og forkert opdeling.

Mange af erhvervslivets opgaver, ligger på et niveau, så de ikke kræver universitetsuddannelse. Og for universitetsuddannede, kan det endog virke dumt, at skulle løse disse opgaver. Sæt dog en uden uddannelse, eller en programmør, på opgaven. Hvis man selv kunne programmere det, eller løse opgaven, da man var teenager, virker det lidt ude af propertion, at skulle have års uddannelse, og herefter erfarring, for at løse en af erhvervslivets normale opgaver.

Problemet indenfor kodning, ligger ikke i, at programmørerne ikke kan bruge værktøjerne. Problemet ligger i, at værktøjerne ikke altid giver anledning til kode, som fungerer. Det er ikke nødvendigt, at en programmør, har kendskab til bunker af algorihtmer, hvis værktøjerne automatisk implementerer gode algorithmer. Problemet er, at værktøjerne ofte ikke implementere gode algorithmer, og måske gør det nemmere, at gøre på dårlige måder.

Enhver programmør, vil vide at en "linær søgning", er nemmest. Men den tager også lang tid. Hvad er årsagen, hvis at en bedre algorithme, var indbygget i programmeringssproget? Eller selv et bibliotek, vil kunne ændre, hvad det er nem. Men, de fleste sprog, har indbygget ordre for linær søgning, f.eks. pos ordren, under strenge, og den bruges flittigt. Det betyder måske O(x*x) funktioner, hvor der søges og søges i enorme strenge, med linær søgning, uden opgaven egentligt analyseres på datalogisk vis. Det gør softwaren sløv, og at den får svært ved, at håndtere store datamængder. Hvis programmeringssproget, i stedet for linær søgning, havde indbygget metoder, der gjorde binær søgning, metoder der anvender binære træer, eller andre bedre algorithmer, så vil programmørenes kunnen også øges.

Værktøjerne, er der hvor problemet er. De er lavet af dem, der ikke er gode nok. De gode, sættes til at lave "banale" opgaver, for erhvervslivet, som de også kunne have løst, ligeså godt, i teen-age årene.

Jeg mener, at vi måske burde indføre børnearbejde indenfor kodning. Det reducerer lønningerne, til omkring en trediedel. Og børn, vil få mere ud af, at løse simplere opgaver, end trænede programmører. Har de en dygtig vejleder, vil de lære noget. Derimod, dygtige personer, vil intet få ud af det, og det er kun spild af evner og tid. Evner, som kunne være brugt, på ordentlige opgaver, i stedet for "teen-age" programmeringsopgaver, de nemt kunne løse som teen-agere, måske med en smule vejledning fra en dygtig datalog, der kan gennemgå algorithmerne, eller en dygtig programmør, der kan undervise dem i det programmeringstekniske. Den tid, der skal til, for at lære dem det nødvendige, for at øge kvaliteten af softwaren, er småting, i forhold til at skulle løse opgaven, og det kan ligge på et større niveau.

Dem, der sidder bag kassen er børnearbejdere. Dem, der arbejder på lageret, er børnearbejdere. Dem, der udvikler gratis software på nettet, er børnearbejdere. Løsningen, på softwarens pris, er mere børnearbejde, og at datalogerne sættes til fornuftige jobs, af typen de ikke kunne have løst i folkeskolen.

  • 0
  • 0
Poul-Henning Kamp Blogger

Nu skal det her ikke udvikle sig til en diskussion om DIKU uddannede dataloger er ubrugelige eller ej, den kan vi tage ved anden lejlighed.

Personligt tror jeg ikke det er så meget et spørsmål om uddannelse, som om erfaring, der bestemmer om folk kan finde ud af at designe og kode systemer der kan bruges til noget.

Der er noget "fornemmelse" man skal have tilegnet sig og det tror jeg ikke nogen underviser kan formidle, det kræver noget hands on.

Men blot fordi man har de nødvendige års erfaring, betyder det ikke at man har indset at man har en pligt til at sige fra overfor opgaver der er dumme.

Hvis det er tilfældt at der ikke er en eneste IT faglig person der kunne se at Amanda, DeMars (osv osv) var hul i hovedet, så har vi et meget stort antal meget inkompetente folk i branchen.

Hvis de så det, uden at sige fra, hvad gør det dem så til ?

De mindst attråværdige folk at have i sin organisation ?

Det er helt sikkert, at hvis jeg skulle interviewe en person der havde et af de mange store IT katastrofer på sit CV, så ville jeg spørge hvorfor vedkommende ikke havde stoppet projektet, om nødvendigt ved at gå til pressen.

Dem der sidder hos Skat lige nu (var det ca. 370 mio ekstra ?) kunne passende overveje om ikke der er noget offentligheden burde vide mere om...

Poul-Henning

  • 0
  • 0
Rasmus Morten Helbig Hansen

Det tror jeg de fleste er eller prøver på at være.

men det er vist de færreste som virkelig er. Det er imho en disciplin for sig selv.

Kan du lave denne XX opgave på 30 timer?

Det spørgsmål svarer man da aldrig på (jfr "Avoid off-the-cuff estimates" i Rapid Development af Steve McConnell).

Ens projektleder er også en kollega, så det er da ærgeligt hvis man har et forhold som du beskriver.

  • 0
  • 0
Ole Elkjær Christensen

men det er vist de færreste som virkelig er. Det er imho en disciplin for sig selv.
Ens projektleder er også en kollega, så det er da ærgeligt hvis man har et forhold som du beskriver.

Spørgsmålet med de 30 timer, ville jeg selvfølgelig heller ikke svare på, men det betyder ikke at jeg ikke stadigvæk får spørgsmålet :-)
Faktum er desværre, at der stadig findes masser af fastprisprojekter, hvilket næsten ikke kan andet end at munde ud i dette spørgsmål i bedste fald. I værste fald er det mere : du har 30 timer til at løse denne opgave.
Det er efter min mening utaknemmeligt at være projektleder på fastpris projekter, fordi man så kan blive nødt til at høre som beskrevet.
Jeg har også ofte set at projekter har fået estimeret timer, budget og deadline uden at der har været en eneste udvikler/teknisk person inde i vurderingerne.
Jeg vil også nødigt være projektleder på et sådant projekt, da det igen gør det svært at være en god kollega set fra projektlederens side, og dermed acceptere et nej fra udvikleren, da det er projektlederens ansvar at estimater overholdes.

Det med at være en god kollega er også en meget svær balancegang. Nu til dags i IT branchen, er det en kunst at være god og hjælpsom kollega, overholde egne deadlines samt undgå at falde død om af stress. Det kræver at man ind imellem må gå på kompromis med de to første for at undgå den sidste. I sidste ende kan man blive man nødt til at sige nej på nogle af områderne og gøre dette uden dårlig samvittighed (Hvilket nok er det sværeste).

Umiddelbart vil jeg så sige at det at være en god kollega bl.a. betyder at man kan sige nej og også at man kan acceptere et nej. Dette gælder også selv om kollegaen er projektleder eller chef :-)

Men blot fordi man har de nødvendige års erfaring, betyder det ikke at man har indset at man har en pligt til at sige fra overfor opgaver der er dumme.

Det er fuldstændig rigtigt. Nu er det heldigvis også sådan at det kun er opgaver der er designet af andre der er dumme, så derfor er det ret nemt at skelne :-)

/Ole

  • 0
  • 0
Carsten Sonne

Min mening:

Langt det vigtigste for en udvikler, er at have viden og indsigt.

Grundlæggende forståelse for det man beskæftiger sig med er altafgørende for at man kan vedligeholde og udvikle 'god kode’.

Det er umuligt at have dybdegående vide om alt, så en specialisering er også en god ting.

Som applikationsudviklere der arbejder med OO sprog er vigtigt man har en grundlæggende forståelse for:
1. Software arkitektur herunder lagdelt arkitektur.
2. OOA, OOD og kendskab til desing patterns.
3. Den/de API man har til rådighed. Jo dybere kendskab jo bedre.

For databaseudviklere er det et must at kende til:
1. ER diagrammer.
2. Normalisering.

Grundlæggende forståelse af programmeringssprog/afviklingsmiljø, datatyper, algoritmer og datastrukturer er selvfølgelig også et must. Ikke kun viden om men også forståelse for.

De resterende grupper af udviklere vil jeg afholde mig fra at have en mening om. Der findes så mange forskellige større og mindre 'nicher'.

Det kan lyde banalt, men selv denne grundlæggende viden, findes der udviklere som ikke bestrider.

Generelt syntes jeg matricen fra Makholms blog er et meget godt bud, men forsøget på at være generisk og udtømmende er dog mislykket. Ethvert forsøg på at lave en fyldestgørende model der samtidig favne alle typer udviklere, er dømt til at mislykkedes.

Mht. at agere på den viden og indsigt man har, som bliver efterspurgt af PHK; at være fagligt ansvarlig, vil jeg mene det er en mere menneskelig egenskab som absolut ikke burde være afgrænset til udviklere, men burde gælde for alle faggrupper!

En sidste ting: Børnearbejdere er ikke sagen...

Løsningen, på softwarens pris, er mere børnearbejde, og at datalogerne sættes til fornuftige jobs, af typen de ikke kunne have løst i folkeskolen.

Børn/teenagere har ikke viden nok til på tilfredsstillende vis at bestride rollen som udvikler. At være skarp og hurtig i opfattelsen samt kunne bakse noget kode sammen der virker, er ikke nok (men dog et rigtig god udgangspunkt). Lad børnene tage sig af arbejde som ikke er videnstungt. Derudover vil jeg afholde mig fra yderlig at kommenterer Hr. Madsens indlæg.

Det blot at kunne lave noget kode som ’virker’, er et ret ringe succeskriterium for om man er en god udvikler syntes jeg.

Mvh
Carsten Sonne Larsen

  • 0
  • 0
Jacob Christian Munch-Andersen

Jeg synes du fokuserer meget på viden.

Selvfølgelig skal man vide noget for at kunne programmere, men viden kan vi allesammen tilegne os.

En god programmør har først og fremmest en god logisk sans, den skal så kombineres med rutine for at blive rigtig anvendelig til formålet.

Dertil er det til de fleste opgaver godt at programmøren har en hvis forståelse for opgaven, han skal kunne sætte sig ind i præcist hvad produktet skal kunne og hvordan det vil blive brugt. Det er helt essentielt hvis programmøren arbejder alene, men kan også være en ganske god egenskab selvom andre kan hjælpe på det område.

Samlet vil jeg rangordne kriterierne for en god programmør på denne måde:

  1. Logik
  2. Erfaring
  3. Forståelse for opgaven
  4. Viden

Ikke fordi viden som sådan ikke er vigtigt, men fordi det i modsætning til de tre andre kriterier kan tilegnes trivielt og ad hoc.

Børn/teenagere har ikke viden nok til på tilfredsstillende vis at bestride rollen som udvikler.

Det var dog en arrogant generalisering. Voksne er nok generelt bedre til opgaven, men det betyder ikke at der ikke findes børn som mestrer kunsten, og som med stort set alle andre opgaver er en lille del af dem brændende skarpe til det.

  • 0
  • 0
Rene Nejsum

Der er ingen forskel på en god tømre og en god programmør, eller det burde der ikke være...

Jeg vælger ikke tømre til min nye carport ud fra hvor god han er til at save præcist, slå søm i eller have et godt øjemål. Jeg vælger den tømre der har ry for at levere til tiden og til aftalt pris. (Det kan også være svært nok at finde)

Af en eller anden grund har nogle programmører fået den idé at programmering er noget andet end at være tømre, det er ligesom om at det er finere og man derfor kan tillade sig at klynke meget mere :-)

Men, vis mig en kunde der siger: Det er et fantastisk IT system, alting virker perfekt, programmøren har forstået præcis hvad jeg ønskede mig, på flere områder har jeg fået mere end jeg regnede med, prisen er helt OK og det blev leveret til tiden.

Når en kunde siger ovenstående, så har du fundet en god programmør.

  • 0
  • 0
Log ind eller Opret konto for at kommentere