Programmøren vs. projektlederen?

Son of Man,
is the clay
Take his hand,
and he find a way

Sikke et fantastisk manifest, og ja jeg kan nogle gange godt følge tanken når jeg laver et projekt. Det kan være skide irriterende hele tiden at skulle høre på hvad andre mener, for selvfølgelig har jeg altid den bedste løsning.

Meeeen som satans humanist og med en forhåbning om et job indenfor webudvikling, må jeg nok også tilstå at jeg mener at der er brug for folk som mig, skabe bedre websites:)

Hvis man bare snakker ren usability, så kan programmørerne da sikkert det meste til fingerspidserne. Men når det kommer til at skabe gode oplevelser på for eksempel et website, så tror jeg altså at programmørerne har brug for nogle indspark. Jeg har i hvert fald set eksempler på websites, hvor der godt kunne være brugt nogle flere overvejelser omkring den færdige løsning.

Sikke et fantastisk manifest, og ja jeg kan nogle gange godt følge tanken når jeg laver et projekt. Det kan være skide irriterende hele tiden at skulle høre på hvad andre mener, for selvfølgelig har jeg altid den bedste løsning.

Meeeen som satans humanist og med en forhåbning om et job indenfor webudvikling, må jeg nok også tilstå at jeg mener at der er brug for folk som mig, skabe bedre websites:)

Hvis man bare snakker ren usability, så kan programmørerne da sikkert det meste til fingerspidserne. Men når det kommer til at skabe gode oplevelser på for eksempel et website, så tror jeg altså at programmørerne har brug for nogle indspark. Jeg har i hvert fald set eksempler på websites, hvor der godt kunne være brugt nogle flere overvejelser omkring den færdige løsning.

Man programmerer i fritiden. Man udvikler på arbejdet. Udvikling kræver mere interaktion med de involverende parter.

Jeg føler sjældent at processen kommer i vejen for mit arbejde. Det er måske også fordi jeg arbejder i en ret lille virksomhed, hvor vi indfører processor hvor vi ser de er nødvendige, men ellers holder dem til et minimum. Denne tilgang kalder vi ikke noget.

Som udvikler er jeg glad for, at vi har en usabilityperson der sidder og designer hvordan ting skal se ud før jeg kaster mig ud i det. Det betyder til dels, at jeg kan fokusere på mit kerneområde, til dels, at jeg langt sjældnere skal spilde tid på at lave noget om i koden, da alle interessenter har været inde over da det blev designet. En anden fordel ved at have en ikke-koder til at designe programmet er at tilgangen er anderledes: Der bliver set mere på hvad der er smart for brugeren, og mindre på hvad der er smart for koderen. Måske er det lidt bøvlet at lave, men i sidste ende lader det mig lave noget jeg kan være mere stolt af. :)

Jeg har møder med kunder undervejs, og det betyder, at det jeg udvikler bliver mere værdsat fra starten, og igen, at jeg slipper for at skulle ændre alt muligt senere.

Alt i alt har jeg det fint med at andre tager hånd om de ting jeg enten ikke gider, eller ikke er lige så god til. Så kan jeg fokusere på programmering, motherfucker! :)

Joel Spolsky har længe været knotten overfor anvendelsen af metodikker indenfor softwareudviklingen.

På et tidspunkt tog han sig sammen, og skrev en hel blogpost om emnet[1].

Hans opsummering er godt i tråd med The MF Manifesto:

What's the moral of the story? [b]Beware of Methodologies[/b]. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them. It's pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald's, precisely because of McDonald's rules. So why do IT consultants brag so much about their methodologies? (Beats me.)

[1] http://www.joelonsoftware.com/articles/fog0000000024.html

I at forsøge at finde roden til rigtig programmering

http://www.pbm.com/~lindahl/real.programmers.html

Der angiveligt snart 30 år siden at man fandt det nødvendigt at forklare hvad en rigtig programmør var for noget.

Omkring rigtige programmeringssprog er dette link i øvrigt værd at kigge på http://www.ibm.com/ibm100/us/en/icons/fortran/

Jeg bliver provokeret af dette "manifest". Men det er sikkert også meningen med det.

Det kan være fair nok at være træt af den megen agile-snak og af de konkrete praktikker som nu er blevet udbredt. Men hvis vi ligefrem skal tale om en trend, så håber jeg ikke at folk generelt er så respektløse og egoistiske som denne Motherfucking Zed A. Shaw.

Han oplever åbenbart at folk bruger ordene fra de agile metoder, men i realiteten er ligeglade med andre mennesker og kvaliteten af den software der kommer ud i den anden ende.

Sjovt nok, det lyder som om Zed netop deler værdier med disse påtagede agilister?

En mere konstruktiv dialog ville være at diskutere f.eks. om "Working unit tests" virkelig er den bedste vej til "Working software" -- men den slags diskussioner ville selvfølgelig tage tid væk fra Zeds hellige kode-tid...

Martin, god historie !

Fra samme blog:

After a few dozen years, Youthful Programmer is now a Huge Incompetent IT Consultant with a capital-M-methodology and a lot of people who blindly obey the Methodology, even when it doesn't seem to be working, because they have no bloody idea whatsoever what else to do, and they're not really talented programmers -- they're just well-meaning Poli Sci majors who attended the six-week course.

Programmøer er ikke alene i verden, og det er ikke kunst de/vi producerer. Man producerer som regel til et firma hvor man dels har omkostninger ved produktionen af koden og dels har nogle omkostninger ved vedligeholdelse af koden. Hvis ikke man følger nogle standarder / metoder vil det være så godt som umuligt for efterfølgere at vedligeholde og udbygge kode.

At sige at metoder står i vejen for koden er primadonna nøkker af værste skuffe. Virksomheden bestemmer hvad der godt skik og god metode, programmører beslutter sig for hvordan firmaets metoder og politikker skal føres ud i livet.

At sige at metoder står i vejen for koden er primadonna nøkker af værste skuffe. Virksomheden bestemmer hvad der godt skik og god metode, programmører beslutter sig for hvordan firmaets metoder og politikker skal føres ud i livet.

Præcis, virksomheden bestemmer. Joel Spolsky har tydeligvis bestemt at at hans virksomhed vil satse på talent frem for regler. Det tvivler jeg på er et udtryk for primadonnanykker.

Jeg synes 'the motherfucking manifesto' er temmelig humoristisk men også rejser spørgsmålet om talent vs. metode.

I min ringe erfaring baseret på ren empiri vil jeg hellere have 1-2 talentfulde programmører på mit team end 5-9 almindelige programmører, der kender deres metoder, frameworks etc. Den talentfulde forstår at få det gode ud af metoder og frameworks, når det giver mening i situationen, medens metodetalebanere decideret er trættende og ofte også trættekære.

God fredag!

Interessant tanke...

Kunne godt forestille mig at det vil give nogle innovative løsninger - men også stort potentiale for kaos.

http://www.infoq.com/presentations/Leaner-Programmer-Anarchy

/Rasmus

Faldt lige over denneher

http://www.halfarsedagilemanifesto.org/

Det er en svær balancekunst at lade dem der i egen optik er "programming-superheroes" blomstre og levere kreative og gode løsninger, uden at man samtidig ser svære udbrud af vidensarrogance.
Maintainability og dokumentation af kode er tidt vigtig for dem der betaler, men totalt usexet for en der tænker at "enhver der ikke umidelbart kan læse mit eminente kodekunstværk ikke er værdig til at forstå den"...

Great programmers with a decent methodology will outperform mediocre programmers with a decent methodology any day...

Uden at skulle være politisk, vil jeg stille det skarpt op. Med frihed under ansvar, vil "paradigmet" virke. Med ansvar under frihed, vil det ikke virke. Her giver regler god mening.

Talent i sig selv, er ingen garanti for succes. Der er mange andre kompetencer i spil.