[Alg] 'Angst' om te beginnen door perfectionisme*

[Verwijderd]

Ik persoonlijk zie software ontwikkelen als een soort kunstvorm. Ik wil er graag altijd wat bijzonder moois van maken en daarmee bedoel ik niet de applicatie zoals de gebruiker die ziet en ervaart (althans, niet in de eerste plaats), maar juist het schrijven van de code en het totale technische model. Het probleem is echter, die wens veroorzaakt een zekere 'angst' om aan een project te beginnen. De 'angst' om een bepaalde weg in te slaan die later in het ontwikkeltraject misschien niet de beste is gebleken en dat het via een andere weg nog mooier had gekund. Zo kan het bij mij voorkomen dat ik een bepaalde module volledig herschrijf, terwijl de oorspronkelijke module voor wat betreft de bruikbaarheid perfect voldoet.

Dit is uiteraard bijzonder inefficiënt, maar het schijnt meer voor te komen onder software-ontwikkelaars. Herkennen mensen dit 'ontwikkelperfectionisme'? Op welke manier kan de 'angst om het niet mooi genoeg te doen' worden geneutraliseerd?

[ Voor 3% gewijzigd door Verwijderd op 12-02-2006 17:39 ]

[NMe]

Door je code te backuppen op kritieke punten in je ontwikkelproces?

[Verwijderd]

-NMe- schreef op zondag 12 februari 2006 @ 17:39:
Door je code te backuppen op kritieke punten in je ontwikkelproces?

Dat doe ik sowieso altijd, maar het gaat er meer om dat ik altijd een soort frustratie ervaar met betrekking tot de elegantie van datgene wat ik op dat moment aan het schrijven ben of reeds heb geschreven. Terwijl ik aan het tikken ben ben ik met mijn gedachten al bij mogelijke alternatieve ontwerpen die het probleem nog eleganter oplossen.

[Wim Leers]

Misschien dan wat meer brainstormen, mindmappen etc vóórdat je begint? In de trant van 'Bezint eer ge begint.'

[Bluestorm]

Misschien moet je eens kijken naar refactoring, etc. zodat je er wat meer vertrouwen in krijgt dat een eventuele minder elegante oplossing altijd nog weer verbeterd kan worden mocht het niet helemaal doen wat je wilt. Een keertje wat herschrijven kost vaak minder tijd dan er oneindig over nadenken terwijl je toch niet in de toekomst kunt kijken.

(Bij mij persoonlijk helpen deadlines erg goed tegen perfectionisme )

[ Voor 10% gewijzigd door Bluestorm op 12-02-2006 17:47 ]

[Clock]

Hehe, bijzonder probleem

Ikzelf heb altijd dat ik heel gestructureerd begin, alles zeer netjes neerzet en documenteer, maar naarmate het project vorderd wordt het steeds slordiger. Wat in het begin alle mogelijke mogelijkheden leek te dekken werkt toch niet helemaal zoals ik het wil. En soms blijf ik dan ook eindeloos herschrijven en opnieuw bekijken.

[SeatRider]

Bashrat schreef op zondag 12 februari 2006 @ 17:44:
Misschien dan wat meer brainstormen, mindmappen etc vóórdat je begint? In de trant van 'Bezint eer ge begint.'

^^ Met stom

Maak eerst een FO/TO en ga daarna kloppen.

Of leg je er bij neer dat het *altijd* beter kan. Ik heb mij er zelf op een gegeven moment bij neergelegd dat het er in de eerste plaats om gaat of de klant het accepteert, niet of een bepaalde regel code misschien nog netter had gekund.

[Michali]

De term die je zoekt is Agile. Dat is ontwikkelen op zo'n manier dat je per definitie rekening houdt met eisen die gaan wijzigen. En ze zullen wijzigen in bijna alle gevallen. Refactoring is daar idd heel nauw mee verbonden, maar het is een beter idee om dat te combineren in de context van een Agile methodologie. Misschien een idee om daar iets over op te zoeken?

[Verwijderd]

VisaRider schreef op zondag 12 februari 2006 @ 18:09:
[...]

^^ Met stom

Maak eerst een FO/TO en ga daarna kloppen.

Of leg je er bij neer dat het *altijd* beter kan. Ik heb mij er zelf op een gegeven moment bij neergelegd dat het er in de eerste plaats om gaat of de klant het accepteert, niet of een bepaalde regel code misschien nog netter had gekund.

Nou, zelfs met een goed uitgewerkte FO/TO ervaar ik het probleem. Ik noem een eenvoudig voorbeeld: de naamgeving van een variabele. Dan denk ik: is die goed genoeg, is die te lang, is de te algemeen, is die uberhaupt nodig enzovoort. En ook waar ik de variabele declareer en wat de mooiste volgorde is van de declaraties enzovoort. Het gaat om de kleinste mierenneukerij.

[Michali]

Dan moet je echt gaan kijken naar boeken als Refactoring en Code Complete. Die nemen je twijfels weg en geven je een logische kijk op wat goed is en wat minder. Ik denk dat je je dan heel wat beter voelt bij je beslissingen. Een goed IDE is overigens ook niet verkeerd. Vooral eentje die refactoring gemakkelijk maakt, door bijvoorbeeld het wijzigen van een variabel naam door te voeren op alle plaatsen waar hij gebruikt wordt. Dat scheelt je ook veel tijd.

[JHS]

Michali schreef op zondag 12 februari 2006 @ 18:12:
Misschien een idee om daar iets over op te zoeken?

[rml][ Alg] Agile development[/rml] .

[whoami]

Software schrijven is niet iets waar je aan kan beginnen, en dan direct de 'juiste' weg inslaan, of direct een 'perfect' model / structuur whatever hebben.
Software schrijven is een proces; je source-code is iets organisch. Het groeit, je verbetert het, etc... Je kan niet verwachten dat het vanaf de eerste keer 100% goed is of klopt, want dat is gewoon niet mogelijk. Je structuur of model zal ook nooit voor de volledige 100% goed zijn / kloppen.
Je zult altijd bepaalde dingen moeten overwegen, trade-offs maken tvv performantie, onderhoudbaarheid , etc...

De term die hier al gevallen is, is idd refactoring. Je code veranderen, zonder dat je er functionaliteit aan toevoegt. De structuur van je code veranderen. Het kan zelfs zo iets stoms zijn als het wijzigen van de naam van een bepaalde method.
Een hulpmiddel bij refactoring, zijn unit-tests. Hiermee kan je nagaan of je functionaliteit nog goed is, na de (structuur)-wijzigingen die je doorgevoerd hebt.

Maar als je 'angst om te beginnen hebt', dan ben je eigenlijk niet goed bezig. Als je maar blijft denken, analyseren, etc..., dan komt het er nooit van en dan heb je zowiezo geen software die de eisen van de klant inlost. Je hebt ook zo iets als 'paralysis by analysis'.

[EfBe]

Verwijderd schreef op zondag 12 februari 2006 @ 17:38:
Dit is uiteraard bijzonder inefficiënt, maar het schijnt meer voor te komen onder software-ontwikkelaars. Herkennen mensen dit 'ontwikkelperfectionisme'? Op welke manier kan de 'angst om het niet mooi genoeg te doen' worden geneutraliseerd?

Door zelf de rekening te betalen van de tijd die je steekt in software development. Op een gegeven moment kom je er achter dat er een balans is tussen perfectionisme en pragmatisme: er zijn helaas altijd factoren binnen een project die bepalen dat je niet het perfecte programma kunt maken, maar slechts het 'best haalbare'. Door pragmatisch om te gaan met de mogelijkheden die je hebt en de limieten waarmee je moet werken kun je EN goed resultaat afleveren EN toch iets afkrijgen.

Ik zie overigens het pragmatisch kunnen oplossen van een probleem ook als eigenschap van een goede software engineer. Je kunt nl. een probleem vaak op vele manieren oplossen en dan de oplossing kiezen die het meest efficientst is qua kwaliteit en tijdsinvestering (dus niet OF, maar EN) is IMHO de beste oplossing.

Staar je niet blind op die OH-sessies van wat ik 'cleanroom specialisten' noem: mensen die oplossingen verzinnen die perfect werken in een volledig gecontrolleerde omgeving maar die volledig voorbij gaan aan factoren waar je IRL mee te maken hebt in een project. Een software project heeft nu eenmaal een paar factoren waar je niet onderuit kunt. Zoals men zegt: "Your project can be: Efficient, cheap and perfect. Pick 2" (of van die strekking).

Verwijderd schreef op zondag 12 februari 2006 @ 17:41:
[...]
Dat doe ik sowieso altijd, maar het gaat er meer om dat ik altijd een soort frustratie ervaar met betrekking tot de elegantie van datgene wat ik op dat moment aan het schrijven ben of reeds heb geschreven. Terwijl ik aan het tikken ben ben ik met mijn gedachten al bij mogelijke alternatieve ontwerpen die het probleem nog eleganter oplossen.

Nou en? Denk je echt dat dat over gaat op je 45e nadat je JAAAAREN van alles gedaan hebt? no way. Ik maak nu 12 jaar professioneel software en ik heb ook dagen dat ik denk "waarom heb ik dit in vredesnaam zo opgelost?" (ik werk met mn eigen code, dus kan alleen mezelf de schuld geven ) . Er is echter 1 ding dat je niet moet vergeten: een goed stukje code wat gewoon werkt, is een goed stukje code. Een GEWELDIG stukje code wat hetzelfde resultaat heeft, heeft nog steeds hetzelfde resultaat.

Michali schreef op zondag 12 februari 2006 @ 18:12:
De term die je zoekt is Agile. Dat is ontwikkelen op zo'n manier dat je per definitie rekening houdt met eisen die gaan wijzigen. En ze zullen wijzigen in bijna alle gevallen. Refactoring is daar idd heel nauw mee verbonden, maar het is een beter idee om dat te combineren in de context van een Agile methodologie. Misschien een idee om daar iets over op te zoeken?

Refactoring is niet gratis, het kost tijd en als je niet oppast ERG veel tijd. Er zijn class hierarchies te bedenken die bij het begin van het project volledig logisch leken maar na 3 kwart van het project moet je ineens iets erbij bouwen waardoor het handiger zou zijn geweest als je het ANDERS gedaan had. En de classes dan refactoren is niet aan te bevelen, tenzij je unlimited funding hebt en tijd (en dan nog).

Agile development is overigens ook niet iets wat deadlines, tijdtekort, en gebrek aan geld doet verdwijnen. Je hebt nog altijd te maken met die factoren en die zijn t.a.t. de factoren die bepalend zijn voor de kwaliteit. Tenzij je toch wel betaald krijgt natuurlijk of je wel of niet iets oplevert (zoals de gemiddelde consultant). Wanneer het opleveren van iets essentieel is voor wat je als beloning krijgt voor je werk, dan is het zaak rekening te houden met de factoren die ik net noemde, en is perfectionisme een leuke eigenschap voor de buhne maar gebruik het met mate, zoals ik zei: in balans met pragmatisme.

[ Voor 49% gewijzigd door EfBe op 12-02-2006 21:28 ]

[Michali]

Als je een nieuwe class set nodig hebt en je gaat er naar refactoren, dan is het eigenlijk ook geen refactoren meer, omdat je eigenlijk naar nieuwe functionaliteit toe werkt, iets dat bij refactoring per definitie niet het geval is. (Of je moet er een eigen proces van maken.) Refactoren bedoelde ik ook meer in de zin van het zo duidelijk en losgekoppeld (maar wel op een pragmatische manier) houden van je code, zodat je later bij wijzingen er weer (hopelijk) minder tijd bij kwijt bent. Als je refactoring goed (en pragmatisch) toepast, dan ben je uiteindelijk alleen maar minder tijd kwijt, al is dat een beetje moeilijk te meten of te bewijzen.

Verder denk ik dat agile development je zeker kan helpen bij het verminderen van angst tot verkeerde beslissingen. Verder is ervaring ook een goede manier (iets waarover ik maar een beetje mee kan praten), maar ook uit boeken is een hoop bruikbare informatie te halen die er voor zorgt dat je sneller de juiste beslissingen maakt.

[D4Skunk]

Enkele tips vanuit mijn persoonlijke ervaring:
- zet een duidelijk gestructureerde basis op, ook al lijkt het niet nodig. In mijn geval is MVC meestal genoeg, of zoals Einstein all zei : "Everything should be made as simple as possible, but not simpler". IMHO kan je dit enkel leren dmv ervaring... Zorg voor een uniforme aanpak, maar ga bv geen plugin-systeem schrijven als dit niet ECHT nodig is.
- ga voorbij aan het 'not invented here' syndroom. Als er een bepaalde technologie voorhanden is, waarom zou je ze dan niet gebruiken, ook al kost ze wat $$/€€ ? Reken maar eens uit hoeveel het je kost in werkuren als je zelf iets moet ontwikkelen.
- werk in stappen. Meestal zie je bij klanten dat ze heel veel willen. Begin bij de basis, en lever daar een prototype van, zo loop je nooit het risico dat zij of jij het concept verkeerd interpreteren. Zorg ook dat bij elke stap alle zoveel mogelijk bugs uit het systeem zijn. Zo vermijd je de kans dat je op het einde enkel saai werk moet doen, en je motivatie keldert. Dit heeft ook als voordeel dat je een tussentijds afrekening kan maken.
- leg alles vast op papier... duidelijke afspraken vermijden misverstanden/frustraties achteraf.
- besteed uit wat een ander beter/sneller/goedkoper kan... (mijn persoonlijk probleem - hier heb ik al VEEEEL tijd mee verloren, oa logo design/ engelstalige website/...)

Tot slot, omdat we toch al aan het quoten waren :

Sun Tzu - The Art of war : "Opportunities multiply as they are seized"

[Verwijderd]

Heerlijk, sourcesafe van microsoft. Slaat elke keer netjes een nieuwe versie op als ik mijn werk opsla, zo kan ik terug gaan naar elke wijziging die ik gedaan heb

[kenneth]

En als je fatsoenlijke en gratis versiebeheer wil, is er ook nog Subversion

[Cyphax]

whoami schreef op zondag 12 februari 2006 @ 20:51:
Software schrijven is niet iets waar je aan kan beginnen, en dan direct de 'juiste' weg inslaan, of direct een 'perfect' model / structuur whatever hebben.
Software schrijven is een proces; je source-code is iets organisch. Het groeit, je verbetert het, etc... Je kan niet verwachten dat het vanaf de eerste keer 100% goed is of klopt, want dat is gewoon niet mogelijk. Je structuur of model zal ook nooit voor de volledige 100% goed zijn / kloppen.
Je zult altijd bepaalde dingen moeten overwegen, trade-offs maken tvv performantie, onderhoudbaarheid , etc...

Hangt dat niet een beetje af van welke methode je gebruikt om te ontwikkelen? (sommige zijn er erg op geprat dat je eerst alles ontwerpt, dat bevriest en vervolgens gaat implementeren zonder dat het geheel blijft groeien/evolueren)

Ik merk dat ook weleens, dat ik ergens aan begin en dan halverwege denk "ik had dit anders moeten doen" en dan vervolgens delen opnieuw schrijf. Dat kost zeker tijd maar het is niet snel een kwestie van helemaal opnieuw beginnen. Hoe dan ook, zo uit de losse pols gaan ontwikkelen kan eigenlijk nooit echt goed gaan, zeker bij ingewikkelde projecten (en toch doen velen (met name hobbyisten heb ik de indruk) dat).

[whoami]

Ik zeg ook niet dat je zomaar direct moet beginnen met programmeren. Natuurlijk moet je eerst een analyse hebben, en moet je weten wat de requirements zijn, en moet je eerst goed nadenken over de structuur die je nodig hebt.
Echter, wat ik wel wil zeggen, is dat je initiële design waarschijnlijk niet vanaf de eerste keer goed zal zijn. Misschien zal het wel voldoen aan de initiële requirements, maar requirements veranderen, en dus zal je design hoogstwaarschijnlijk ook moeten veranderen / mee-evolueren.

[Cyphax]

whoami schreef op dinsdag 14 februari 2006 @ 12:37:
Ik zeg ook niet dat je zomaar direct moet beginnen met programmeren. Natuurlijk moet je eerst een analyse hebben, en moet je weten wat de requirements zijn, en moet je eerst goed nadenken over de structuur die je nodig hebt.
Echter, wat ik wel wil zeggen, is dat je initiële design waarschijnlijk niet vanaf de eerste keer goed zal zijn. Misschien zal het wel voldoen aan de initiële requirements, maar requirements veranderen, en dus zal je design hoogstwaarschijnlijk ook moeten veranderen / mee-evolueren.

Daar reageerde ik in eerste instantie op.
Tijdens mijn opleiding is steeds besloten (niet door ons overigens) het watervalmodel toe te passen waarbij je gewoon op gegeven moment je design bevriest: dat wordt het, en niets meer (da's wel erg strict, maargoed). Ik ben echter meer voorstander van wat jij beschrijft omdat het vaak lastig is alle requirements vooraf op zo'n niveau te definieren dat je 't echt KAN bevriezen.

[Verwijderd]

Bedankt voor de vele reacties!

Wat ik mij ook afvraag. In hoeverre kan werkdruk er mee te maken hebben? Wat zouden jullie zien als gemiddeld aanvaardbaar hoeveel projecten er op ongeveer hetzelfde moment lopen en waarvan de deadlines vrij dicht bij elkaar liggen? Met andere woorden: wat is aanvaardbaar met betrekking tot het aantal parallelle projecten tijdens een bepaalde tijdsperiode?

[EfBe]

Verwijderd schreef op dinsdag 14 februari 2006 @ 13:22:
Bedankt voor de vele reacties!

Wat ik mij ook afvraag. In hoeverre kan werkdruk er mee te maken hebben? Wat zouden jullie zien als gemiddeld aanvaardbaar hoeveel projecten er op ongeveer hetzelfde moment lopen en waarvan de deadlines vrij dicht bij elkaar liggen? Met andere woorden: wat is aanvaardbaar met betrekking tot het aantal parallelle projecten tijdens een bepaalde tijdsperiode?

Dat is natuurlijk niet te verwoorden in een omlijnd getal, omdat dat voor iedereen EN voor iedere set projecten verschillend is. Meerdere projecten tegelijk doen is goed mogelijk maar je concentratiespanne mbt een project is het makkelijkst vast te houden (IMHO) als je langere tijd aan een project kunt werken, dus niet om het uur switchen, maar bv om de paar dagen. Merk je dat het switchen naar een ander project je opbreekt bij het huidige project waar je op dat moment mee bezig is, dan kun je wellicht beter wat in de planning schuiven. Keyword: planning, dus je kunt alleen schuiven met tijdsindelingen, niet gewoon 'ik heb nu meer zin in dit' en dus meer tijd aan iets besteden dan voorzien, want dan kom je in de problemen.

Overigens is dit niet anders dan verschillende onderdelen binnen een project, bv GUI + BL tier + bv tests. Of onderdelen binnen een BL tier bv. Ikzelf doe nu een aantal van die onderdelen tegelijk met allemaal dezelfde deadline (runtime libs, designer, templates, code generator engine, drivers) en dan is het zaak om per functionaliteitsonderdeel te werk te gaan (althans dat werkt IMHO het best), dus als een functionaliteitsonderdeel 3 van die onderdelen raakt, dan moeten ze alledrie worden aangepast. Met grotere teams waarbij ieder onderdeel is ondergebracht in een apart team moet je dan soms wachten op het resultaat van dat andere team. Dat kan dan bv de tijd scheppen om iets wat je al moest doen dan te gaan doen.

Maar alles valt en staat bij planning.

[PhoneTech]

[sarcasme]Ik heb een manager die me de huid volsched dat ik de lang bezig ben op een onderdeel goed te krijgen...[/sarcasme]

[ Voor 10% gewijzigd door PhoneTech op 14-02-2006 22:33 ]

[Verwijderd]

PhoneTech schreef op dinsdag 14 februari 2006 @ 21:37:
Ik heb een manager die me de huid volsched dat ik de lang bezig ben op een onderdeel goed te krijgen...

Maar meestal zijn dat dezelfde managers die je huid volschelden dat je te lang bezig bent later de troep op te ruimen... kosten gaan voor de baten uit!

[PhoneTech]

Verwijderd schreef op dinsdag 14 februari 2006 @ 21:55:
[...]

Maar meestal zijn dat dezelfde managers die je huid volschelden dat je te lang bezig bent later de troep op te ruimen... kosten gaan voor de baten uit!

Misschien had ik de sarcasme tags vergeten

[Verwijderd]

Niks mis met het streven naar perfectionisme, maar 't wordt wat lastig wanneer dat tot gevolg heeft dat je project niet van de grond komt of niet op tijd wordt afgeleverd...
Ik heb als voordeel dat ik werk voor een bedrijf dat in principe geen maatwerk levert, maar alleen standaard software, en dan kun je vaak wat meer tijd uittrekken voor een implementatie die 't niet alleen doet, maar die ook nog 's "esthetisch verantwoord" in elkaar zit. Ik werk nl. niet alleen voor het geld, maar vooral voor de voldoening die 't mij biedt, en een mooi stukje werk is dan best belangrijk.

Maar toch kom ik regelmatig haastklussen, etc. tegen, en dan moet je doodgewoon een deadline halen. En dan neem je soms shortcuts...
Ik voeg dan altijd 2 soorten comments toe aan m'n code:
- OFU, open for update (code werkt voor deze klus, maar moet waarschijnlijk aangepast worden om in het algemeen te werken) en
- OFR, open for refactoring (aanpassingen aan bestaande objectstructuur vergden teveel knip/plak acties om nog zonder krullende tenen te kunnen bekijken).

Als de deadline druk dan wat van de ketel is, lopen we die OFU/OFR comments langs en schonen de code op.
Voor mij werkt dit prima, maar voor een collega van mij is alleen het plaatsen van een OFU comment al genoeg om 'm volledig van slag te krijgen. Dat is dus iemand die we bij voorkeur niet op een deadline-project zetten, hij is immens veel nuttiger bij research, code reviewing en refactoring.