[Alg] Hoe omgaan met slechte code van collega's?

[user109731]

Hoi

Ik doe naast mijn studie Wiskunde & Informatica wat werk voor een klein bedrijfje (~5 man). De sfeer en alles is okee, maar het probleem is dat er naar mijn idee teveel geprutst wordt en de code daarom vaak bagger is.

Paar voorbeelden:

• De sneltoetsen CTRL-C/CTRL-V worden enorm veel gebruikt. Het resultaat is dezelfde code op tig plekken, vrijwel altijd iets dat prima in een mooie functie/class gegoten had kunnen worden.
• Stel ik schrijf een (algemene) class om PDFs te genereren, dan ben ik er vrijwel zeker van dat daar code in gehackt gaat worden voor één soort document. Resultaat: mijn mooie class is onbruikbaar geworden voor andere bestanden (is dat toch nodig dan wordt bovenstaande techniek toegepast...)
• OOP-concepten als inheritance, interfaces, e.d. worden niet gebruikt.
• C-style boolean of integer return waarden in Java/C# (en pointers ipv references e.d. in C++) in plaats van exception handling. De meeste functies hebben een try ... catch block die errors logt en false teruggeeft... Of C-style lijst met int-constantes ipv enum's.
• Business-logica en database code staat vrolijk tussen GUI-code, etc...
• Concurrency issue? "Oja, je hebt gelijk, maar de kans dat dat echt misgaat is in de praktijk maar klein..."

Al met al werkt men dus enorm (imho té) pragmatisch (als het maar werkt...) en wordt er bijna niet nagedacht over het design van de code. Ik ben echt niet overdreven van de design patterns, layering, etc. maar ik probeer m'n code wel gewoon overzichtelijk, herbruikbaar en zoveel mogelijk zonder copy/paste op te zetten.

Het bedenken van een goed design en dit omzetten in nette code zijn toch de leukere kanten van het programmeren. Dan is het enorm frustrerend en demotiverend als collega's puur gaan voor 'iets dat werkt' en daarvoor telkens jouw code verkrachten

Zijn er tweakers die dit herkennen? Hoe ga je om met aanmodderende collega's of brakke code?
Heeft het zin om ze te overtuigen of ben je er maar mee gestopt of zelfs bij het bedrijf vertrokken?

[Verwijderd]

Als het meer regel dan uitzondering is binnen een bedrijf zou ik snel mijn biezen pakken. Programmeren is echt een vak en je gaat dit niet in je eentje leren aan 5 man in x weken, daar heb je gewoon echt een opleiding voor nodig. Misschien dat je 1 persoon nog wat bij zou kunnen brengen, maar niet een geheel bedrijf.

Verder spreek ik er mensen meestal gewoon op aan op het moment dat ze iets, in mijn ogen, onlogisch hebben gedaan. Ik verwacht dat ze dit bij mij ook doen. Je bent er om te leren.

[Refro]

Yep herken het. Hebben jullie coding guidelines? En ook omschreven hoe code gemaakt dient te worden design? Voor dit alles hebben wij richtlijnen en deze werden/worden ook met voeten getreden (met name door inhuurpersoneel). Ik heb me dus sterk gemaakt voor code reviews en dat lijkt toch te werken gewoon uitprinten en met de rode pen doorheen gaan. Het kost wel wat tijd maar levert naar ons idee vrij veel kwaliteit terug. Het komt zelfs soms voor dat ik gewoon weiger aan een review te beginnen omdat de code nog totaal niet klaar is voor review.

Op http://www.ifsq.nl/ kun je wat richtlijnen vinden voor reviews een paar simpele stappen die veel opleveren. Probleem voor het invoeren voor reviews zijn de mensen managers zien het over het algemeen niet zitten omdat het tijd kost, programmeurs houden er niet van omdat ze het gevoel hebben op de vingers gekeken te worden. Maar het voornaamste is gewoon elkaar er op durven aan te spreken en ook accepteren als dat bij jouw gebeurt. (Een stok achter de deur in de vorm van reviews maakt het iets minder vrijblijvend)

[SinergyX]

In een veel kleinere situatie en niet echt vergelijkbaar (maar wel onwerkbaar), werkte ik samen met nog 2 andere voor wat bijverdiensten voor een amerikaans design-bedrijfje. PSD's netjes knippen naar HTML (vlakken vervangen door html kleur etc) met daarbij wat plain HTML zut.

Meestal kreeg ik de probleem gevallen als het weer fout was gegaan of het werkte niet zo meer, kom je semi-php sites tegen (naja, index met case include zut) waar complete copy/past code instond van bv hotscripts (incl bergen onnodige opmerkingen) of zelfs frontpage gegeneerde zut.

Het ligt er maar aan hoelang die andere collega's al zo werken, gaat dit al jaren zo is het geen opgave dit ooit te veranderen. Het is zo ingebakken dat je dat niet 'eventjes' anders gaat doen. Gooi het anders voor bij je baas, mogelijk dat je dan bepaalde projecten van begin af aan mag doen

[Hydra]

Je kunt het als 'eenling' nooit de bedrijfscultuur aanpakken. Als ze lopen te prutsen ga je ze niet met een koevoet bewegen om het wel op de juiste manier aan te pakken. Ik zou zeggen; doe ervaring op (van fouten leert men), probeer niet te gefrustreerd te raken, en neem deze ervaring mee als je straks een echte baan gaat zoeken. Op een sollicitatiegesprek kun je deze ervaring prima gebruiken om aan te geven wat je niet zoekt in een bedrijf, en in een klap duidelijk te maken dat je weet hoe het in ieder geval niet moet

[kasper_vk]

Áls je dit al zou willen aanpakken, dan denk ik dat je twee uitgangspunten moet hanteren:

• Ga absoluut niet in één klap al die punten die je in de TS aanhaalt op tafel gooien, maar begin met de ergste. Anders gaat 't waarschijnlijk opgevat worden als 'jullie doen ALLES fout', en daarmee gooi je de deur van de kier in het slot.
• Je moet de voordelen van de 'betere' aanpak duidelijk maken. Alleen zeggen/redeneren dat iets beter is, werkt vaak niet: men moet pijn voelen om iets te willen genezen.
  Heb je een concreet voorbeeld van een bug die opgelost leek, maar later toch terugkwam omdat de bug middels copy+paste nog op een (of meer) andere plaats(en) voorkwam? Kijk --> dan heb je een aantoonbaar nadeel te pakken van dit soort gepruts.

En nog een politiek adviesje: weet je zeker dat je niet een medestander kunt vinden? Iemand die je wel eens hoort vloeken / zuchten vanwege wat ie tegenkomt in de code. Als je iets in de groep bespreekbaar maakt, en je krijgt er één zover dat ie 'jouw kant kiest' dan volgen de anderen vaak ook wel. (iets met schapen en een dam )

Maar wat hierboven al geschreven is: zodra dit je te erg frustreert en je er niet gelooft dat 't zal veranderen, pak je dan biezen.

[jbdeiman]

Daarom vind ik het ook zo heerlijk om zelf aan code te werken, en veel met functies te werken, die niets anders doen dan simpel dingen genereren die je zo in de code kan gebruiken.
Zo heb ik een functie geschreven die een menu (xhtml valide unordered list) retourneerd, maar wel rekening houd met de actieve items. (de main is actief, evenals elke sub die voor de getoonde pagina staat, werkt ook als er meerdere subs met eenzelfde naam zijn)

Deze functies geef ik wel door en kunnen anderen zo gebruiken, opmaak moeten ze zelf doen.

Overigens is het heel belangrijk dat je afspraken hebt over de code en code niet (zomaar) op maat gaat maken voor iets, als je het ook zo kunt schrijven dat het voor meerdere doeleinden een oplossing kan bieden.

Ga eens met z'n allen om tafel zitten, (evt incl de baas, maar het is laagdrempeliger en minder "aanvalsgevoelig" wanneer je het gewoon met elkaar bespreekt) bespreek je bevindingen met je collega's en vraag of ze mee kunnen/ willen denken aan een oplossing.

Scripts kopiëren ben ik sinds ik daarmee in aanraking ben geweest (geloof mij, geen beste ervaring) helemaal op tegen. Je weet vaak niet 100% wat een script op elk punt doet, doorlezen doe je niet wanneer het een groot script betreft.
Ik had zelf niets met dat script gekopieerd, maar er zaten fouten in een script dat het bedrijf had gekocht. Ze vroegen aan mij of ik dat kon repareren. Dus ik daar vol goede moed aan beginnen, een paar grote fouten eruit gehaald, maar voor elke reparatie kwam weer een andere fout terug. De hele opbouw was ook al niet zo optimaal (de databasestructuur en dergelijke) maar je kan gewoon alles herschrijven.
(alles was ook in een bijna 100k groot php bestand bij elkaar geplempt onder 1 class, wel zeggen dat ze het OOP maken, maar ook de gehele HTML werd binnen functies en die class uitgepoept) Dit is echt niet werkbaar, uitbreiden is niet / nauwelijks te doen (kost 10x meer tijd dan wanneer de boel redelijk was opgebouwd).

Dus ga met elkaar praten laat iedereen aan oplossingen meedenken en wanneer iemand code wil gaan kopiëren kan dat, maar laat de bestaande code altijd zoals het was. (de geöptimaliseerde code) blijf daar gewoon vanaf, maak evt. een nieuwe functie/ class (of pas de namen daarvan gewoon aan) en gebruik dan de gekopieerde code:
- Ja, je hebt dan nog wel de zooi
- Nee, je goede code blijft lekker bruikbaar.

[IStealYourGun]

Misschien tijd om de lead developer te vervangen of een analist aan te nemen?

Hoe je er persoonlijk mee omgaat is moeilijk in te schatten. Zijn ze gewoon lui of niet op de hoogte van hoe je "netjes" kan programmeren? In het laatste geval zal je hen misschien iets kunnen bijleren. In het eerste ga je op hun systeem werken.

[Boudewijn]

Externe review kan ook helpen, of mensen een boek geven (code complete?) als stille hint.

Er zijn ook metrics-toolkits die code duplication meten, kun je iig wat getalletjes ophoesten als er dingen misgaan.

[ Voor 40% gewijzigd door Boudewijn op 28-07-2009 11:35 ]

[gorgi_19]

webshit schreef op dinsdag 28 juli 2009 @ 11:28:
Misschien tijd om de lead developer te vervangen of een analist aan te nemen?

Je moet het wel in perspectief zien: hij is de student die het naast zijn bijbaan doet, met een klein bedrijfje er bij ga je dit lastig voor elkaar krijgen

[Hydra]

gorgi_19 schreef op dinsdag 28 juli 2009 @ 11:46:
Je moet het wel in perspectief zien: hij is de student die het naast zijn bijbaan doet, met een klein bedrijfje er bij ga je dit lastig voor elkaar krijgen

Dat is een understatement. Dat gaat gewoon nooit lukken. Gewoon nu 't beste van maken, van leren, en later een echt bedrijf zoeken dat codekwaliteit en best-practices wel serieus neemt.

[Verwijderd]

Hi JanDM,

Een aantal van de zaken die jij noemt (bijvoorbeeld veelvuldig Ctrl-C, Ctrl-V) zijn "software defect indicators" -- een goede indicatie dat de software op zijn minst onnodig moeilijk onderhoudbaar is en misschien zelfs onbetrouwbaar zal zijn in gebruik. Het zou handig zijn om de projectleider of opdrachtgever op de hoogte te stellen van het bestaan van de IfSQ Standards voor Computer Program Source Code (begin maar met Level-1: http://www.ifsq.org/level-1.html). Deze normen zijn kosteloos toe te passen door de werk van een programmeur te laten beoordelen door een andere programmeur.

Waarom zou je het doen? Omdat het HEEL VEEL GELD spaart: kijk maar op http://www.ifsq.org/why-inspect.html.

Veel succes met je carriere als developer -- het is een blijft een leuke ambacht. (Een vak is het zeker nog niet -- een vak zonder vaknormen is geen vak!)

[Boudewijn]

Ik denk dat je baas pas gevoelig ervoor wordt als hij economisch benadeeld wordt.
Maw: hij moet inzien dat de huidige situatie hem gewoon geld kost door slechte maintainability.

Hoe je hem dat in kunt laten zien als student zijnde, behalve door boeken oid weet ik ook niet.

[Eddy Dean]

Getting things done when you're only a grunt (Joel Spolsky

En lees ook eens het boek "How to win friends and influence people" van Dale Carnegie (absoluut niet zweverig ofzo hoor, is het lezen zeker waard). Daar staat heel wat nuttig advies in om mensen ergens van te overtuigen.

Maar verwacht vooral niet dat je in een keer alle minpunten kunt aanpakken, het zal lang duren voordat er echt vooruitgang is.

[Sebazzz]

Nofi, maar als de dingen die je in je TS aangeeft echt gebeuren bij dat bedrijf lijkt het alsof er een stelletje beginners aan de gang is? Zelfs ik weet dat je niet op die manier moet programmeren Ik zou ze inderdaad even Code Complete 2 aanraden.

[Olaf van der Spek]

Verwijderd schreef op dinsdag 28 juli 2009 @ 12:04:
Waarom zou je het doen? Omdat het HEEL VEEL GELD spaart: kijk maar op http://www.ifsq.org/why-inspect.html.

Interessant. Bij open source projecten kom je de instelling "Het werkt nu toch?" ook vaak tegen, helaas.
Dat het later heel veel tijd scheelt om dingen nu goed te implementeren is inderdaad waar.

[ Voor 12% gewijzigd door Olaf van der Spek op 28-07-2009 12:59 ]

[Remus]

Olaf van der Spek schreef op dinsdag 28 juli 2009 @ 12:59:
[...]

Interessant. Bij open source projecten kom je de instelling "Het werkt nu toch?" ook vaak tegen, helaas.
Dat het later heel veel tijd scheelt om dingen nu goed te implementeren is inderdaad waar.

Idd, net als de houding 'Documentatie? De code is toch de documentatie!'

[Sebazzz]

Olaf van der Spek schreef op dinsdag 28 juli 2009 @ 12:59:
[...]

Interessant. Bij open source projecten kom je de instelling "Het werkt nu toch?" ook vaak tegen, helaas.

Ik denk dat dat sowieso wel veel voorkomt, alleen bij open source projecten kan je het zien. Ik wil bijvoorbeeld niet weten hoe de software die we bij de AH gebruiken in het elkaar zit of hoe Rooster&Realisatie in elkaar zit Als ik naar die programma's kijk, kan dat nooit goed zijn...

[Olaf van der Spek]

Remus schreef op dinsdag 28 juli 2009 @ 13:18:
Idd, net als de houding 'Documentatie? De code is toch de documentatie!'

Bugs documenteren in plaats van fixen zie ik helaas ook nogal eens...

[jbdeiman]

Bugs worden gedocumenteerd, omdat mensen die iets bouwen nooit stil zitten. Ze documenteren bugs om zo een lijstje te hebben waarin staat welke bugs er in een bepaalde versie zitten en welke daarvan zijn opgelost.

Bijv bij windows vista toen die klaar was, denk je toch niet dat ze stil gaan zitten? Ze zijn toen al begonnen met (een basis van) windows 7. Ontwikkelingen gaan snel, dus moet je ook proberen bij te blijven.het mooie van een "open source project" is wel dat omdat er altijd wel iemand is die de tijd heeft op dat moment ook meteen die bugs kan wegwerken. (+ op zo'n buglist staan ook nooit alle bekende bugs, tenminste niet op de naar buiten gebrachte list.

Qua documenteren dan? Wat documenteren jullie allermaal bij de code? Ikzelf (ZZP'er) documenteer vooral bij de scripts zelf. Veel commentaar e.d. maar ook de juiste standaarden aanhouden.

[Remus]

Olaf van der Spek schreef op dinsdag 28 juli 2009 @ 13:41:
[...]

Bugs documenteren in plaats van fixen zie ik helaas ook nogal eens...

Op zich kan dat geen kwaad als het een tester is die het documenteren doet

[cariolive23]

Bugs documenteren in plaats van fixen zie ik helaas ook nogal eens...

Hoe wil jij iets gaan fixen als je niet eens weet dat je iets moet fixen? Zonder documentatie is er geen basis om iets te gaan fixen, laat staan dat je er enige prioriteit aan toe kunt kennen. Het werk verdelen onder de verschillende programmeurs wordt ook lastig, je weet niet wat er te verdelen valt. Daarnaast zul je de boel ook weer moeten testen, ook dat gaat niet lukken wanneer je niet weet wat er fout was en wat er is gefixed.

Open source of closed source, de code is net zo fraai. Met open source wordt er wellicht nog iets meer tijd besteed aan mooie code, iedereen kan het zien en iedereen kan er opmerkingen over gaan maken. Vele programmeurs zitten daar niet op te wachten en steken er dan liever even 5 minuten extra in.

[Voutloos]

cariolive23 schreef op dinsdag 28 juli 2009 @ 14:21:
[...]
Hoe wil jij iets gaan fixen als je niet eens weet dat je iets moet fixen?

Het documenteren moet dus via een bug tracking system, en ik neem aan dat Olaf bedoelt dat bugs in de code zelf met comments goed gepraat wordt.

[Sebazzz]

cariolive23 schreef op dinsdag 28 juli 2009 @ 14:21:
[...]

Vele programmeurs zitten daar niet op te wachten en steken er dan liever even 5 minuten extra in.

Veel wel ja, maar niet iedereen. Coding Horror had laatst er een mooi artikel over.
How to Motivate Programmers

[Olaf van der Spek]

cariolive23 schreef op dinsdag 28 juli 2009 @ 14:21:
Hoe wil jij iets gaan fixen als je niet eens weet dat je iets moet fixen?

Ik zei: documenteren in plaats van fixen. Met een bug tracker is niks mis, ik bedoel bugs die bijvoorbeeld in de readme van een applicatie/game terecht komen.

[Boudewijn]

Is gewoon een afweging: verwachte verbetering van de applicatie tov verwachte kosten voor het fixen van de bug.

[Olaf van der Spek]

Boudewijn schreef op dinsdag 28 juli 2009 @ 15:00:
Is gewoon een afweging: verwachte verbetering van de applicatie tov verwachte kosten voor het fixen van de bug.

Dat is eenvoudig gezegd voor de developer natuurlijk. En users er maar keer op keer tegenaan lopen.

[Voutloos]

Nog een afweging: De kosten van bugs direct fixen versus de kosten van bugs later fixen. O wacht, later is het in 99 vd 100 gevallen duurder en ben je inmiddels ook tijd kwijt geweest aan extra bugmeldingen, support, feedback en notificaties wanneer de bug is opgelost.

* Voutloos is liefhebber van de technical debt analogie.

[ Voor 11% gewijzigd door Voutloos op 28-07-2009 22:08 ]

[bredend]

Hoe omgaan met slechte code van collega's? Tsja, niet iedereen kan even goed programmeren als jij. Blijkbaar is er vraag naar wat het bedrijf levert, ondanks dat het niet perfect is. Als ik jou was zou ik gewoon mooie code blijven schrijven en af en toe een collega informeren over het feit dat als het het op een bepaalde manier aanpakt het resultaat dan beter is.

[Grijze Vos]

Waar ik een hekel aan heb is het uitstellen van het bouwen van componenten van het pakket wat het bedrijf zelf heeft ontwikkeld totdat random klant X erom vraagt, terwijl je al een half jaar weet dat dat gebouwd moet worden. Vervolgens zit je dus componenten te ontwikkelen die een collega twee weken geleden al had willen hebben, en werkt je collega met een beta-versie van de component.

[Gomez12]

Voutloos schreef op dinsdag 28 juli 2009 @ 22:05:
Nog een afweging: De kosten van bugs direct fixen versus de kosten van bugs later fixen. O wacht, later is het in 99 vd 100 gevallen duurder en ben je inmiddels ook tijd kwijt geweest aan extra bugmeldingen, support, feedback en notificaties wanneer de bug is opgelost.

* Voutloos is liefhebber van de technical debt analogie.

Tja, maar soms is het in dit soort grote probleemgevallen ook handiger om bepaalde bugs even te laten zitten / rusten en gewoon een rewrite van dat gedeelte in te plannen.

Heb je de bugs niet binnen 1 dag eruit, maar mits je een goede rewrite doet verhelp je ook een heleboel nog niet gedecteerde bugs.

Als je begint met bagger-code en personeel wat bagger-code produceert zou ik niet direct beginnen met incidenten fixen, alle fixes zijn dan wederom bagger...

Het gaat hier niet echt om een droombedrijfje wat goede code produceert en enkel wat kleine bugs heeft...

@TS : Loop gewoon eens door de bug-database heen en kijk eens of je een bug herkent... Herken je iets dan waarvan je denkt dat jij dit ook gefixed hebt, dan heb je een gesprekspunt. Copy/paste iedereen elke keer alles ( dus ook gefixte versies in andere documenten ) waardoor je geen probleem kan aantonen, dan heb je een uitdaging.
Dan is het meer een gevoel / een theorie dat het niet klopt, maar je kan het niet onderbouwen en dan werkt het om de een of andere magische wijze toch blijkbaar wel voor dit clubje programmeurs. Ik heb nog nooit meegemaakt dat Copy/paste fouten niet heel simpel aan te tonen waren door gewoon door de oude bugs / openstaande bugs heen te bladeren, maar misschien zijn jullie het eerste bedrijf ter wereld wat deze techniek perfect toepast...

Begrijp namelijk wel dat elke verandering ( hoe mooi theoretisch ook ) altijd tot een praktische verbetering moet leiden, is er geen praktische verbetering dan kost elke cursus / andere werkwijze het bedrijf gewoon geld...

bredend schreef op dinsdag 28 juli 2009 @ 22:28:
Hoe omgaan met slechte code van collega's? Tsja, niet iedereen kan even goed programmeren als jij. Blijkbaar is er vraag naar wat het bedrijf levert, ondanks dat het niet perfect is. Als ik jou was zou ik gewoon mooie code blijven schrijven en af en toe een collega informeren over het feit dat als het het op een bepaalde manier aanpakt het resultaat dan beter is.

Het is veelal niet een kwestie van dat niet iedereen zo goed kan programmeren als jij.
Best practices etc zijn gewoon zoals de naam al doet vermoeden gewoon uit de praktijk voortgekomen. Je kan 10 jaar aan een prog programmeren en alles uitbreiden met ctrl-c / v etc en perfect blijde klanten hebben, maar als er dan in jaar 11 iets in de core moet veranderen en dit breekt alle code van de afgelopen 10 jaar, dan heb je even een uitdaging als bedrijf zijnde ( oh nee wacht, je kan even een quick fix maken zodat de uitdaging weer een jaar uitgesteld is en iets groter geworden is... )

Simpel voorbeeld wat ik ken : een bedrijf wat hardcoded in elk los scherm ( waarop het van toepassing was ) een btw-percentage van 19% heeft staan ( nog even het simpele feit dat dit niet in een view-gedeelte hoort daargelaten ) dat kreeg een paar jaar terug de zenuwen toen ze hoorden dat het btw-percentage mogelijk ging veranderen naar 20%. Zolang de btw op 19% blijft staan levert het bedrijf snel een werkend product op, maar achter de schermen zijn er enkele mensen al 1 1/2 jaar als er tijd is bezig met het omcoderen van deze grap... Dat grapje kost bakken met geld...

[ Voor 28% gewijzigd door Gomez12 op 28-07-2009 22:59 ]

[Sebazzz]

Weet je dat dit topic mij best doet schrikken, ik dacht dat de programmeurs die programmeren omdat ze ervoor betaald krijgen over het algemeen wel hoge kwaliteit code en nette applicatiedesigns aanhouden. Ik had zeker niet verwacht dat er bedrijven zouden zijn waar bijna iedere programmeur op pre-hobby niveau programmeert.
Is het echt zo erg in de IT?

[Boudewijn]

Olaf van der Spek schreef op dinsdag 28 juli 2009 @ 19:16:
[...]

Dat is eenvoudig gezegd voor de developer natuurlijk. En users er maar keer op keer tegenaan lopen.

Nee dat is voor de projectmanager.

Die moet gewoon een tradeoff maken tussen de belangen van de stakeholders. Als hij dat goed doet, dan doet hij dat en dan is het gewoon zo.

[Gomez12]

Sebazzz schreef op dinsdag 28 juli 2009 @ 22:59:
Weet je dat dit topic mij best doet schrikken, ik dacht dat de programmeurs die programmeren omdat ze ervoor betaald krijgen over het algemeen wel hoge kwaliteit code en nette applicatiedesigns aanhouden. Ik had zeker niet verwacht dat er bedrijven zouden zijn waar bijna iedere programmeur op pre-hobby niveau programmeert.
Is het echt zo erg in de IT?

Heel simpel feit, veelal is het als een klant iets binnen 1 dag moet hebben dan krijgt de klant dit gewoon binnen 1 dag, hoe erge gruwelcode dit ook oplevert. Het is enkel aan de verkoopafdeling / factuurafdeling om hier rekening mee te houden en gewoon 10 dagen werk te factureren ( 1 dag voor het daadwerkelijke oplossen van het probleem van de klant, en 9 dagen om de quick-fix te rewriten naar behoorlijke code voor de volgende update ).

Als er een tijdsdruk is en een keiharde deadline dan leidt dit vaak tot hacks/quickfixes links en rechts. Enkel een professioneel bedrijf trekt dit naderhand weer recht.
Nee zeggen tegen een klant blijft moeilijk voor een commercieel bedrijf...

[Boudewijn]

Het komt ook doordat er veel slecht geschoolde mensen programmeren. Slecht: als in niet IT geschoold.

Ik heb in een bedrijf gewerkt met veel electro-technici, waar ook wat mensen uit andere disciplines werken.
Ook een boekhouder die zelf systeembeheerder is geworden en dan ook de meest ranzige crap maakte.

Zo zijn er meer bedrijven met 50'ers die via via in de IT zijn gerold en vast heel goed zijn in hun vak maar nooit geleerd hebben degelijk te coden.

De electro'ers die ik ken en al een tijdje meedraaien (lees >=40) maken de meest ranzig code die ik gezien heb.
Domweg omdat het werkt maar ze niet naar de nodige 'ility' eigenschappen (availability, maintainability etc) kijken.

[TeeDee]

Sebazzz schreef op dinsdag 28 juli 2009 @ 22:59:
Weet je dat dit topic mij best doet schrikken, ik dacht dat de programmeurs die programmeren omdat ze ervoor betaald krijgen over het algemeen wel hoge kwaliteit code en nette applicatiedesigns aanhouden. Ik had zeker niet verwacht dat er bedrijven zouden zijn waar bijna iedere programmeur op pre-hobby niveau programmeert.
Is het echt zo erg in de IT?

Fast, Good, Cheap. Pick two. Als wij (dev team van 6 man) alle tijd van de wereld zouden hebben dan zou onze code nog mooier zijn en zouden we alle deadlines halen* inclusief de meest magische design patterns.

Dat jij zegt "pre-hobby" nivo vind ik nogal overdreven. Tuurlijk zijn er enorme prutsers met hooggeplaatste functies, maar het gros weet echt wel wat het doet. Alleen is vaak de tijd/druk niet in verhouding met het werk dat gedaan moet worden.

Uiteraard is dat ook de 'fout' van de ontwikkelaar zelf; "Nope, ga ik niet redden", is vaak een betere reactie dan "Tuurlijk, morgen is 't klaar". En deadlines met 2 weken vooruitschuiven is ook geen goed idee, want dan ben je nog niet klaar. Vervolgens tegen 'die sales gasten' zeggen dat er nog eens 2 weken tegen aan moeten.

Bottom line: welcome to the real world

* _{we zijn wel bezig met een 100% rewrite van de core, wcf en silverlight zijn er bij gekomen. Sommige zaken hebben we ons op verkeken en het merendeel waren workarounds voor een hoop meuk wat niet of nauwelijks werkte in SL2.}

[ Voor 4% gewijzigd door TeeDee op 29-07-2009 00:17 ]

[Chip.]

Remus schreef op dinsdag 28 juli 2009 @ 13:18:
[...]

Idd, net als de houding 'Documentatie? De code is toch de documentatie!'

In principe is de code ook documentatie mits er gebruikt maakt van goeie naamgevingen. Ik ga geen code documenteren waaruit uit de code simpel blijkt wat het doet, alleen bij stukken code waardat niet 1 2 3 duidelijk is wat de samenhang is...

Olaf van der Spek schreef op dinsdag 28 juli 2009 @ 13:41:
[...]

Bugs documenteren in plaats van fixen zie ik helaas ook nogal eens...

Vind ik niet raar... niet alle bugs zijn meteen op te lossen. Of je moet van quiekfixes houden...

Sebazzz schreef op dinsdag 28 juli 2009 @ 22:59:
Weet je dat dit topic mij best doet schrikken, ik dacht dat de programmeurs die programmeren omdat ze ervoor betaald krijgen over het algemeen wel hoge kwaliteit code en nette applicatiedesigns aanhouden. Ik had zeker niet verwacht dat er bedrijven zouden zijn waar bijna iedere programmeur op pre-hobby niveau programmeert.
Is het echt zo erg in de IT?

Time is money. Het is simpel een kosten baten analyse. Bij een simpele applicatie als het rooster systeem van de AH zal er echt niet zo op de code gelet worden. Maar bij de software die zorgt dat brandstof tanks van de Endeavour op tijd starten zal dat weer anders zijn.

[ Voor 58% gewijzigd door Chip. op 29-07-2009 00:31 ]

[Verwijderd]

Sebazzz schreef op dinsdag 28 juli 2009 @ 22:59:
Weet je dat dit topic mij best doet schrikken, ik dacht dat de programmeurs die programmeren omdat ze ervoor betaald krijgen over het algemeen wel hoge kwaliteit code en nette applicatiedesigns aanhouden. Ik had zeker niet verwacht dat er bedrijven zouden zijn waar bijna iedere programmeur op pre-hobby niveau programmeert.
Is het echt zo erg in de IT?

Geld > *. Je wilt niet weten in hoeveel serieuze bedrijven er met houtje touwtje oplossingen gewerkt wordt. Soms moet je gewoon consessies doen met betrekking tot netheid en best practices en zul je pragmatischer te werk moeten gaan. Goed voorbeeld, we hebben hier in elke tabel een veld, wat eigenlijk een tabel is in een kolom. Het idee erachter is dat bij elke release wensen van klanten in die kolom worden opgslagen (nieuwe velden et cetera) en bij een volgende release zou dan het datamodel worden uitgebreid met die wensen.
Dat is natuurlijk nooit gebeurd (in meer dan 20 jaar) en nu is dat veld in elke tabel dus een grote verzamelbak van 'dingen' die met substrings uit worden gelezen.
Wij (R&D afdeling) zijn dat oude pakket aan het overbouwen naar een .NET omgeving and guess what? Het wordt gewoon 1-op-1 overgebouwd in deze fase... Waarom? Tijd en geld.
Als je op zoek bent naar een omgeving waar alles volgens de boekjes en uni gedaan wordt, be'n je hoogstwaarschijnlijk nog wel even op zoek, zeker als er aandeelhouders in het spel zijn

[chime]

Het nadeel is: ranzige code geeft op korte termijn winst (het is sneller af) maar op de lange termijn geeft het veel meer kosten/problemen.
2e nadeel: ranzige code wordt vaak alleen maar ranziger, want iemand die iets moet aanpassen, gaat zo weinig mogelijk herschrijven omdat dat waarschijnlijk toch alleen maar meer problemen gaat opleveren.

Nu, dat niet alles is gedocumenteerd is de realiteit.
Vaak is het beste wat je kan doen:
- leesbare code schrijven
- ervoor zorgen dat er weinig duplicatie is in je eigen klasses.

[Grijze Vos]

Het probleem is dat bedrijven nu ook nog wegkomen met bugs. Vaak worden ze betaald om die alsnog te fixen. Als de wetgeving omtrent garantie op software wordt veranderd zoals laatst in het nieuws was, dan zou dat best wel eens positieve effecten kunnen hebben op de code kwaliteit.

[Verwijderd]

Hoe zou die garantie dan precies moeten worden vormgegeven? Er zijn genoeg kleine bugs die de workflow/functionaliteit van de software niet breken, maar het zijn wel bugs.
Windows levert eens in de zoveel tijd nog wel eens een BSOD als het het even niet meer zo ziet zitten, is dit een bug?
Bij wat voor bugs stel je de grens? Als ik zie hoe enorm groot en complex de software is waar wij aan werken (ERP) dan is het _echt niet_ realistisch om te denken dat alle bugs er uit gehaald worden. Dit kost gewoon teveel tijd en mankracht en gaat ten koste van nieuwe functionaliteit en maatwerk.

[ Voor 14% gewijzigd door Verwijderd op 29-07-2009 09:52 ]

[Remus]

Wouser schreef op woensdag 29 juli 2009 @ 00:22:
In principe is de code ook documentatie mits er gebruikt maakt van goeie naamgevingen. Ik ga geen code documenteren waaruit uit de code simpel blijkt wat het doet, alleen bij stukken code waardat niet 1 2 3 duidelijk is wat de samenhang is...

En dat is een flinke valkuil. Want jouw code is niet altijd even makkelijk te doorgronden als je zelf denkt, en als jij (of iemand anders) er een paar maanden of jaren later naar kijkt kan je veel tijd verliezen. Daarnaast moeten comments in code in principe de intentie vermelden (implementatie kan soms verkeerd zijn) en natuurlijk niet simpelweg de implementatie anders verwoorden.

Daarnaast heb ik het niet exclusief over sourcecode documentatie. Maar ook over dingen als documentatie van het buildproces, protocol specificaties, afhankelijkheden en APIs met andere systemen (of voor andere systemen) en noem maar op.

Ik heb nu al een paar keer meegemaakt (zowel op werk als bij testen van opensource applicaties of frameworks of implementeren van plugins op basis van een opensource framework) dat de documentatie dusdanig te wensen overlaat dat je inderdaad de code in moet duiken om erachter te komen hoe bepaalde dingen gebruikt of getest moeten worden. Dat is niet hoe het hoort en kan zelfs leiden tot foutpropagatie (test gebaseerd op de incorrecte implementatie, incorrect gebruik van het framework etc etc).

Vind ik niet raar... niet alle bugs zijn meteen op te lossen. Of je moet van quiekfixes houden...

Dat klopt, en er is ook niks mis mee met documenteren van bugs in mijn ogen. Maar sommige bedrijven/ontwikkelaars hebben er nog wel eens een handje van om eenmaal gedocumenteerde bugs niet meer op te lossen ("Het staat toch in de handleiding/knowledgebase beschreven").

[unclero]

Sebazzz schreef op dinsdag 28 juli 2009 @ 22:59:
Weet je dat dit topic mij best doet schrikken, ik dacht dat de programmeurs die programmeren omdat ze ervoor betaald krijgen over het algemeen wel hoge kwaliteit code en nette applicatiedesigns aanhouden. Ik had zeker niet verwacht dat er bedrijven zouden zijn waar bijna iedere programmeur op pre-hobby niveau programmeert.
Is het echt zo erg in de IT?

De mooiste code wordt geschreven bij hobbyprojecten / opensource projecten / research projecten.
Bij projecten waar een accountmanager in de nek staat te hijgen gaat het gewoon anders.
Klant wil vaporware? Wij schrijven wel even een menuutje dat het niet doet. Applicatie laat ubertraag in? Het is goedkoper een fancy laadschermpje te schrijven dan te gaan optimaliseren.
Heb je op de HBO leren applicatiedesignen? Doen we niet aan, hooguit een diagrammetje voor de databeesten. Documentatie doen we al helemaal niks aan, als er iets is gaat de accountmanager eerst in zijn geheugen graven wie het geschreven heeft, en die mag vervolgens op komen draven om vervolgens te mompelen "is dat mijn code? oohhh.. hoe had ik dat ook alweer gedaan..".

chime schreef op woensdag 29 juli 2009 @ 08:07:
Het nadeel is: ranzige code geeft op korte termijn winst (het is sneller af) maar op de lange termijn geeft het veel meer kosten/problemen.
2e nadeel: ranzige code wordt vaak alleen maar ranziger, want iemand die iets moet aanpassen, gaat zo weinig mogelijk herschrijven omdat dat waarschijnlijk toch alleen maar meer problemen gaat opleveren.

Oh, praat me er niet van. We hebben er daar eentje van. Slapeloze nachten, en in onze project managemer zijn er bizar veel topics in de trant van "Verloren gegane kennis uit 2007: weet iemand nog hoe dit-en-dat in elkaar zat?".
Update procedures zijn rituelen geworden, omdat we inmiddels zo bijgelovig zijn geworden (het moment dat voodoo het gaat winnen van physics weet je dat het project ranzig is), dat we bepaalde handelingen op bepaalde wijzen in bepaalde volgordes uit moeten voeren. En voor ieder ritueel is er wel een persoon die dat uit moet voeren (en niemand anders kan dat na doen).
Het is dat er 6-cijferige bedragen op jaarbasis aan verbonden zijn, anders hadden we het waarschijnlijk allang de deur uit gekiept.

Nu, dat niet alles is gedocumenteerd is de realiteit.
Vaak is het beste wat je kan doen:
- leesbare code schrijven
- ervoor zorgen dat er weinig duplicatie is in je eigen klasses.

De belangrijkste tip idd.

[AtleX]

Leuk dat een methode 'leesbaar' is, maar wat houdt dat in? Methode A maakt gebruik van methode B die weer methode C uit klasse D gebruikt. Code is vrijwel per definitie niet leesbaar, daarom hebben ze documentatie (al was het maar een simpel klassediagram) uitgevonden. Je kan namelijk nog zulke juwelen van code schrijven maar als bijvoorbeeld een nieuwe medewerker wat moet wijzigen aan je applicatie heeft hij gegarandeerd een aantal uren/dagen/weken en wat hulp nodig om de structuur en werking te doorgronden.

[jbdeiman]

Wat natuurlijk het mooiste is is als je het red/ als het uitkan, iemand (of een team van mensen) full-time aan het werk hebt / kan hebben om code te verbeteren/ optimaliseren. Een aantal mensen (lees: manuren) zijn gereserveerd voor het verbeteren en optimaliseren van de door (het grootste deel van de) medewerkers die zsm een oplossing maken voor een klant.
Zo hou je:
a) De klant tevreden, met snelle levertijden
b) De code toch netjes/ werkbaar
c) De toekomst veilig ivm met betrouwbare code
d) De klant nog tevredener met een update die het systeem versnelt/ versoepelt.

Randvoorwaarden hiervoor zijn wel dat de herschreven code:
1) Generiek is (alles op eenzelfde manier/ zelfde stijl geschreven)
2) De database structuur altijd goed genormaliseerd is
3) Er een schaduwkopie van het systeem beschikbaar is, zodat je altijd de beschikking hebt over de oude (dirty) en nieuwe (clean) code.

Wat ik heb gemerkt aan bugfixes in Dirty of in Clean code (waarbij de opbouw generiek is en ook logisch in elkaar zit. Tevens meerdere bestanden worden gebruikt met kleinere stukken code die niet altijd allemaal ingeladen/ gebruikt worden -> minder overhead) is dat je met Clean Code veel sneller bug fixes kan doen die het probleem ook echt oplossen.
Met dirty code loop je nog al eens tegen het probleem aan dat je de ene bug oplost en een andere ervoor terugkrijgt. Daarbij moet je ook maar eens zien uit te zoeken waar het probleem ligt, dat is met cleane code (en handige "bugtracker opbouw" -> Oftewel goede foutafhandeling) veel sneller en gemakkelijker te doen, omdat je redelijk na kan gaan waar de fout zich bevind.

[ Voor 28% gewijzigd door jbdeiman op 29-07-2009 11:13 ]

[Voutloos]

Zonder testcases gaat die aanpak in ieder geval niet werken.

Bovendien wil juist de cultuur tegengaan dat 'de opruimheld er toch overheen gaat'. Daarom is dit topic gestart, anders had TS wel in z'n eentje tot in de lengte van dagen zijn lol op gekund, ware het niet dat je binnen een paar jaar afstompt tot het IQ van een zee-egel.

Het gaat sowieso wat offtopic. Al deze argumenten kennen wij wel uit onze bijbels, of door bijvoorbeeld op de genoemde term technical debt te zoeken en door te klikken.

[ Voor 21% gewijzigd door Voutloos op 29-07-2009 12:04 ]

[Grijze Vos]

unclero schreef op woensdag 29 juli 2009 @ 10:46:
[...]


De mooiste code wordt geschreven bij hobbyprojecten / opensource projecten / research projecten.

Hobbyprojecten zou kunnen, maar opensource? Dat wordt verpest door prutsers die graag wat "willen helpen". Research projecten zijn doorgaans juist bijzonder slecht van kwaliteit, omdat dat bijna allemaal prototypes zijn. De technologie die ontwikkeld wordt is mooi, maar de implementatie is bijzonder brak. (Ik ben bezig met mijn afstuderen en ben dagelijks het lijdend voorwerp.)

Verwijderd schreef op woensdag 29 juli 2009 @ 09:44:
Hoe zou die garantie dan precies moeten worden vormgegeven?

Dat zijn ze nog aan het onderzoeken, en het is zeker geen makkelijk vraagstuk. Maar wellicht een stap in de goede richting. Het is fijn als je kunt focussen op kwaliteit in plaats van kwantiteit. Gelukkig krijgen wij hier op het werk redelijk de ruimte; en ik geef mijn programmeurs gewoon op hun noten als ze ranzige shit lopen te bouwen.

[ Voor 30% gewijzigd door Grijze Vos op 29-07-2009 12:20 ]

[BCC]

Verwijderd schreef op woensdag 29 juli 2009 @ 09:44:
Hoe zou die garantie dan precies moeten worden vormgegeven?

Dat het werkt volgens de specificaties lijkt me een aardig begin.

[Recursio]

Als onderzoeker ben ik mijn eigen klant en opdrachtgever: ik moet voortdurend kiezen tussen goed coderen vs. quick-'n-dirty proof-of-concepts afleveren. Doorgaans is er alleen tijd voor dat laatste, helaas. Ik werk op dit moment niet aan project met veel code, en deze handelswijze wordt dus ook niet direct afgestraft met maintenance problemen. Ik kan alleen niet zeggen dat coderen daar leuker van wordt.

[cariolive23]

Hobbyprojecten zou kunnen, maar opensource? Dat wordt verpest door prutsers die graag wat "willen helpen".

Ook open source projecten kennen een vorm van project management, sturen op kwaliteit hoort daar ook bij. Wat dat betreft zijn er weinig verschillen tussen open en closed source.

Mocht jij andere ervaringen hebben, noem dan eens wat namen van projecten die brakke code opleveren, dan hebben we het ergens over. Ik hoor van PostgreSQL juist dat de code bijzonder clean is, maar ik heb dat zelf nooit gecontroleerd. Ik ben dan ook geen programmeur, maar DBA en gebruik het eindresultaat.

Ter informatie: http://wiki.postgresql.org/wiki/Developer_FAQ

[unclero]

Grijze Vos schreef op woensdag 29 juli 2009 @ 12:17:
Research projecten zijn doorgaans juist bijzonder slecht van kwaliteit, omdat dat bijna allemaal prototypes zijn. De technologie die ontwikkeld wordt is mooi, maar de implementatie is bijzonder brak. (Ik ben bezig met mijn afstuderen en ben dagelijks het lijdend voorwerp.)

Bij mijn vorige toko waren we voornamelijk bezig met research, en van het "oh, doe maar volgend jaar ergens.." deadlines. Dus hadden we plenty tijd om de meest fancy classes, constructies en optimalisaties te bedenken.
En vooral eindeloos te filosoferen over nog efficientere methods .

[FragFrog]

cariolive23 schreef op woensdag 29 juli 2009 @ 12:36:
Mocht jij andere ervaringen hebben, noem dan eens wat namen van projecten die brakke code opleveren, dan hebben we het ergens over.

Geen idee in hoeverre het waar is, maar mijn oude C/C++ prof (Brokken, oa bekend van de C++ annotations) schijnt nogal een hekel te hebben aan de linux broncode En ik weet dat er tenminste een project op sourceforge staat met erg ranzige, ongestructureerde code..

Grijze Vos schreef op woensdag 29 juli 2009 @ 12:17:
Research projecten zijn doorgaans juist bijzonder slecht van kwaliteit, omdat dat bijna allemaal prototypes zijn. De technologie die ontwikkeld wordt is mooi, maar de implementatie is bijzonder brak.

Deels wel, deels niet. Probleem is dat, in elk geval op universitair niveau, programmeren niet bijzonder veel aandacht krijgt in de meeste studies - een paar introductie cursussen en dan word je geacht het wel te kunnen. Voornaamste reden waarom ik erg selectief ben in met wie ik samenwerk: een paar studenten die er wel interesse in hadden heb ik geintroduceerd aan version control, code reviews, goed documenteren en algemeen een nette code stijl, daar heb je wat aan. Anderen leveren doorgaans zo'n troep af dat als het niet helemaal werkt zoals het moet ik vaak sneller klaar ben het zelf te herschrijven, dat is natuurlijk niet de bedoeling.

Op werk hou ik doorgaans een erg simpel paradigma aan: don't break my stuff. Ga niet in mijn classes lopen rommelen zonder dat je weet wat je doet, en als je dat wel weet zorg ervoor dat je het net zo netjes achterlaat als je het aantreft - zoniet heb je een erg verdrietige FragFrog aan je bureau. Werkt aardig, zolang m'n baas me niet vraagt bij te springen in deelprojecten van anderen

[Verwijderd]

Grijze Vos schreef op woensdag 29 juli 2009 @ 12:17:
Dat zijn ze nog aan het onderzoeken, en het is zeker geen makkelijk vraagstuk. Maar wellicht een stap in de goede richting. Het is fijn als je kunt focussen op kwaliteit in plaats van kwantiteit. Gelukkig krijgen wij hier op het werk redelijk de ruimte; en ik geef mijn programmeurs gewoon op hun noten als ze ranzige shit lopen te bouwen.

Ter bewaking van de kwaliteit doen we hier, buiten het ontwikkelen van de functionaliteit, 4 dingen:
a) FxCop, eerste check voor het inchecken in TFS;
b) Unit tests;
c) Code review, voldoet de code aan de standaarden, geen rare constructies of overbodige code et cetera;
d) Functionele test, werkt het zoals het zou moeten werken.

Nog krijgen we bugs, enerzijds door fouten in het platform of updates aan dat platform anderzijds door conflicterende code. Om dit zoveel mogelijk te voorkomen wordt na een platform release weer een bepaalde selectie van schermen doorgetest.

Je kunt gewoon niet 100% dekkend zijn, zeker niet als je je realiseert dat we met, op het moment, x-100 schermen nog niet op 10% van het totale pakket zitten. Verder hebben te maken met integratieproblematiek, ons pakket zal een module worden van een ander pakket, wat ook de nodige hersenbrekers met zich meebrengt.

Op een gegeven moment houdt het gewoon op, er zullen áltijd bugs blijven bestaan. In hoeverre kan ons nog nalatenschap worden verweten als een klant tegen een bug aan loopt en zich op de garantie wil beroepen?
Softwareontwikkeling, zeker binnen grote projecten, is natuurlijk niet hetzelfde als lopendeband werk (al lijkt het soms wel zo ). Ik ben zeer benieuwd naar de uiteindelijke vormgeving van een voorstel voor een garantieregeling