Page 1 of 2 1 2 LastLast
Results 1 to 15 of 20

Thread: Gestandaardiseerd programmeren

  1. #1
    Student
    Join Date
    Apr 2008
    Location
    Rijssen
    Posts
    45

    Gestandaardiseerd programmeren

    Hallo,

    Heeft er iemand een tip over een boek waarin wordt uitgelegd, hoe je tot een standaard kunt komen voor programmeren. Ook als met meerdere mensen aan een project wordt gewerkt.

    Ik heb namelijk een elektrotechnische achtergrond. En hebt dit dus niet geleerd, omdat programmeren geen hoofdvak was/is. Alle ideen en tips zijn welkom.

    Alvast bedankt
    JanM
    "Wat wij weten is een druppel, wat wij niet weten een oceaan."

  2. #2
    Ik vraag me af of daar een boek voor is. Als programmeren te standaardiseren is heb je geen programmeurs meer nodig, die kun je dan automatiseren.

    In mijn tijd (20 jaar geleden) kreeg je wel ontwerp methoden aangeleerd, o.a. Yourdon was toen populair.

    Tegenwoordig zie je meer agile ontwikkelmethodieken, gericht op korte cycli en een grote betrokkenheid van de klant. Over agile zijn zat boeken en artikelen te vinden.

    Wat werken aan code met meerdere mensen betreft, daar zijn afspraken denk ik het belangrijkste. Zoek eens naar code guidelines bij de diverse open source projecten, daar heb je als voorbeeld het meeste aan denk ik.

  3. #3
    Senior Member Thaddy's Avatar
    Join Date
    Dec 2004
    Location
    Amsterdam
    Posts
    2,211
    UML rules als standaard. (Heeft inderdaad Yourdon ook nog wat mee te maken gehad, vandaar de U van unified).
    Agile heeft daar niets of heel weinig mee te maken: je moet wel een sluitend stuk papier houden, al was het alleen maar voor je rekening! Agile vereist alleen meer flexibiliteit (en leidt tot ongelukken, maar men zegt die dan te accepteren). Agile is een implementatie, geen methode. En het is al weer op de weg terug vanwege het ontbreken van methode.
    De meeste agiles beginnen meteen - niet gehinderd door enige wetenschapsfilosofische achtergrond -met iets te maken en dan duurt het door het ontbreken van begrip van wat de klant wil veel te lang om betaalbaar een product te kunnen leveren. Als er eenmaal een product is, mag iedereen van mij agilen.....

    Vooral overheden zijn gek op agile en vragen nooit naar substantie. En vooral overheden (en de "big three" automatiseerders) zijn er gek op! Geld verdienen/laten verdwijnen waar je op kunt rekenen. In dat opzicht is agile wel een methode. Geen mening, maar feit.

    Zoals mijn 82 jarige moeder - en Delphi hobby programmeur met meer dan 10 jaar ervaring, echt waar! - zegt over haar brouwsels:
    "Debuggen snap ik niet, ontwerpen ook niet, maar als ik er lang genoeg mee werk crashed het ook niet en weet ik weer wat mijn bedoeling was."

    So far voor agile.
    Last edited by Thaddy; 17-Jan-12 at 01:13. Reason: moeder (is echt waar!)
    Werken aan Ansi support voor Windows is verspilde tijd, behalve voor historici.

  4. #4
    Wat een nonsens-redenatie. Als je een grote, dikke applicatie wilt bouwen volgens een groot dik FO, zal het vast sneller zijn om dit van voor tot achter te implementeren. Via een agile methode zul je dan meer tijd kwijt zijn.

    Het verschil is alleen dat je met agile niet hetzelfde eindresultaat krijgt. Je krijgt namelijk eerst wat je het hardst nodig hebt, en gaandeweg worden dingen aan je wensen aangepast, toegevoegd, of misschien verwijderd of nooit geïmplementeerd omdat je wensen veranderen (of vooral: uitkristalliseren, gaandeweg duidelijk worden).

    Ik werk sinds iets meer dan een jaar ook op die manier en het is vooralsnog duidelijk dat het effectief is. Dat is te zien in de hoeveelheid werk die opgeleverd wordt (zowel in regels code als gevoelsmatig), maar ook in het enthousiasme bij de rest van het bedrijf (wat voor onze afdeling de klant is), en in de bedrijfsresultaten. We zien het ook heel sterk in de hoeveelheid werk die niet gedaan wordt. De hoeveelheid knopjes die we in het verleden hebben gemaakt en die bij nader inzien nooit gebruikt worden, was schrikbarend hoog. Het afgelopen jaar is het aantal nieuwe ongebruikte functionaliteiten nihil. En daar zit denk ik de grootste winst bij agile.

    Nou wil ik uiteraard geen vervelende dingen over je moeder zeggen, maar ik heb het idee dat je moeder niet in die zin agile werkt. Misschien heeft ze gewoon geen aanleg voor programmeren, of -mogelijk door haar leeftijd- kan ze zich iets minder snel deze kennis eigen maken en moet ze daardoor nog als beginner beschouwd moet worden.
    Je ziet ze weleens: mensen waar je dingen aan uit kunt blijven leggen, maar die nooit de dieperliggende gedachte achter programmeren, ontwerpen, of programmeren in het algemeen zullen begrijpen, hoeveel jaren ervaring ze ook in hun profiel hebben ingevuld. Het maakt bij deze mensen niet echt uit wat voor model of methode ze gebruiken.

    Beginner, devibeet... Nou gun ik iedereen z'n hobby, en je moeder is vast een schat van een mens, maar ik voel me onwillekeurig toch aangesproken als je me in dat hokje probeert te duwen.
    Last edited by GolezTrol; 17-Jan-12 at 10:18.
    1+1=b

  5. #5
    Volgens mij hangt de juiste methode erg van het soort project af, maar zeker ook van het team. Een methode waar alles vooraf is beschreven is mooi, maar het probleem blijft dat de realiteit vaak alweer is achterhaald wanneer iets eenmaal is gebouwd, dat leidt dus tot ongebruikte knopjes.

    In een agile (of zelfs scrum) opzet voorkom je dat, maar het eist veel meer van het team. Van een ontwikkelaar wordt geacht dat hij meedenkt in het process en al voordat hij aan het bouwen is zaken herkent. Daarnaast moeten zaken flexibel worden gebouwd zodat een latere aanpassing inderdaad een aanpassing is en geen herbouw.

    Van een teamleider wordt verwacht dat hij direct en kort kan communiceren, zowel met de klant als met de ontwikkelaar. Dus geen lang document, maar een korte alinea en geen "misschien dit en dat volgende maand" maar "dit zeker morgen".

    Een agile opzet vergt dus veel meer van het team (aan de kant van de ontwikkeling en aan de kant van de klant) maar levert in mijn ervaring een product op dat veel dichter bij de klant staan.
    Marcel

  6. #6
    Senior Member Thaddy's Avatar
    Join Date
    Dec 2004
    Location
    Amsterdam
    Posts
    2,211
    Laat ik het zo zeggen:
    Iedereen in zijn waarde, maar voor projecten tussen de 30.000,-(ex onderhoud) (das 2 maanden f.t hier) en max (10.000.000+ in mijn geval met een zeer groot team) is agile onzin en heeft het zijn waarde al lang tot nul gereduceert.
    Mijn mam maakt adresdatabeestjes, foto albums e.d. en die werken. Als je je aangesproken voelt moet je dat zelf weten. Het gevaar is namelijk dat je te groot gaat en er dan pas achter komt dat je de boel moet weggooien.
    Ja, ik ben erg voorzichtig maar ik durf dan ook fixed price te werken, ook voor hele grote opdrachten. Met agile moet ik de eerste nog tegen komen.
    Werken aan Ansi support voor Windows is verspilde tijd, behalve voor historici.

  7. #7
    Agile kan natuurlijk best fixed price, maar dan op kleine onderdelen. Maar om je eigen woorden aan te halen: fixed price is zooo 1989 . En de klant, het bedrijf, de organisatie die 100% vooraf kan vastleggen wat er gedaan moet worden moet ik nog tegenkomen. Zowel kleine als grote organisaties zijn daar simpelweg niet toe in staat. Dus fixed price is altijd fixed price voor de 1.0, daarna komen toch de meerwerkopdrachten als gevolg van voortschrijdend inzicht..
    Marcel

  8. #8
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Marcel View Post
    Volgens mij hangt de juiste methode erg van het soort project af, maar zeker ook van het team. Een methode waar alles vooraf is beschreven is mooi, maar het probleem blijft dat de realiteit vaak alweer is achterhaald wanneer iets eenmaal is gebouwd, dat leidt dus tot ongebruikte knopjes.

    In een agile (of zelfs scrum) opzet voorkom je dat, maar het eist veel meer van het team.
    In agile MOET je meer uit je team halen om quitte te spelen. Maar in Waterfall kan motivatie en leiderschip ook rendabel zijn (en door vaardig sturen van de vergaderingen b.v. het knopjesaka design-by-committee aka eierlegende wollmichsau syndroom te bezweren).

    Als je angst voor falen nodig hebt om je team te motiveren, heb je dus duidelijk meer baat bij agile :-)

    Waterfall is daarnaast ook meer defensief. Op het moment met een meningsverschil met de klant heb je iets om ergens op terug te vallen. Het valt op dat agile teams vaak intern werken.

  9. #9
    Angst voor falen? Aan je laatste opmerking te zien geldt dat juist meer voor waterval. Waar zou je op terug moeten vallen als je klant heel de tijd bij je project is betrokken en op elk moment kan bijsturen (of desnoods de stekker eruit trekken), in plaats van aan het eind ineens met een duur product te zitten dat niet doet wat hij wil?

    Agile teams werken denk ik vaak intern, omdat die interne afdeling er in de eerste plaats al is om sneller op veranderingen in te kunnen springen dan wanneer je je software extern laat maken. Als je een software bureautje hebt, met klanten die verwachten (op basis van hoe het nu eenmaal gaat) dat ze eerst een krabbel zetten onder een dik saai document en dan een halfjaar later een cd-rommetje in de bus krijgen, dan is de kans dat je gaat investeren in een andere manier van werken niet zo groot. En de noodzaak misschien ook niet.
    1+1=b

  10. #10
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by GolezTrol View Post
    Angst voor falen? Aan je laatste opmerking te zien geldt dat juist meer voor waterval.
    Nee hoor. Indien het indekken een realistische casus is, dan is dat geen angst voor falen. Er is een verschil tussen niet bang zijn en roekeloos zijn.

    Waar zou je op terug moeten vallen als je klant heel de tijd bij je project is betrokken en op elk moment kan bijsturen (of desnoods de stekker eruit trekken),
    Ja, en bij een theoretische ideale klant die perfect weet wat ie wil, en intern helder en eensgezind communiceert is dat ook zo. En eenhoorns zijn ook zeldzaam :-)

    in plaats van aan het eind ineens met een duur product te zitten dat niet doet wat hij wil?
    Die twee argumenten (klant kan op elk moment bijsturen, en klant kan blijven zitten met een duur product dat ie niet wil) zijn niet mutueel exclusief.

    Agile teams werken denk ik vaak intern, omdat die interne afdeling er in de eerste plaats al is om sneller op veranderingen in te kunnen springen dan wanneer je je software extern laat maken.
    En omdat je niet voor fixed price werkt (waarbij je zelfs bij een succesvol project met verlies kan blijven zitten), en een zich aanstellende klant via gedeeld management ter orde geroepen kan worden, en waar bij problemen de eerste paar keer nog een oogje dichtgeknepen wordt (aka "het is een heel moeilijk project, dat begrijp ik")

    Maar met name het eerste, dat mis ik geheel in verhaal tot nu toe. Daar wordt er systematisch van uitgegaan dat een halleluja bij de klant zich in klinkende knaken omzet.

    Als je een software bureautje hebt, met klanten die verwachten (op basis van hoe het nu eenmaal gaat) dat ze eerst een krabbel zetten onder een dik saai document en dan een halfjaar later een cd-rommetje in de bus krijgen, dan is de kans dat je gaat investeren in een andere manier van werken niet zo groot. En de noodzaak misschien ook niet.
    Been there, done it all, got the t-shirt. O.a. toen ik intern ergens werkte. Agile is nu niet bepaald ZO nieuw en revolutionair :-)

  11. #11
    Quote Originally Posted by marcov View Post
    Ja, en bij een theoretische ideale klant die perfect weet wat ie wil, en intern helder en eensgezind communiceert is dat ook zo. En eenhoorns zijn ook zeldzaam :-)
    Maar als de klant het al niet weet (en dat ben ik zoals ik al schreef met je eens), dan kun je toch nooit dat dikke document vooraf schrijven?
    Marcel

  12. #12
    Dat is inderdaad het probleem met waterval. Aan het eind van de rit heb je precies wat er vooraf is afgesproken...
    1+1=b

  13. #13
    Student
    Join Date
    Apr 2008
    Location
    Rijssen
    Posts
    45
    Iedereen in ieder geval bedankt voor de reacties.
    Mijn vraag is nu een beetje bijgesteld nadat ik op internet een beetje ben gaan lezen over de watervalmethode en agile methode.

    Ik ben echter iemand die graag op de bank mag zitten met een goed boek hierover . Hebben jullie dan nog een tip voor mij, ben dus op zoek naar een boek over 'methodes voor softwareontwikkeling'.

    Alvast bedankt.
    "Wat wij weten is een druppel, wat wij niet weten een oceaan."

  14. #14
    Quote Originally Posted by janm7462 View Post
    Hebben jullie dan nog een tip voor mij, ben dus op zoek naar een boek over 'methodes voor softwareontwikkeling'.
    Tuurlijk
    De beste manier om te leren is door fouten te maken.
    80 procent van alle leugens die jij en ik vertellen blijft onopgemerkt

  15. #15
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Marcel View Post
    Maar als de klant het al niet weet (en dat ben ik zoals ik al schreef met je eens), dan kun je toch nooit dat dikke document vooraf schrijven?
    Je beschrijft wat je gaat doen. En daar houd je je aan. Daarmee kan je terugschrijdend inzicht mee afkappen.

    Deels is het een beetje als de GPL. Openbreken kan, maar je moet dan wel aan tafel gaan zitten om te onderhandelen (hoeft niet perse financieel te zijn overigens. Kan ook herformuleren van kerndoelen in een geven en nemen zijn).

    Afwijken van specs kan moeilijker sluipend gebracht worden, wat kostenoverschrijdingen teweeg brengt.

    En dat gebeurt ook regelmatig.

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •