Solliciteren bij bedrijven met legacy code

[gold_dust]

Ik ben op zoek naar een andere werkgever/opdrachtgever als software ontwikkelaar. Ik heb genoeg gesprekken en al een aantal aanbiedingen gehad dus op zich niet zo'n probleem. Ik ben bij mijn vorige werkgever na korte tijd weggegaan omdat de code base een hopeloos legacy systeem is waar niemand zich eigenlijk meer de vingers aan durft te branden.

Wat ik met legacy code bedoel is in code die in ieder geval een van volgende eigenschappen heeft:

- geen/gebrekkige documentatie
- geen tests
- geschreven door mensen zonder software engineering achtergrond
- geen behoorlijke version control
- geen OOD of gestructureerd ontwerp
- geen onderliggende architectuur
- oud en geschreven door mensen die het bedrijf al lang verlaten hebben
- vol met magic numbers
- maakt gebruik van legacy libraries
- etc.

Nu ik aan het solliciteren ben merk ik uit de gesprekken dat verschillende bedrijven weer verwachten dat ik code ga optimaliseren, bugs ga fixen, problemen ga oplossen van mensen die vertrokken zijn, etc. Afgezien van dat dit niet mijn interesse heeft vind ik het ook nogal onrealistisch en ondankbaar om van een nieuwe werknemer te verwachten dat die in ongedocumenteerde, slecht geschreven code van jaren oud bugs gaat lopen fixen. Ik heb zoiets van: dan had je meteen maar goede mensen moeten aannemen.

Mijn concrete vraag is, hoe zien andere ontwikkelaars dit en hoe ga je hier mee om?

[Aloys]

Zo gaat het toch vrijwel altijd? Een bedrijf kan nooit alleen maar bezig zijn met nieuwe projecten, of je moet voor een start-up kiezen (maar die fase duurt ook maar even). De code die jij nu schrijft is over een paar jaar ook legacy code. Ik weet dat nieuwe code schrijven leuker is op de korte termijn. Maar ik denk dat je best veel voldoening kan halen uit een compleet herschreven code-base van legacy code naar moderne technieken. Dat laatste zal je waarschijnlijk ook meer waardering opleveren bij je werkgever.

[naitsoezn]

Ik weet niet wat je precies verwacht of hoe lang je al rond loopt, maar zo werkt het met vrijwel ieder systeem. Vrijwel elk systeem dat ouder is dan, zegge, een jaar, heeft slechte documentatie, testing is overal een ondergeschoven kindje, spaghetti-code galore, etc. Ik denk dat de keren dat de gemiddelde software engineer volledig vanaf scratch een nieuw systeem mag bouwen in een volledige carrière op de vingers van één hand te tellen is (en dan houden de meesten nog vingers over ook ).

[ Voor 29% gewijzigd door naitsoezn op 31-12-2016 11:28 ]

[frickY]

Dan moet je een bedrjf zoeken die code schrijft voor derden, zoals het bouwen van websites
Dan heb je vaak bij ieder project de mogelijkheid vanaf scratch te beginnen, of wordt er slechts een klein deel gestandaardiseerde code gebruikt als blueprint.
Of en startup die nog moet beginnen.

Vergeet ook niet dat alles wat jij nu nieuw schrijft, over een jaar legacy code voor een ander is. Dat verloop gaat vrij hard.

Ik zelf vind het als ontwikkelaar vaak juist een uitdaging om dergelijke systemen te refactoren zonder functionaliteit te slopen. Hoe onmogelijker dat lijkt hoe groter de voldoening. Maar puur andermans bugs fixen is inderdaad geen lol aan.

[ Voor 40% gewijzigd door frickY op 31-12-2016 20:51 . Reden: typo ]

[t_captain]

Het klinkt alsof je bij een bedrijf zat waar de software engineering niet zo serieus werd genomen. MKB, buiten ICT en internet sector?

[Verwijderd]

Ik denk niet dat het realistisch is om te verwachten dat je bij een bedrijf met bestaande software komt, en dan alleen nieuwe software van scratch gaat bouwen. Het zal vrijwel altijd uitbreiding van bestaande software zijn, of er op moeten aansluiten. Een deel van het werk als software engineer zal altijd werken aan code van een ander zijn. Dat kun je ook als een uitdaging zien. Als je de code moet optimaliseren, kun je misschien delen compleet vervangen door je eigen code.

Misschien heeft t_captain gelijk, en moet je eens solliciteren bij een bedrijf dat op zijn minst iets als Scrum/Agile als werkmethode heeft, en ook gestructureerd test.

[CMD-Snake]

t_captain schreef op zaterdag 31 december 2016 @ 11:46:
Het klinkt alsof je bij een bedrijf zat waar de software engineering niet zo serieus werd genomen. MKB, buiten ICT en internet sector?

Genoeg grote ICT toko's die ook een heerlijk bord spaghetti code serveren.

gold_dust schreef op zaterdag 31 december 2016 @ 11:20:
- geen/gebrekkige documentatie
- geen tests
- geschreven door mensen zonder software engineering achtergrond
- geen behoorlijke version control
- geen OOD of gestructureerd ontwerp
- geen onderliggende architectuur
- oud en geschreven door mensen die het bedrijf al lang verlaten hebben
- vol met magic numbers
- maakt gebruik van legacy libraries
- etc.

Welkom in de ICT!

Legacy systemen zijn een onderdeel van het leven van elke IT'er of je het leuk vindt of niet. Je zal er mee moeten leren leven anders zal je weinig plezier beleven. Meeste bedrijven kunnen simpelweg niet hun hele legacy in een keer vervangen of willen dat niet. Als iets goed draait op een oud platform zonder problemen, waarom moet het dan vervangen worden?

[t_captain]

Deels ben ik het met bovenstaande reakties eens, deal with it.

Sommige punten zijn wel echt sub-par. "Geen behoorlijke version control." Ik heb altijd netjes met SCCS, ClearCase, VSS, TFS, SVN of GIT gewerkt. Er waren altijd (tenminste) tags en releases, soms was er een zeer professionele OTAP met feature branches, release branches en integratieprocedures. Meestal iets daar tussenin.

[CH4OS]

Dat het nú code is wat als "legacy" bestempeld wordt, betekend niet dat het destijds ook ruk was, misschien was het voor dat moment wel best practice. Doordat de originele schrijver vaak weg is en jij geen snars van de code begrijpt door brakke documentatie doet daar niets aan af. Jij wordt aangenomen om het beter te doen, nu zaken veel simpeler zijn gemaakt en men bewuster is geworden van het feit dat kwalitatieve code beter is voor elke applicatie. Het is dus onderdeel van het werk anno nu, terwijl men daar toen lang zoveel niet mee bezig was als nu.

[CMD-Snake]

Je hebt hoe dan ook te maken dat met het verloop van tijd anders gekeken wordt naar software ontwikkelen. Nu is Scrum en Agile helemaal hip, maar is dat ook het geval over vijf jaar? Misschien lachen we dan iedereen uit die aan Scrum en Agile doen.

Sommige applicaties worden ook complex omdat ze eenvoudig beginnen. Iemand wil het aantal verstuurde brieven per maand bijhouden en begint een Excel sheetje. Een handige Harry op de administratie bouwt een macro of twee in om de boel wat beter te laten werken. Nog eentje giet het in een Access database met wat schermpjes. Oeps... de applicatie is ineens nu zo belangrijke voor de administratie afdeling dat de IT afdeling deze moet ondersteunen en verder moet uitbouwen. Die besluit de Acces database in een SQL Server te gieten met een web frontend. En zo rolt het balletje verder.

[downtime]

frickY schreef op zaterdag 31 december 2016 @ 11:38:
Dan moet je een bedrjf zoeken die code schrijft voor derden, zoals het bouwen van websites
Dan heb je vaak bij ieder project de mogelijkheid vanaf scratch te beginnen, of wordt er slechts een klein deel gestandaardiseerde code gebruikt als blueprint.
Of en startup die nog moet beginnen.

Dat dus. Of ga mobile apps ontwikkelen. Die zijn veelal ook nieuw. Maar als web of mobile niet jouw ding is, dan kun je maar beter accepteren dat een groot deel van jouw werkzame leven eruit bestaat dat je voortborduurt op andermans werk, want echte greenfields zijn zeldzaam geworden.

Ik zou het belangrijker vinden dat je zelf wel de ruimte krijgt om zaken te verbeteren. Als die ruimte er ook niet is, omdat management de zin van documentatie/architectuur/versioncontrol/testen niet ziet, dan moet je daar niet gaan werken.

[CodeCaster]

Ik ben het volledig eens met wat hierboven gezegd wordt. Je moet je realiseren dat IT voor de meeste toepassingen nog steeds een middel is, en geen doel. "Verbeteren? Het werkt toch?". Dit is echt niet voorbehouden aan zaken waar IT een aangelegenheid is; ook bedrijven die toegewijd zijn aan (maatwerk)software bouwen hebben er een handje van om documenteren, testen en refactoren uit te stellen tot na de oplevering, en daarna tot de volgende kerst. Hoeveel POC's er niet afgeraffeld zijn en toch in productie draaien...

Het wordt pas interessant als je de drive hebt om deze zaken te verbeteren. Staat het bedrijf open voor veranderingen? Willen ze praten over source control, of willen ze blijven werken met de mappen "final", "really_final" en "final_2016_last"? Worden code reviews serieus genomen, of zijn er "seniors" (door jaren in dienst, niet noodzakelijk door ervaring) die steevast hun vierduizend regels tellende main() naar master pushen? Is er echt interesse voor het vastleggen van functionaliteit in unittests, of is het percentage coverage de enige metric en wordt er eigenlijk alleen getest of constructors en publieke methods wel de nodige ArgumentNullExceptions gooien? Kun je deployen met één druk op de knop, of worden er mapjes gekopieerd via een remote desktop of shell?

Kortom: het gaat overal zo. Zoek een bedrijf dat naar jouw input luistert, en wees voorbereid op een lang traject van kleine verbeteringen.

[ Voor 3% gewijzigd door CodeCaster op 31-12-2016 12:36 ]

[gold_dust]

Ok, ik heb het misschien niet helemaal goed verwoord. Ik werk bijvoorbeeld veel met open source frameworks, vaak zijn die toch echt wel goed geschreven en gedocumenteerd. Daar heb ik dan ook geen moeite mee, ook al is het niet mijn eigen code. Het is niet per definitie zo dat oudere code die ik zelf niet heb geschreven niet mee te werken valt of slecht is.

Wat ik bedoel is code die zo ver heen is dat het niet realistisch is om daar nog verder mee te werken. Bij mijn vorige werkgever wist iedereen dat dit zo is, er werd wat lacherig over gedaan en iedereen inclusief management was het er mee eens dat alles opnieuw moest maar vervolgens wordt de ruimte daar niet voor gegeven. Bovendien was er zo'n gebrek aan documentatie, niet alleen van de software zelf, maar ook van de processen die worden aangestuurd door de software dat opnieuw beginnen eigenlijk ook niet realistisch was en er een soort van impasse ontstaat.

Ik zie toch bij veel bedrijven een gebrek aan software development en project management kennis, zaken als versiebeheer, een testomgeving, behoorlijke documentatie, mensen met een software engineering achtergrond aannemen ipv. een natuurkunde, scheikunde achtergrond, etc zouden toch standaard moeten zijn maar zijn dat blijkbaar niet.

Mijn concrete vraag is, hoe filter ik dit soort bedrijven er uit en hoe vind je een iets een beetje op niveau. Mijn achtergrond is enkele R&D functies bij grote multinationals.

MKB links laten liggen en wat meer naar startups kijken met een modern ontwikkel proces zijn al goede tips.

[naitsoezn]

Juist de wetenschappelijke software hebben dit 'euvel' en als je bij grote multinationals hebt gezeten dan kunnen de managers waar jij contact mee hebt gehad er ook vrij weinig aan doen. Bovendien onderschat je denk ik de impact van 'opnieuw beginnen', vooral bij die grote multinationals. De mensen die jij bedoelt voor wetenschappelijke software zijn gewoon schaars, dat is geen kwestie van 'even aannemen'. Voor dat soort software is juist domeinkennis heel belangrijk, en dat is kennis die de 'gewone' software engineer vaak niet heeft, vandaar dat er vaak teruggevallen wordt op natuurkundigen / physici / beta-mensen met 'affiniteit voor programmeren'. Hier is niet één duidelijke oplossing voor, want alles kost geld en het schaap met de vijf poten is gewoon zeldzaam. Als jij je hierin niet kunt vinden, dan kun je de scientific software engineering beter loslaten en meer voor de 'administratieve' software (bij gebrek aan beter woord) gaan. In dat geval denk ik dat je mss juist beter voor de mkb kunt gaan (die start-ups zullen doorgaans ook niet de tijd hebben om alle systemen en processen optimaal in te richten).

[ Voor 8% gewijzigd door naitsoezn op 31-12-2016 12:59 ]

[maniak]

Mja.. legacy code biedt juist de mogelijkheid om iets nieuws te beginnen. Als jij het management kan overtuigen dat de kosten naar beneden gaat wanneer jij (delen van de) code opnieuw schrijft dan is de kans groot dat je dat mag doen. Werken in een organisatie is veelal zelf kansen creëren en pakken.

[CurlyMo]

Ik werk zelf precies in zo'n organisatie met exact dezelfde problemen als beschreven (ook in de onderzoeksveld). Ik vond het juist een uitdaging om het management en mijn collega's te overtuigen van het anders inrichten van het werkproces. Nu 1.5 jaar bezig. Daarin heb ik het werk langzaam omgebogen tot een nieuwe structuur. Eerst zelf een proof-of-concept gemaakt, in de samenwerking met collega's direct aan het documenteren geslagen, en in het nieuwe jaar gaan we allemaal agile en modulair aan de slag. Doordat ik in mijn concept kon laten zien dat ik een stukje van het werkproces door juiste code, documentatie en tests flink kon optimaliseren door een geautomatiseerd proces, was iedereen wel overtuigd.

Ik haal juist het werkplezier uit het ombuigen van deze werkprocessen en door het pakken en creëren van deze kans ben ik nu zelf projectleider van het specifieke project dat ik probeer te innoveren.

Wat eerder al is gezegd, begin klein, documenteer je eigen werk, maak unittests. Als je legacy code moet verbeteren, documenteer het gelijk, check bij collega's of je documentatie klopt en verbeter wanneer niet. (Gedrags)verandering gaat niet van de ene op de andere dag.

[ Voor 3% gewijzigd door CurlyMo op 31-12-2016 22:56 ]

[Gonadan]

Het is om nogal onrealistisch en ondankbaar om te verwachten dat als je ergens binnen komt alleen maar leuke en nieuwe dingen mag doen. Alle software heeft onderhoud nodig dus bugs fixen en zaken optimaliseren hoort er gewoon bij.

Daarbij is er altijd oude meuk aanwezig. Sterker nog, een ontwikkelaar vindt iets bestaands altijd flink voor verbetering vatbaar, zelfs als hij het zelf een jaar eerder geschreven heeft.

Het is met name belangrijk wat hierboven al genoemd wordt. Is er ruimte voor zaken als versiebeheer en verbetering. Werk je uiteindelijk ook aan nieuwe dingen of blijft het onderhoud?

Zo heb ik ook wel sollicitanten gehad. Met oud spul willen ze niet werken, alleen leuke nieuwe dingen. Wie is er dan niet flexibel? Zoek dan maar verder.

[NMe]

Als je bij een nieuw bedrijf begint is een belangrijke eerste stap om te achterhalen wat je precies kan, en dat is beter te zien bij een reeds bestaand project dan bij een nieuw. Het onderhouden van een bestaand project kan immers meestal zonder klant (of die nou intern is of extern) die in je nek hijgt, wat betekent dat het bedrijf jou in alle rust kan inwerken.

Dit geldt natuurlijk in mindere mate voor bedrijven waar je slechts aan één product werkt, maar daar kies je in dat geval zelf voor. Als je afwisseling wil moet je gaan werken voor een bedrijf dat werkt op projectbasis en zelfs daar zul je jezelf dus eerst echt moeten bewijzen.

[jip_86]

Kom je soms net van school af? Vind altijd nog wel de grootste beperking dat je nooit geleerd word met een bestaand systeem te werken. Je komt dan met je bagage, netjes ontwerpen, documenteren testen in een bedrijf werken. Maar daar blijken ze dat ineens allemaal niet te gebruiken en mag je inderdaad bugs van anderen oplossen.

[gold_dust]

Gonadan schreef op zaterdag 31 december 2016 @ 13:41:
Het is om nogal onrealistisch en ondankbaar om te verwachten dat als je ergens binnen komt alleen maar leuke en nieuwe dingen mag doen. Alle software heeft onderhoud nodig dus bugs fixen en zaken optimaliseren hoort er gewoon bij.

...

Zo heb ik ook wel sollicitanten gehad. Met oud spul willen ze niet werken, alleen leuke nieuwe dingen. Wie is er dan niet flexibel? Zoek dan maar verder.

Ik kan niet overal op reageren maar dit is een goede. Ik zal voortaan tijdens een sollicitatiegesprek direct vragen of het gaat om voornamelijk bux-fixen en onderhoud of nieuwe ontwikkeling, waarbij het ene het andere natuurlijk niet helemaal uitsluit. En vragen naar ontwikkel proces, versiebeheer, design patterns, ontwerp, is er een architect en een lead developer, achtergrond en kwalificaties van potentiële collega's en dan maar het risico te nemen om veeleisend en arrogant over te komen.

En even verder zoeken is dan inderdaad de betere optie. Wat ik overigens al doe, inmiddels al meerdere functies afgewezen toen het fixen van de problemen van anderen aan bod kwam. Dat ze geen goede mensen kunnen vinden of er niet voor willen betalen is niet mijn probleem.

[jeroen3]

gold_dust schreef op zaterdag 31 december 2016 @ 11:20:
[...]
Mijn concrete vraag is, hoe zien andere ontwikkelaars dit en hoe ga je hier mee om?

Daar blijf je vanaf, en huur je de oude mensen weer voor in. Is dat niet mogelijk, dan tel je de reverse-engineering tijd bij je tijdprognose op.

Afgelopen week kreeg ik dus "even" een Visual Basic database voorraad programma op mijn tafel geschoven om te onderhouden. Want developer ging weg. Het programma is geschreven door een student elektrotechniek welke nog nooit iets met software gedaan had. Hij heeft er een 1.5 jaar over gedaan.
Zelf heb ik nog nooit met visual basic gewerkt, of met databases, maar omdat ik zo goed was in embedded C, kon ik dat wel gaan onderhouden. Fijn .

Waarom voor zoiets überhaupt een DIY oplossing gekozen is blijft mij een raadsel. Nu kost het >20k aan loon, en dan heb je straks iets wat "een beetje" functioneert. Maar nee, het is zeker goedkoper.

Zo worden dergelijke project dus geboren.

[ Voor 4% gewijzigd door jeroen3 op 31-12-2016 15:06 ]

[Gonadan]

gold_dust schreef op zaterdag 31 december 2016 @ 14:49:
Ik kan niet overal op reageren maar dit is een goede. Ik zal voortaan tijdens een sollicitatiegesprek direct vragen of het gaat om voornamelijk bux-fixen en onderhoud of nieuwe ontwikkeling, waarbij het ene het andere natuurlijk niet helemaal uitsluit. En vragen naar ontwikkel proces, versiebeheer, design patterns, ontwerp, is er een architect en een lead developer, achtergrond en kwalificaties van potentiële collega's en dan maar het risico te nemen om veeleisend en arrogant over te komen.

Een drive naar kwaliteit zal nooit als arrogant of veeleisend gezien worden, een weigering om legacy of minder leuke klussen op te pakken wel degelijk.

Het is juist positief als een sollicitant vraagt naar wat hij kan verwachten en dat zekere eisen voor stelt. Passieve chagrijnen die het achteraf niets blijken te vinden hebben we al genoeg. Het toont initiatief en ambitie, dus vooral doen.

Daarbij kan je ook gerust vragen wat later de perspectieven zijn. Gewoon aangeven dat legacy aanpakken geen issue is, maar dat je ook vooruit wilt blijven kijken. Een goede werkgever zal ook daar het positieve van inzien. En dan heb jij duidelijkheid.

En even verder zoeken is dan inderdaad de betere optie. Wat ik overigens al doe, inmiddels al meerdere functies afgewezen toen het fixen van de problemen van anderen aan bod kwam. Dat ze geen goede mensen kunnen vinden of er niet voor willen betalen is niet mijn probleem.

Word wakker, je zult _altijd_ problemen van anderen fixen. Of ga je ook weigeren in een team te werken?

Het klinkt nu alsof jij zelf denkt eindbazen code te schrijven en dat de halve wereld troep maakt. Dan kom je dus wel arrogant over.

En uiteraard zitten er ook bedrijven tussen die wel gewoon prutswerk hebben draaien en dat goedkoop opgelost willen hebben. Daar moet ik je wel gewoon in geven, maar het klinkt alsof je ze al veel te snel in die categorie wilt schuiven.

[Dets]

Wat ik met legacy code bedoel is in code die in ieder geval een van volgende eigenschappen heeft:

- geen/gebrekkige documentatie
- geen tests
- geschreven door mensen zonder software engineering achtergrond
- geen behoorlijke version control
- geen OOD of gestructureerd ontwerp
- geen onderliggende architectuur
- oud en geschreven door mensen die het bedrijf al lang verlaten hebben
- vol met magic numbers
- maakt gebruik van legacy libraries
- etc.

Nu ik aan het solliciteren ben merk ik uit de gesprekken dat verschillende bedrijven weer verwachten dat ik code ga optimaliseren, bugs ga fixen, problemen ga oplossen van mensen die vertrokken zijn, etc. Afgezien van dat dit niet mijn interesse heeft vind ik het ook nogal onrealistisch en ondankbaar om van een nieuwe werknemer te verwachten dat die in ongedocumenteerde, slecht geschreven code van jaren oud bugs gaat lopen fixen. Ik heb zoiets van: dan had je meteen maar goede mensen moeten aannemen.

Mijn concrete vraag is, hoe zien andere ontwikkelaars dit en hoe ga je hier mee om?

Tja, dat is legacycode. De levensduur van software wordt schromelijk onderschat. Hoe goed je je best ook doet van jouw code wordt over een aantal jaren hetzelfde gezegd. Bijna alle punten die jij aandraagt zijn gewoon tekenen van "slijtage". Bij een iets grotere organisatie ontkom je er niet aan. Nieuw en (heel) oud staan naast elkaar. Als je alleen maar greenfield werk wil doen dan leer je nooit wat je als erfenis achterlaat.

[jip_86]

gold_dust schreef op zaterdag 31 december 2016 @ 14:49:
[...]toen het fixen van de problemen van anderen aan bod kwam. Dat ze geen goede mensen kunnen vinden of er niet voor willen betalen is niet mijn probleem.

Dus jij laat een collega gewoon stikken als die er niet uit komt? Je laat je baas gewoon zitten als een collega een weekje ziek is en er nog een bug in zijn code zat? Kan zo een lijst aan redenen bedenken waarom je niet altijd de leuke klusjes zal moeten doen of waarom een bedrijf iemand zoekt om een bestaand project over te nemen.

[QvTzKwCi]

Bekend probleem dit; er zit gewoon meer budget aan het begin van een project dan helemaal aan het einde.

Meestal is er zelfs helemaal geen budget meer aan het einde, als de kennis allang vertrokken is. Dan moet het op het budget van beheer - die moet het erbij doen. Maar dat is natuurlijk onrealistisch, want beheer is iets anders dan ontwikkeling en bugfixing. Meestal is beheer wel goed, maar typisch in zo'n scenario dan is ook beheer al gekort in budget. Je ziet dan ook dat het vooral uit de goodwill van werknemers moet komen. Ik bedank meestal, want daar is geen eer te behalen aan zo'n klus.

[FreezeXJ]

Eens met bovenstaande, en zoals een prof van mij ooit zei "het is makkelijker om een scheikundige te leren programmeren dan een programmeur scheikunde te leren". In principe heeft hij gelijk, maar de rotzooi-code die dat oplevert moet daarna wel door een goede programmeur onderhouden worden, anders heb je alsnog niks. Echter, het hangt dan van het bedrijf af of daar budget voor is, en hoe goed ze het achteraf willen hebben.

Je gaat zoals al door anderen aangegeven waarschijnlijk overal legacy-code zien, de vraag is hoe ze ermee omgaan. Vraag dus of er budget is om dat aan te pakken, schrijf een dekkende set unit-tests voor de essentiele stukken, en vraag of ze willen verbeteren (en wie de leiding daarover heeft/krijgt). Roepen dat het beter moet gebeurt overal, maar daadwerkelijk aanpakken is meestal het probleem, dus als je wat wilt, kijk dan of je je bedrijf over de hindernis krijgt. Lukt dat niet, dan wordt het tijd om verder te kijken.

[P1nGu1n]

Perfecte code zal je maar weinig tegen komen (als het al bestaat). Ik begrijp dat je niet wil dat al die punten die je opnoemt, van toepassing zijn, dat zou ik ook absoluut niet doen. Maar wanneer één punt van toepassing is het bedrijf al meteen afschrijven, dat lijkt me wel overdreven. Zolang de basis er al is (dus wel een redelijke architectuur), kan je die legacy library wel vervangen, project in VC zetten of wat documenteren.

downtime schreef op zaterdag 31 december 2016 @ 12:22:
[...]

Dat dus. Of ga mobile apps ontwikkelen. Die zijn veelal ook nieuw. [...]

Juist niet. Mobile apps bestaan inderdaad pas slechts een aantal jaar (8/9 jaar), dus heel oud is de code niet. Maar juist omdat het nog zo relatief nieuw is, gaat de ontwikkeling keihard en is code veel sneller 'legacy'. Zo is bijvoorbeeld het gros van de iOS apps in Objective-C geschreven, wat inmiddels alweer een opvolger heeft: Swift.

[ Voor 19% gewijzigd door P1nGu1n op 31-12-2016 18:58 ]

[Yucon]

P1nGu1n schreef op zaterdag 31 december 2016 @ 18:31:
Perfecte code zal je maar weinig tegen komen (als het al bestaat).

Ik denk dat dat het belangrijkste aspect is, en daarmee mag je 'code' wat breder zien incl zaken als documentatie. Daar zullen we het mee moeten doen maar veel belangrijker is of het bedrijf in kwestie het met de zaken uit de OP eens is. Als je tijdens het gesprek het onderwerp deze kant op weet te krijgen en vervolgens eens een 'als het werkt, dan werkt het' proefballon op laat krijg je vanzelf een idee hoe men er in staat. Als men het wel prima vindt zolang het werkt zul je de afweging moeten maken of je dat acceptabel vindt en daar wel wil werken. En als je merkt dat men het zelf ook niet heel geweldig vindt en er voor open staat er iets aan te doen dan ligt er misschien een mooie uitdaging voor je, tenminste als je het interessant vindt om ook eens naar de onderliggende procedures te kijken en daar in mee te denken.

[WhiteDog]

Tja programmeren is "nu" eenmaal gemakkelijker dan vroeger. Vaak genoeg kan ik nu honderden lijnen code vervangen door één functie uit het framework opdracht een 3rd party library.

Vind het net een uitdaging om legacy code te onderhouden en te verbeteren.

[Bossie]

Yucon schreef op zaterdag 31 december 2016 @ 22:22:
[...]

Ik denk dat dat het belangrijkste aspect is, en daarmee mag je 'code' wat breder zien incl zaken als documentatie. Daar zullen we het mee moeten doen maar veel belangrijker is of het bedrijf in kwestie het met de zaken uit de OP eens is. Als je tijdens het gesprek het onderwerp deze kant op weet te krijgen en vervolgens eens een 'als het werkt, dan werkt het' proefballon op laat krijg je vanzelf een idee hoe men er in staat. Als men het wel prima vindt zolang het werkt zul je de afweging moeten maken of je dat acceptabel vindt en daar wel wil werken. En als je merkt dat men het zelf ook niet heel geweldig vindt en er voor open staat er iets aan te doen dan ligt er misschien een mooie uitdaging voor je, tenminste als je het interessant vindt om ook eens naar de onderliggende procedures te kijken en daar in mee te denken.

Ik denk dat de definitie van perfecte code ook behoorlijk zal verschillen als je dit vraagt aan een ontwikkelaar of een PM

Mijn ervaring is dat documentatie zowel altijd minimaal hebt, als je nu een custom app hebt of een packaged applicatie van een van de grote vendors. Zodra je gaat lezen is toch altijd high level meuk dat in keurig gestandaardiseerde templates is gegoten.

@TS, stroop je mouwen op, het klinkt juist als een rol waar jij het verschil kan maken juist door de genoemde dingen te implementeren.

[DutchKel]

Ik werk intussen 7 jaar als Developer bij een groot bedrijf en intussen mag ik ook legacy code gaan herschrijven omdat de code hopeloos achterhaald is.

De techniek blijft niet stil staan mijn eerste projecten waren in .net 2.0 en intussen ben ik het grootste deel aan het omzetten naar 4.6.2 met alle optimalisaties die er zijn.

Ik heb echter wel als voordeel dat ik mijn eigen code mag herschrijven en als ik die code af en toe zie dan vraag ik me soms wel af hoe ik zoiets hopeloos heb bedacht. Toch kan ik aan de structuur zien dat het mijn eigen code is. Sommige projecten moet ik gewoon even kijken wat er precies gebeurd en dan begin ik vanaf 0 opnieuw.

Heel vroeger heb ik alles netjes gedocumenteerd en overal unit testen van gemaakt, dit heb ik een half jaar volgehouden. Toen kreeg ik bij het beoordelingsgesprek te horen dat ik sneller projecten moest opleveren en ben ik gaan bezuinigen op de documentatie en de unit testen. Dit heeft goed uitgepakt, er werd wel op het einde een integratietest gedaan die het grootste deel testte.

Dit was dus hoe in mijn situatie hetgeen ontstaat waar TS mee zit. Collega's deden hetzelfde en sommige zijn intussen inderdaad vertrokken.

Version control is er wel altijd geweest, eerst dmv mis source safe, erna git en nu via devstash/git incl octopus voor deployment

Nu zijn we wat gegroeid qua developers en zijn we een slag professioneler gaan werken met de deployment zoals met octopus werken en devstash. Maar veel oude projecten zijn ook nog steeds in gebruik.

Als iedereen denkt zoals TS dan worden er bij ons geen nieuwe ontwikkelaars aangenomen. Je krijgt bij ons wel de kans om een project opnieuw te maken maar het moet wel in een redelijk termijn af zijn. Je mag dan denken: dat is niet mijn probleem... Maar dan zit je waarschijnlijk snel zonder werk. Of je daar nou zo gelukkig van wordt.

Beter is om te vragen hoe ze met legacy code omgaan. Mag je het herschrijven vanaf scratch? Of moet je het onderhouden as-is?

[gold_dust]

FreezeXJ schreef op zaterdag 31 december 2016 @ 17:30:
Eens met bovenstaande, en zoals een prof van mij ooit zei "het is makkelijker om een scheikundige te leren programmeren dan een programmeur scheikunde te leren". In principe heeft hij gelijk, maar de rotzooi-code die dat oplevert moet daarna wel door een goede programmeur onderhouden worden, anders heb je alsnog niks. Echter, het hangt dan van het bedrijf af of daar budget voor is, en hoe goed ze het achteraf willen hebben.

Ik kan niet overal op reageren maar dit is ook wat ik nu al 10 jaar zie. Het hele probleem met slechte code is ook alleen maar een oorzaak van alle prutsers die er rondlopen en niet iets wat op zichzelf staat. Het terecht komen in een bedrijf waar ik dit soort code moet onderhouden en debuggen is juist wat ik absoluut niet zoek, dan hadden ze in de eerste plaats maar goede mensen aan moeten nemen.

Ik zie in ieder geval een verschil tussen een ontwikkelaar die nieuwe dingen ontwikkelt en iemand die alleen maar onderhoud en bug-fixing doet en dan vaak ook nog in de puinhoop die door iemand anders is achtergelaten. Uit de reacties hier peil ik dat veel 'ontwikkelaars' van het tweede type zijn en bedrijven ook naar dit type 'ontwikkelaar' op zoek zijn. Daar was ik me tot nu eigenlijk niet bewust van en het is gewoon niet wat ik zoek.

[naitsoezn]

Als je vooraan wilt staan bij het ontwikkelingen van nieuwe toepassingen / toevoegen met een sterk technisch / wetenschappelijk karakter, zul je toch meer moeten weten dan ontwerppatronen, versiebeheer en grondig testen. Je zult vooral thuis moeten zijn in de achtergrond van de toepassingen (bv die chemische / fysische hoek).

offtopic:
Bovendien vind ik je insteek erg negatief, zwart/wit en een tikkeltje ongepast arrogant.

[CodeCaster]

gold_dust schreef op zondag 1 januari 2017 @ 12:30:
[...]

Ik kan niet overal op reageren maar dit is ook wat ik nu al 10 jaar zie. Het hele probleem met slechte code is ook alleen maar een oorzaak van alle prutsers die er rondlopen en niet iets wat op zichzelf staat. Het terecht komen in een bedrijf waar ik dit soort code moet onderhouden en debuggen is juist wat ik absoluut niet zoek, dan hadden ze in de eerste plaats maar goede mensen aan moeten nemen.

Ik zie in ieder geval een verschil tussen een ontwikkelaar die nieuwe dingen ontwikkelt en iemand die alleen maar onderhoud en bug-fixing doet en dan vaak ook nog in de puinhoop die door iemand anders is achtergelaten. Uit de reacties hier peil ik dat veel 'ontwikkelaars' van het tweede type zijn en bedrijven ook naar dit type 'ontwikkelaar' op zoek zijn. Daar was ik me tot nu eigenlijk niet bewust van en het is gewoon niet wat ik zoek.

Dus iemand die aan onderhoud doet, is volgens jou per definitie geen ontwikkelaar? Of vanwaar anders de schampere aanhalingstekens? De noodzaak voor onderhoud is zeer zeker niet enkel aanwezig door het bestaan van prutsers, wat hierboven al meermaals is geprobeerd aan je uit te leggen. Niet alleen slechte code hoeft onderhouden te worden.

Zoals ook al eerder gezegd, "greenfield"-projecten (nieuwe projecten zonder bagage) zijn zeldzaam. Als je vraag is hoe je op zulke projecten terechtkomt: jezelf eerst bewijzen door (is 'ie weer) onderhoud uit te voeren, en zo te laten zien dat je een fijne collega bent die weet waar 'ie het over heeft, die het bedrijfsproces begrijpt en dan hopen dat er een stuk verouderde techniek op het punt staat om vervangen te worden, of dat er in een nieuwe nood voorzien moet gaan worden.

Je komt zonder indrukwekkend cv niet zomaar ergens binnen om in een zandbak vrijgelaten te worden om volledig losstaand van de rest van het bedrijf (of althans: de in gebruik zijnde ontwikkelprocessen en bestaande systemen) een nieuw project tot uitvoering te brengen. Zo wel, dan is het project waarschijnlijk al niet interessant genoeg.

[ Voor 8% gewijzigd door CodeCaster op 01-01-2017 13:07 ]

[Hydra]

Ik vind het wel wat makkelijk stellen dat dit "overal" zo is. Er is nogal een verschil tussen grote complexe systemen en systemen waar men jarenlang er met de pet naar gegooid heeft. Ik zit zelf bij een klein gespecialiseerde (Java) consulting club en projecten in de eerste categorie doen wij wel. Projecten in de 2e categorie bedanken wij voor.

Mijn ervaring is dat dergelijke prutssoftware vooral het gevolg is van een prutscultuur. Het is voor developers erg makkelijk om het altijd maar op management af te schuiven; management wil features en geen tests. M.i. is dat complete kolder; tests e.d. zijn een onderdeel van mijn werk. Software engineering is een vak. Je gaat van een chirurg ook niet accepteren dat 'ie z'n handshoenen in 't lichaam achterlaat en maar de helft van het aantal hechtingen dat nodig is gebruikt. Software is niet anders; voor alles complexer dan een PoC heb je een fatsoenlijke test coverage nodig want anders flikkert de hele bende om als je iets moet aanpassen.

[CodeCaster]

Hydra schreef op zondag 1 januari 2017 @ 13:10:
Ik vind het wel wat makkelijk stellen dat dit "overal" zo is. Er is nogal een verschil tussen grote complexe systemen en systemen waar men jarenlang er met de pet naar gegooid heeft. Ik zit zelf bij een klein gespecialiseerde (Java) consulting club en projecten in de eerste categorie doen wij wel. Projecten in de 2e categorie bedanken wij voor.

Mijn ervaring is dat dergelijke prutssoftware vooral het gevolg is van een prutscultuur. Het is voor developers erg makkelijk om het altijd maar op management af te schuiven; management wil features en geen tests. M.i. is dat complete kolder; tests e.d. zijn een onderdeel van mijn werk. Software engineering is een vak. Je gaat van een chirurg ook niet accepteren dat 'ie z'n handshoenen in 't lichaam achterlaat en maar de helft van het aantal hechtingen dat nodig is gebruikt. Software is niet anders; voor alles complexer dan een PoC heb je een fatsoenlijke test coverage nodig want anders flikkert de hele bende om als je iets moet aanpassen.

Je realiseert je toch wel dat je daarmee een uitzondering bent? Er lopen gewoon een héleboel middelmatige ontwikkelaars rond, die het belangrijker vinden om de baas of de klant zo snel en goedkoop mogelijk te pleasen en betaald te krijgen dan om een netjes opgezet, goed onderhoudbaar systeem neer te zetten.

Als de kritische massa van een team uit zulke mensen bestaat, kan er nog zo veel moois worden beloofd tijdens om het even welke vergadering, het eindresultaat komt toch weer neer op "het werkt toch?".

Dan nog, de topicstarter is blijkbaar op zoek naar zo'n bedrijf als het jouwe. Vertel hem dan ook hoe je bij jullie binnenkomt of hoe hij zulke bedrijven kan vinden.

[Hydra]

CodeCaster schreef op zondag 1 januari 2017 @ 13:35:
Je realiseert je toch wel dat je daarmee een uitzondering bent?

Nouja. Ik hoop meestal van niet. Maar het is inderdaad wel iets wat me enorm stoort. De cultuur van middelmatigheid bij de meeste software bedrijven. "It compiles, ship it!" zou een grap moeten zijn, niet de harde realiteit.

Dit neemt niet aan dat het is hoe het hoort en stellen dat het "vrijwel altijd" zo gaat vind ik te kort door de bocht en veel te cynisch. Ik zit zelf bij de ING bijvoorbeeld en daar, hoewel er zeker sprake is van legacy en een hoop oude applicaties, gaan ze er wel een heel stuk beter mee om.

Als de kritische massa van een team uit zulke mensen bestaat, kan er nog zo veel moois worden beloofd tijdens om het even welke vergadering, het eindresultaat komt toch weer neer op "het werkt toch?".

Dat is zeker herkenbaar. Ik ben op intake geweest bij een bedrijf waar al 2 collega's een jaar zaten. Ik wist al hoe het er aan toe ging dus ik had er al weinig zin in, maar onze account manager wou, gezien het op de route van een andere intake was, er toch ff langs. Het was zo dramatisch dat we ons als bedrijf daar teruggetrokken hebben; er is weinig dat je kan doen als de meeste andere developers en de architecten (die ons nota bene gevraagd hadden) niet willen veranderen.

Dan nog, de topicstarter is blijkbaar op zoek naar zo'n bedrijf als het jouwe. Vertel hem dan ook hoe je bij jullie binnenkomt of hoe hij zulke bedrijven kan vinden.

Er zijn genoeg grote bedrijven waar het tempo gewoon wat lager ligt en je de tijd krijgt dingen goed te doen. Daarnaast zijn er genoeg kleine consulting clubs die zich specialiseren in echte vakmensen. Ik ben geen grote fan van hier m'n eigen bedrijfsnaam te noemen maar als de TS aangeeft waar z'n interesses liggen kan ik misschien wel suggesties doen.

[psychodude]

Persoonlijk werk ik in een totaal andere tak van sport (geneeskunde en medisch-wetenschappelijk onderzoek). Maar overeenkomstig is zo nu en dan wel het feit dat je het niet altijd eens bent met het eerdere verrichte werk van anderen of de begrijpelijkheid / documentatie soms ver te zoeken is. Belangrijk daarin te realiseren is wel dat dit ook net zo goed vice versa kan zijn. Wat voor jou misschien als eenvoudig en begrijpelijk wordt ervaren, kan voor een ander tenslotte een volkomen raadsel zijn.

Zelf reflectie is ook altijd een mooie. Zo kun je ook prima eigen werk van een aantal jaar geleden terug voorbij zien komen, en jezelf afvragen hoe je dit ooit als dusdanig zo hebt kunnen doen.

Nu kan ik mij prima voorstellen dat je meer zoekt in je werk dan enkel en alleen puin ruimen. Maar ik denk ook zeker niet dat je alles op alles moet zetten om het uit de weg te gaan. Maar het juist ook moet aangrijpen als mogelijkheid om het zelf anders / beter aan te pakken. En ik kan mijzelf ook goed voorstellen dat zodra jij toonbaar kunt laten zien dat jij ook hierin kunt accelereren, je gemakkelijker hogerop kunt komen en ook op die wijze je voet tussen de deur kunt krijgen tot ontwikkeling van nieuw bovenop onderhouden van het oude.

[gold_dust]

CodeCaster schreef op zondag 1 januari 2017 @ 13:04:
Dus iemand die aan onderhoud doet, is volgens jou per definitie geen ontwikkelaar? Of vanwaar anders de schampere aanhalingstekens? De noodzaak voor onderhoud is zeer zeker niet enkel aanwezig door het bestaan van prutsers, wat hierboven al meermaals is geprobeerd aan je uit te leggen. Niet alleen slechte code hoeft onderhouden te worden.

Inderdaad, dat vind ik al meer onder beheer vallen. Op zich is het niet erg dat de meeste bedrijven en 'ontwikkelaars' beheer doen maar communiceer dan ook duidelijk over in een sollicitatieprocedure dat je beheerders zoekt in plaats van net te doen alsof je ontwikkelaars zoekt.

Zoals ook al eerder gezegd, "greenfield"-projecten (nieuwe projecten zonder bagage) zijn zeldzaam. Als je vraag is hoe je op zulke projecten terechtkomt: jezelf eerst bewijzen door (is 'ie weer) onderhoud uit te voeren, en zo te laten zien dat je een fijne collega bent die weet waar 'ie het over heeft, die het bedrijfsproces begrijpt en dan hopen dat er een stuk verouderde techniek op het punt staat om vervangen te worden, of dat er in een nieuwe nood voorzien moet gaan worden.

Ik verwacht geen 'Greenfield projecten', vrijwel niemand ontwikkelt nog volledig van scratch en dat is ook niet zinvol. Er zijn voldoende goede open source frameworks te vinden die volwassen, gedocumenteerd, en getest zijn die je kan toepassen. Gek genoeg zit het met veel open source projecten dan wel weer vrij goed met de kwaliteit van de code maar lukt het veel bedrijven intern niet op dit op orde te krijgen of om enigszins competente ontwikkelaars te vinden.

[CodeCaster]

gold_dust schreef op zondag 1 januari 2017 @ 15:32:
[...]
Inderdaad, dat vind ik al meer onder beheer vallen.

Dus iemand die een pull request indient voor een opensourceproject is geen ontwikkelaar meer, maar een beheerder? Dan is het probleem dat hier speelt eenvoudigweg een definitiekwestie, waarbij jij het bij het verkeerde eind hebt. Dat gaat uiteraard voor problemen zorgen tijdens je zoektocht. Dat is verder niet erg, kan gebeuren.

Verder houdt greenfield niet in dat je zonder libraries of frameworks werkt, maar juist dat je niet gebonden bent aan eerdere projecten binnen het bedrijf.

[ Voor 19% gewijzigd door CodeCaster op 01-01-2017 15:47 ]

[CurlyMo]

gold_dust schreef op zondag 1 januari 2017 @ 15:32:
Gek genoeg zit het met veel open source projecten dan wel weer vrij goed met de kwaliteit van de code maar lukt het veel bedrijven intern niet op dit op orde te krijgen of om enigszins competente ontwikkelaars te vinden.

Ik neem aan dat je hier met Open Source ook de gratis beschikbare projecten bedoelt. Vanuit die aanname is het juist niet gek dat dat kan. Een OSS project kan eisen dat code volgens een bepaalde kwaliteit wordt opgeleverd, omdat ze geen targets te halen hebben, geen klanten om tevreden te stellen binnen een bepaalde tijd, ze hebben op de eerste plaats hun eigen plezier en kwaliteit te bewaken.

In mijn vrije tijd probeer ik regelmatig bijdragen te leveren aan OSS projecten. Laatst nog bezig geweest met het integreren van interrupt ondersteuning in libuv (NodeJS eventing library). Het hele proces heeft me misschien totaal 8 uur gekost (over meerdere weken), met 100de review commentaren. Dat lag deels aan mijn gemakzucht. Liever horen dat een bepaald haakje anders geschreven dient te worden in hun code stijl, dan dat ik dat allemaal van tevoren had uitgezocht.

In de organisatie waar ik werk wordt veel OSS gebruikt. Ook passen we veel OSS aan. Er dient dus budget vrij gemaakt te worden om code terug te brengen upstream, want dat kost (door de eisen die OSS projecten kunnen stellen) nu eenmaal veel tijd en dus geld.

[RagingPenguin]

gold_dust schreef op zondag 1 januari 2017 @ 15:32:
[...]
Ik verwacht geen 'Greenfield projecten', vrijwel niemand ontwikkelt nog volledig van scratch en dat is ook niet zinvol. Er zijn voldoende goede open source frameworks te vinden die volwassen, gedocumenteerd, en getest zijn die je kan toepassen. Gek genoeg zit het met veel open source projecten dan wel weer vrij goed met de kwaliteit van de code maar lukt het veel bedrijven intern niet op dit op orde te krijgen of om enigszins competente ontwikkelaars te vinden.

Al begin je een nieuw project met een framework is het nog steeds een Greenfield project. Een Greenfield project houd in dat je geen balast hebt van een bestaand systeem en zegt verder niets over hoe je het nieuwe project aanpakt.

En zoals men boven mij ook al zei: onderhoud is gewoon development. Maar zelfs binnen een bestaand systeem kan je prima nieuwe dingen bouwen. Beheerders zijn voor de dev gewoon gebruikers die verder niets aan de code veranderen (hoop je )

[gold_dust]

Onderhoud/bugs fixen vind ik geen development, uitbreiding van een bestaand systeem wel. Daar ligt denk ik ook het probleem in de software sector: er wordt geen duidelijk onderscheid gemaakt tussen onderhoud/beheer van software enerzijds en development anderzijds. Dat is al iets nuttigs wat er uit dit topic is gekomen en waar ik bij een volgend gesprek gericht naar zal vragen.

[CodeCaster]

gold_dust schreef op zondag 1 januari 2017 @ 16:33:
Onderhoud/bugs fixen vind ik geen development

Daar verschil jij dan van mening over met een heleboel ontwikkelaars.

Maar waaróm dan niet? Hoef je bij bugfixes geen analyse, ontwerp, tests, implementatie en uitrol- en eventueel rollback-plan te maken? Wat is er zo significant anders aan bugfixing dan aan het ontwikkelen van nieuwe features of nieuwe projecten? Of vind je het gewoon niet leuk om aan oude code te zitten, of soms te moeten reverse engineeren omdat iets niet volledig is afgetest en/of -gespect?

Ik zou bij eventuele sollicitaties in ieder geval niet dezelfde bewoordingen gebruiken als hier, inclusief sarcastische aanhalingstekens. Zoals naitsoezn al aangaf komt dat nogal denigrerend over. Dus niet: "Wordt er van mij verwacht dat ik moet gaan 'ontwikkelen' oftewel bugfixen, of zijn jullie serieus op zoek naar een developer?" of iets in die trant.

Door bugfixing expliciet géén ontwikkeling te noemen, ga je in ieder geval geen hoge ogen gooien op je intakes.

[ Voor 9% gewijzigd door CodeCaster op 01-01-2017 17:10 ]

[NMe]

gold_dust schreef op zondag 1 januari 2017 @ 16:33:
Onderhoud/bugs fixen vind ik geen development,

Dus alle code die jij schrijft is perfect, en blijft altijd werken ongeacht nieuwe beperkingen die door veranderingen in andere hard- of software door de jaren heen worden opgelegd? Met zo'n instelling waarbij je je te goed voelt om bestaande producten te onderhouden ga je het ver schoppen, hoor...

[Bossie]

NMe schreef op zondag 1 januari 2017 @ 17:08:
[...]

Dus alle code die jij schrijft is perfect, en blijft altijd werken ongeacht nieuwe beperkingen die door veranderingen in andere hard- of software door de jaren heen worden opgelegd? Met zo'n instelling waarbij je je te goed voelt om bestaande producten te onderhouden ga je het ver schoppen, hoor...

De code die ik schrijf, is op dat moment perfect, of beter gezegd, fit for purpose
Ik kijk er nu al naar om binnenkort een aantal items te herschrijven die ik drie jaar geleden heb gemaakt.

Niet omdat de code slecht is, maar bijvoorbeeld omdat ik nu als developer nu drie jaar verder ben en door andere ervaringen/projecten zie hoe ik een x-aantal oudere items kan optimaliseren.

Ben ik nu een uitzonderlijke developer
Overigens is 2/3 in mijn werk onderhoud/changes van oude code, niet omdat de code niet goed is, maar omdat de ondersteunende bedrijfsprocessen of bijvoorbeeld KPI-definities ook veranderen.

[gold_dust]

CodeCaster schreef op zondag 1 januari 2017 @ 16:48:

Daar verschil jij dan van mening over met een heleboel ontwikkelaars.

Ik ken verschillende ontwikkelaars, internationaal, en ik ken niemand die zich ontwikkelaar noemt en gericht op zoek gaat naar functies die voornamelijk bestaan uit het fixen van bugs en het refactoren van code. Helemaal als als het om een erfenis gaat van een spreekwoordelijke scheikundige die denkt dat hij kan programmeren en die inmiddels het bedrijf verlaten heeft. Dat je je eigen bugs fixt en code onderhoudt vind ik dan wel weer evident.

Of vind je het gewoon niet leuk om aan oude code te zitten, of soms te moeten reverse engineeren omdat iets niet volledig is afgetest en/of -gespect?

Zoals Hydra ook al benoemd, bepaalde systemen is zo met de pet naar gegooid dat je dat die beter links kan laten liggen. Het is soms lastig om vooraf te bepalen waar je wel of niet moet gaan werken. Ik ben inderdaad niet het type dat de rommel van anderen gaat lopen opruimen en daar wil ik inderdaad graag van de voren duidelijkheid over hebben.

[CodeCaster]

gold_dust schreef op zondag 1 januari 2017 @ 17:26:
[...]

ik ken niemand die zich ontwikkelaar noemt en gericht op zoek gaat naar functies die voornamelijk bestaan uit het fixen van bugs en het refactoren van code

Ik ook niet, maar zo begonnen we niet. Jij noemde mensen die bugs fixen "ontwikkelaars", inclusief aanhalingstekens. En dat is gewoon denigrerend en gaat je geen steek verder helpen. Hier op het forum niet, en bij je sollicitaties al helemaal niet.

gold_dust schreef op zondag 1 januari 2017 @ 17:26:
Het is soms lastig om vooraf te bepalen waar je wel of niet moet gaan werken.

Dat ben ik helemaal met je eens, en de kwestie hóe je dat nu goed kunt bepalen vind ik ook een interessante. De rest van je opmerkingen vind ik alleen nogal een beetje onnodig kwetsend richting een heleboel mensen.

[ Voor 33% gewijzigd door CodeCaster op 01-01-2017 17:35 ]

[orf]

gold_dust schreef op zondag 1 januari 2017 @ 17:26:
[...]
Het is soms lastig om vooraf te bepalen waar je wel of niet moet gaan werken. Ik ben inderdaad niet het type dat de rommel van anderen gaat lopen opruimen en daar wil ik inderdaad graag van de voren duidelijkheid over hebben.

Een dag meedraaien in een team. Je kan dan precies zien hoe de werkwijze is, zonder dat het mooier gemaakt wordt door iemand in een sollicitatiegesprek. Voor het bedrijf kan het ook een mooie manier zijn om te zien wat ze met jou in huis halen, hoe je omgang met toekomstige collega's was, etc.

[NMe]

gold_dust schreef op zondag 1 januari 2017 @ 17:26:
[...]

Zoals Hydra ook al benoemd, bepaalde systemen is zo met de pet naar gegooid dat je dat die beter links kan laten liggen. Het is soms lastig om vooraf te bepalen waar je wel of niet moet gaan werken. Ik ben inderdaad niet het type dat de rommel van anderen gaat lopen opruimen en daar wil ik inderdaad graag van de voren duidelijkheid over hebben.

Het soort bedrijf dat jou op je eerste werkdag aan het werk zet op een nieuw project zonder een goed beeld te hebben van wat je kan is nou net het type bedrijf waar dat soort brakke code geschreven wordt die niemand meer wil onderhouden. Je leidinggevende heeft dan totaal geen idee van wat je nou écht kan maar laat je wel meteen los op een nieuw project, daar krijg je nogal makkelijk slecht onderhoudbare code van. En als je vervolgens na je proeftijd geen vast contract krijgt zitten ze met die code te kijken.`

[jip_86]

Daar moet je dan ook beheerders voor in dienst nemen

[gold_dust]

CodeCaster schreef op zondag 1 januari 2017 @ 17:33:
Ik ook niet, maar zo begonnen we niet. Jij noemde mensen die bugs fixen "ontwikkelaars", inclusief aanhalingstekens. En dat is gewoon denigrerend en gaat je geen steek verder helpen. Hier op het forum niet, en bij je sollicitaties al helemaal niet.

Het wordt nu meer een semantische discussie over wat een ontwikkelaar is maar er zit een groot verschil tussen enerzijds iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt. Ik kan me eigenlijk niet voorstellen dat je dit verschil niet ziet.

Uit de reacties haal ik dat de meeste ontwikkelaars van het laatste type zijn en ook de meeste bedrijven zijn op zoek naar dat type ontwikkelaar. Dat is prima, maar dus niet wat ik wil ga doen.

[Tsurany]

Volgens mij heb jij totaal geen idee welke complexiteit kan komen kijken bij het toevoegen van features, het fixen van bugs en vervolgens het implementeren hiervan in grote applicaties in bedrijfskritische omgevingen.

Het is prima dat jij liever vanaf nul begint, maar schrijf dan niet alle andere ontwikkelaars weg als mensen die nergens over na hoeven te denken. Dat is onnodige generalisatie, daar kom je echt niet ver mee.

De meeste bedrijven zijn op zoek naar ontwikkelaars om systemen te onderhouden en uit te breiden simpelweg omdat vrijwel geen enkel bestaand bedrijf zich kan veroorloven om elke twee jaar alle applicaties weg te gooien en een compleet nieuw software landschap neer te zetten. Een bedrijf heeft nu eenmaal zijn applicaties die al jaren draaien en waar ze enorm afhankelijk van zijn. Juist in zulke situaties kan het een hele uitdaging zijn om features toe te voegen en bestaande bugs te fixen vanwege de complexiteit.

Als jij enkel vanaf scratch wilt werken moet je kijken naar startups, bedrijven die echt vanaf niks beginnen. En dan natuurlijk na twee jaar vertrekken aangezien je anders features moet gaan toevoegen aan bestaande code.

[orf]

Tsurany schreef op maandag 2 januari 2017 @ 00:52:
De meeste bedrijven zijn op zoek naar ontwikkelaars om systemen te onderhouden en uit te breiden simpelweg omdat vrijwel geen enkel bestaand bedrijf zich kan veroorloven om elke twee jaar alle applicaties weg te gooien en een compleet nieuw software landschap neer te zetten. Een bedrijf heeft nu eenmaal zijn applicaties die al jaren draaien en waar ze enorm afhankelijk van zijn. Juist in zulke situaties kan het een hele uitdaging zijn om features toe te voegen en bestaande bugs te fixen vanwege de complexiteit.

Hier een mooi (maar oud) artikel over het herschrijven van code:

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material?

https://www.joelonsoftwar...u-should-never-do-part-i/

[CurlyMo]

gold_dust schreef op maandag 2 januari 2017 @ 00:07:
[...]

Het wordt nu meer een semantische discussie over wat een ontwikkelaar is maar er zit een groot verschil tussen enerzijds iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt. Ik kan me eigenlijk niet voorstellen dat je dit verschil niet ziet.

Uit de reacties haal ik dat de meeste ontwikkelaars van het laatste type zijn en ook de meeste bedrijven zijn op zoek naar dat type ontwikkelaar. Dat is prima, maar dus niet wat ik wil ga doen.

Vergeet niet dat ze in veel bedrijven onbekend onbekwaam zijn. Men vraagt dus naar wat jij ontwikkelaar type 2 noemt, omdat ze niet weten dat ze daadwerkelijk ontwikkelaar type 1 nodig hebben.

Je komt dus zoals je zelf beschrijft in een organisatie terecht met "legacy code", omdat men simpelweg niet beter weet. Het zijn ook zoals je zelf zegt de onderzoekers die hebben leren programmeren. Weten zij veel van unit tests, OOP, design patterns enz. Men weet dus simpelweg niet hoe belangrijk ontwikkelaar type 1 is, omdat ze die wereld niet kennen.

Ik heb wel gemerkt hoe flexibel dit type collega daarbij is. Iemand die in staat is zijn onderzoekskennis om te zetten naar (brakke) code laat zien dat er een zekere potentie zit. Ik vind het te gek om te zien dat niet-programmeurs met bepaalde ICT tools toch tot een oplossing kunnen komen. Ze hebben alleen de juiste kaders nodig zoals jij ook beschrijft.

Naar mijn mening vervul je je rol pas echt goed als je vanuit type 2 een organisatie binnenkomt en je jezelf in een type 1 ontwikkelaar kan brengen, omdat je de organisatie heb kunnen laten zien dat dat type ontwikkelaar nodig is, en je daarin tevens je collega's kan meenemen. Zij hebben immers de inhoudelijke (onderzoeks)kennis die je zult moeten extraheren.

In mijn organisatie heb ik een jaar lang als type 2 ontwikkelaar gewerkt. Zo leerde ik de systematiek, (on)bekwaamheid van mijn collega's, (gebrek aan) documentatie enz. kennen zonder mijn collega's tegen het hoofd te stoten. De output die men wist te generen was echt van hoge kwaliteit, alleen de weg er naartoe erg inefficiënt. Er zat heel veel kennis die alleen niet goed tot uiting kwam (d.w.z. slechte programmatuur, documentatie, tests). Daarna ben ik langzaam verbeteringen aan gaan brengen en heb ik deze in een proof-of-concept gezet. Daar werd het management enthousiast van waarna ik ben doorgegroeid naar jouw ontwikkelaar type 1. Dat vraagt alleen wel een andere houding, zoals velen hier ook beschrijven.

Nu werken we in een structuur waarin collega's aan het documenteren zijn geslagen, unit tests aan het uitdenken zijn, schema's ontwerpen. Strict gezien allemaal niet eens perse ICT, maar gewoon een juiste structuur aanbieden. De techniek komt pas om de hoek zodra iets daadwerkelijk in een technische implementatie moet worden omgezet, het uitdenken daarnaartoe kan prima met niet programmeurs zolang je ze maar helpt. Nu ben ik zelf de schakel tussen het ruwe ICT programmeerwerk en het onderzoek. Ik vertaal al het denkwerk naar technische implementaties, maar de uitwerking wordt dan weer gedaan door echte programmeurs.

Dat is voor mij dan ook de belangrijkste meerwaarde van Agile werken. Niet persé snel ontwikkelen, maar samenwerking en communicatie op gang brengen en houden.

[ Voor 5% gewijzigd door CurlyMo op 02-01-2017 11:20 ]

[Tarkin]

gold_dust schreef op maandag 2 januari 2017 @ 00:07:
[...]

Het wordt nu meer een semantische discussie over wat een ontwikkelaar is maar er zit een groot verschil tussen enerzijds iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt. Ik kan me eigenlijk niet voorstellen dat je dit verschil niet ziet.

Uit de reacties haal ik dat de meeste ontwikkelaars van het laatste type zijn en ook de meeste bedrijven zijn op zoek naar dat type ontwikkelaar. Dat is prima, maar dus niet wat ik wil ga doen.

Je begaat een denkfout. In jouw ogen is elke bug al doodgeanalyseerd en moet de developer enkel nog de code aanpassen. Uit ervaring weet ik dat het zo niet is.

Het begint meestal met een mooi uitgebreid ticketje van de helpdesk: applicatie xyz crasht... (en ja dat is het hel ticket). En bij sommige legacy kan je dan een paar dagen analyseren uitzoeken waarom dat gebeurt, overleggen wat de juiste oplossing is om binnen de gekende muren toch de boel deftig te fixen,... Er is enorm veel uitdaging te vinden in bugfixing, je leert er ook de systemen en de domeinkennis veel beter door.

In al mijn verschillende jobs is het altijd al beide geweest, nieuw development maar ook bugfixing. Soms was dat gewoon standaard 30% van de week bugfixing en 70% van de week nieuw development. Op andere jobs was dat wat meer flou.

Ik moet wel eerlijk zeggen dat als jij met zo'n arrogantie in mijn team komt, je er ook niet lang gaat zitten. Of het nu enkel nieuw development is of niet, je komt me een beetje over als de "rockstar programmer", je vind van jezelf dat enkel jij goede code kan schrijven en dat al de rest shit is...

[Ryur]

Tarkin schreef op maandag 2 januari 2017 @ 11:25:
[...]


Je begaat een denkfout. In jouw ogen is elke bug al doodgeanalyseerd en moet de developer enkel nog de code aanpassen. Uit ervaring weet ik dat het zo niet is.

Het begint meestal met een mooi uitgebreid ticketje van de helpdesk: applicatie xyz crasht... (en ja dat is het hel ticket). En bij sommige legacy kan je dan een paar dagen analyseren uitzoeken waarom dat gebeurt, overleggen wat de juiste oplossing is om binnen de gekende muren toch de boel deftig te fixen,... Er is enorm veel uitdaging te vinden in bugfixing, je leert er ook de systemen en de domeinkennis veel beter door.

In al mijn verschillende jobs is het altijd al beide geweest, nieuw development maar ook bugfixing. Soms was dat gewoon standaard 30% van de week bugfixing en 70% van de week nieuw development. Op andere jobs was dat wat meer flou.

Ik moet wel eerlijk zeggen dat als jij met zo'n arrogantie in mijn team komt, je er ook niet lang gaat zitten. Of het nu enkel nieuw development is of niet, je komt me een beetje over als de "rockstar programmer", je vind van jezelf dat enkel jij goede code kan schrijven en dat al de rest shit is...

Ben het volledig met jou eens!

Ik zelf werk bij een bedrijf waar ik ook zo'n 30/70 verhouding heb (momenteel zelfs meer nieuwe ontwikkelingen omdat dat even meer prio heeft, is al verkocht aan de klant).

De bugfixes die ik doe komen binnen, en dan moet je uitzoeken waar het ligt. Omdat de systemen waar ik mee werk bedrijfkritisch is (werk in de ERP-wereld) kan ik niet zomaar een fix opleveren zonder het zeer uitgebreid te testen/documenteren. Als het mis gaat bij mijn bugfix kan het zo zijn dat ik 1 miljoen euro heb verspilt bij de klant (of zelfs nog meer).
Dus ja ik moet een uitgebreide analyse maken: hoe kom ik zo dat de bug triggert, welke randvoorwaarden zijn er nodig; wat is mijn besloten oplossing (ontwerp); implementatie & daarna het allerbelangrijkste: testen op een lokale omgeving, en daarna als ik volledig zeker ben: testen op de accept omgeving.
En dan dit allemaal documenteren, want mocht er dus een fout zijn gemaakt, dan moet er snel achterhaalt kunnen worden wat de wijzigingen zijn (en vooral WAAROM!).

En ik ben het volledig eens wat hier wordt gezegd over de houding.

[NMe]

gold_dust schreef op maandag 2 januari 2017 @ 00:07:
[...]

Het wordt nu meer een semantische discussie over wat een ontwikkelaar is maar er zit een groot verschil tussen enerzijds iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt. Ik kan me eigenlijk niet voorstellen dat je dit verschil niet ziet.

Uit de reacties haal ik dat de meeste ontwikkelaars van het laatste type zijn en ook de meeste bedrijven zijn op zoek naar dat type ontwikkelaar. Dat is prima, maar dus niet wat ik wil ga doen.

Serieus, get over yourself. Het is een totaalpakket. Als programmeur ben je niet alleen maar bezig met nieuw spul schrijven, je moet ook zorgen dat reeds bestaande software maar eens blijft werken. Als je je daar te goed voor voelt niet je dat zelf weten maar hou asjeblieft op met al dat gesteek onderwater naar al die "inferieure ontwikkelaars" die zich wel "tot dat niveau verlagen." Er is hier maar één iemand die totaal geen team player lijkt te zijn en daardoor inferieur zou zijn als ontwikkelaar. In het bedrijf waar ik werk zou je met deze instelling waarschijnlijk al niet door de sollicitatieprocedure heen komen.

Je gaat echt waar je ook terecht komt bedrogen uitkomen als je denkt niet met enige regelmaat bugs te hoeven fixen, al dan niet in andermans code.

[Lethalis]

gold_dust schreef op zondag 1 januari 2017 @ 16:33:
Onderhoud/bugs fixen vind ik geen development, uitbreiding van een bestaand systeem wel.

Ik zal het doorgeven aan de helpdesk hier, kunnen ze de bugs zelf gaan oplossen voortaan

Natuurlijk is bug fixen development. Sterker nog, het kan een stuk complexer zijn dan nieuwe code schrijven. Daarnaast vind ik de speurtocht ook wel interessant.

Het is ook gewoon een verlengde van jouw eigen werk. Als jij applicatie X bouwt en oplevert, vervolgens constateren mensen daar problemen in, dan is het toch logisch dat jij deze ook oplost?

Dat hoort gewoon bij jouw werk. Jij bent immers ook de "information expert" ( ). Jij hebt de code geschreven, dus jij weet het beste hoe je de bug moet oplossen.

[CurlyMo]

Ik denk dat de discussie die TS aanhaalt niet helemaal onzin is. Natuurlijk zit er wel een verschil tussen "software architect" of een "php ontwikkelaar". Helemaal als ze in de hiërarchie van junior naar senior worden gezet of in opleidingsniveau. Een WO software architect heeft nu eenmaal veel meer taken en verantwoordelijkheden dan een MBO php programmeur. In dat kader gezien is het niet gek dat TS zo denkt.

[...] iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt.

De vraag is alleen of je de scheidslijn zo zwart / wit kan maken. Als jij als software architect in het verleden een stukje code hebt geschreven waar een bug in zit, ga je dan aan je junior ontwikkelaar vragen om er dagen op te zwoegen terwijl je het zelf misschien in een uurtje hebt opgelost, omdat het nu eenmaal jouw code was toen je zelf nog ontwikkelaar was en je nu eenmaal veel meer ervaring hebt.

Ik kan echter niet voor TS beoordelen of hij/zij de kennis en/of ervaring heeft om direct in een senior architecten functie terecht te komen of niet. Alleen kan je nooit afdwingen dat je geen rot klusjes doet, of je nu senior bent of niet en of je nu in een WO functies zit of niet. Die dingen horen er nu eenmaal altijd bij.

Daarnaast willen veel organisaties eerst de kat uit de boom kijken. Ben je wel geschikt om door te groeien naar een betere functie met die verantwoordelijkheden of straal je teveel arrogantie uit om een team te kunnen leiden van ontwikkelaars. Zoals je merkt heb je met je vraag al de nodige weerstand gecreëerd, dus beschouw dat als een les voor hoe je het beter niet kunt aanpakken

[gold_dust]

Bedankt voor de reacties zover. Wat wel duidelijk is geworden is dat verreweg de meeste ontwikkelaars van het type 'software onderhouden en bugs fixen is' en dat bedrijven ook bijna uitsluitend op zoek zijn naar dit type ontwikkelaar. Niet dat daar iets mis mee is, maar ik was me hier eigenlijk niet zo bewust van. Dit inzicht is zeker iets waar ik wat mee kan tijdens mijn volgende sollicitatiegesprekken, ik heb er al weer 4 gepland voor deze en volgende week .

[BCC]

NMe schreef op zondag 1 januari 2017 @ 18:02:
[...]
Het soort bedrijf dat jou op je eerste werkdag aan het werk zet op een nieuw project zonder een goed beeld te hebben van wat je kan is nou net het type bedrijf waar dat soort brakke code geschreven wordt die niemand meer wil onderhouden. Je leidinggevende heeft dan totaal geen idee van wat je nou écht kan maar laat je wel meteen los op een nieuw project, daar krijg je nogal makkelijk slecht onderhoudbare code van. En als je vervolgens na je proeftijd geen vast contract krijgt zitten ze met die code te kijken.`

Soms gaat het wel goed hoor Bijvoorbeeld bij de zogenaamde innovatie factories: kruising tussen een startup en enterprise. Daar zijn er een paar van in Nederland bijvoorbeeld Nedap of TKH Groep of Philips.

Nedap zoekt nog ontwikkelaars trouwens: http://lifeatnedap.com/

[NMe]

gold_dust schreef op maandag 2 januari 2017 @ 14:05:
Bedankt voor de reacties zover. Wat wel duidelijk is geworden is dat verreweg de meeste ontwikkelaars van het type 'software onderhouden en bugs fixen is' en dat bedrijven ook bijna uitsluitend op zoek zijn naar dit type ontwikkelaar. Niet dat daar iets mis mee is, maar ik was me hier eigenlijk niet zo bewust van. Dit inzicht is zeker iets waar ik wat mee kan tijdens mijn volgende sollicitatiegesprekken, ik heb er al weer 4 gepland voor deze en volgende week .

Het is geen "type." Het is deel van elke developmentbaan. Je houdt jezelf voor de gek.

[Hydra]

Ik snap echt niet waarom mensen hier nu zo buitengewoon agressief reageren. Nog nooit van de product lifecycle gehoord kennelijk:



Er is een enorm verschil tussen development in de eerste fase en development in de laatste fase. Sorry maar als je in die laatste 'sterfhuis' fase van een product zit (dat is waar vrijwel alle COBOL developers nu zitten bijvoorbeeld) ben je echt heel ander werk aan het doen. En dat is ook gewoon niet het meest uitdagende werk.

Ik herken mij dan ook zeker in de OP in dat ik het liefst in die initiele fase zit; dat is waar de belangrijke architecturele beslissingen genomen worden. Dat is waar je het meeste "hoe gaan we dit oplossen" werk gaat vinden.

Als je als developer met alle plezier in een product dat in de 3e fase zit werkt; helemaal prima. Maar het is gewoon een stuk minder leerzaam en uitdagend omdat het grootste deel van wat de applicatie kan en hoe het gedaan wordt wel vast staat. Natuurlijk kunnen sommige bugs lastig te vinden zijn en zal je regelmatig nieuwe features moeten bouwen. Maar het is compleet wat anders dan een product from scratch bouwen. En ja, dat soort banen zijn een stuk lastiger om te vinden. De makkelijkste manier is via consulting clubs; bij grote bedrijven worden de initiatie gedaan door gespecialiseerde clubs waarna het 'afmaakwerk' in-house of door een grotere integrator gedaan wordt.

NMe schreef op maandag 2 januari 2017 @ 14:12:
Het is geen "type." Het is deel van elke developmentbaan. Je houdt jezelf voor de gek.

Nou nee. Ik krijg meer het idee dat een hoop mensen hier het vervelend vinden te horen dat ze niet het maximale uit hun ontwikkeling halen. Dat is an sich prima maar als je gaat stellen dat er geen verschil is in product fases, dan hou je jezelf pas echt voor de gek.

[ Voor 13% gewijzigd door Hydra op 02-01-2017 14:15 ]

[CurlyMo]

gold_dust schreef op maandag 2 januari 2017 @ 14:05:
Bedankt voor de reacties zover. Wat wel duidelijk is geworden is dat verreweg de meeste ontwikkelaars van het type 'software onderhouden en bugs fixen is' en dat bedrijven ook bijna uitsluitend op zoek zijn naar dit type ontwikkelaar. Niet dat daar iets mis mee is, maar ik was me hier eigenlijk niet zo bewust van. Dit inzicht is zeker iets waar ik wat mee kan tijdens mijn volgende sollicitatiegesprekken, ik heb er al weer 4 gepland voor deze en volgende week .

Je blijft het maar zwart/wit maken. In de meeste bedrijven begin je als dat type ontwikkelaar, omdat ze nu eenmaal eerst willen weten wie je bent en of je wel geschikt ben om aan grote projecten van scratch af aan deel te nemen of ze te leiden. Op die manier leer je de werkwijze van een bedrijf ook het best kennen. Daarnaast zal het gewoon nooit voorkomen dat je nooit meer bugs fixed of software onderhoudt. Er bestaat dus geen ontwikkelaar van type 1 of type 2 zoals jij ze typeert. Alleen ontwikkelaars met een focus op het één of het ander. Waar je focus ligt is afhankelijk van je kennis, ervaring en de tevredenheid die men met je heeft binnen het bedrijf. Zoals ook in het plaatje hierboven geschetst.

[Hydra]

CurlyMo schreef op maandag 2 januari 2017 @ 14:14:
Je blijft het maar zwart/wit maken. In de meeste bedrijven begin je als dat type ontwikkelaar, omdat ze nu eenmaal eerst willen weten wie je bent en of je wel geschikt ben om aan grote projecten van scratch af aan deel te nemen of ze te leiden. Op die manier leer je de werkwijze van een bedrijf ook het best kennen. Daarnaast zal het gewoon nooit voorkomen dat je nooit meer bugs fixed of software onderhoudt. Er bestaat dus geen ontwikkelaar van type 1 of type 2 zoals jij ze typeert. Alleen ontwikkelaars met een focus op het één of het ander. Waar je focus ligt is afhankelijk van je kennis, ervaring en de tevredenheid men met je heeft binnen het bedrijf. Zoals ook in het plaatje hierboven geschetst.

Dat is dus gewoon niet waar. Accenture bijvoorbeeld heeft hier aparte teams voor; die zijn vaak sterk gespecialiseerd in een bepaald gebied (bijvoorbeeld identity management) en zetten de basisarchitectuur neer waarna als het eenmaal staat de rest van het werk door meer algemeen ervaren developers gedaan wordt.

In de bankenwereld worden bedrijven als Xebia (en dit is ook waar wij vaak in zitten) uitgenodigd voor de initiele architectuur. De nieuwe Wehkamp big data architectuur bijvoorbeeld is ook neergezet door een stel Xebianen waarna de zaak overgenomen wordt door in-house developers.

[NMe]

Hydra schreef op maandag 2 januari 2017 @ 14:13:
Ik snap echt niet waarom mensen hier nu zo buitengewoon agressief reageren. Nog nooit van de product lifecycle gehoord kennelijk:

[afbeelding]

Er is een enorm verschil tussen development in de eerste fase en development in de laatste fase. Sorry maar als je in die laatste 'sterfhuis' fase van een product zit (dat is waar vrijwel alle COBOL developers nu zitten bijvoorbeeld) ben je echt heel ander werk aan het doen. En dat is ook gewoon niet het meest uitdagende werk.

Het punt is helemaal niet dat die fases niet zouden bestaan. Het punt is dat de TS zich te goed voelt om naast het werk in de eerste twee fases ook die andere twee te doen. Daarmee creëert hij alleen werk in die andere twee fases voor alle andere developers die ooit voor dat bedrijf gaan werken.

[jeroen3]

Mensen zoals TS zijn de reden dat mensen zoals TS geen werk naar wens kunnen vinden.
Of is dat te kort door de bocht?

Maar leuke moraalridders zijn jullie, volgens mij er is een verschil tussen de situatie waar jullie het hebben over "met enige regelmaat bugs fixen" en het "hopeloos legacy systeem" waar gold_dust over praat.

Ik ken de situatie prima, ik fix regelmatig andermans code. Echter is er ook software welke ooit in elkaar geflanst door een lang vertrokken collega in een taal welke al >10 jaar antiek is. Om het leuk te maken koppelt dat programmaatje een legacy ERP pakket met inmiddels legacy printer server via een legacy databaseconnector.
Met 0 commentaar, 0 ontwerp en 0 versiebeheer allemaal nog met form1, button1 standaardnamen. Je kunt gewoon niet verwachten dat iemand hierin bugs gaat oplossen zonder omscholing tot archeoloog.
Wat moet je daar nu mee doen, beste moraalridders?

Dit is helaas de real-world situatie, en mede hierdoor is er dus een "tekort aan programmeurs", of een overschot aan "hopeloze legacy systemen". Kies maar.

waarom zit de toon voorbeel knop toch zo dichtbij de verstuur knop

[ Voor 86% gewijzigd door jeroen3 op 02-01-2017 14:24 ]

[Hydra]

NMe schreef op maandag 2 januari 2017 @ 14:17:
Het punt is dat de TS zich te goed voelt

Je stelt je enorm aan naar mijn mening. Hij heeft gewoon een voorkeur voor een bepaald soort werk. Niks mis mee. Ik ook; da's de reden dat ik in de consulting hoek zit.

Ik heb jaren terug een sollicitatie gedaan bij Cap Gemini (meer om te zien wat ik waard was maargoed) en dat was ook een onderhoudstoko. Die deden inderdaad niks anders dan software maintenance. Nieuwbouw werd daar gewoon door een andere club binnen Cap gedaan. Dus je had daar al binnen een redelijk middelmatige integrator een club met developers die het liefst beheer op bestaande software deden. Tja. Dan vind je het maar arrogant dat ik zo iets van "nee laat maar" heb...

[ Voor 42% gewijzigd door Hydra op 02-01-2017 14:23 ]

[Tarkin]

Hydra schreef op maandag 2 januari 2017 @ 14:13:
Ik snap echt niet waarom mensen hier nu zo buitengewoon agressief reageren. Nog nooit van de product lifecycle gehoord kennelijk:

[afbeelding]

Er is een enorm verschil tussen development in de eerste fase en development in de laatste fase. Sorry maar als je in die laatste 'sterfhuis' fase van een product zit (dat is waar vrijwel alle COBOL developers nu zitten bijvoorbeeld) ben je echt heel ander werk aan het doen. En dat is ook gewoon niet het meest uitdagende werk.

Ik herken mij dan ook zeker in de OP in dat ik het liefst in die initiele fase zit; dat is waar de belangrijke architecturele beslissingen genomen worden. Dat is waar je het meeste "hoe gaan we dit oplossen" werk gaat vinden.

Als je als developer met alle plezier in een product dat in de 3e fase zit werkt; helemaal prima. Maar het is gewoon een stuk minder leerzaam en uitdagend omdat het grootste deel van wat de applicatie kan en hoe het gedaan wordt wel vast staat. Natuurlijk kunnen sommige bugs lastig te vinden zijn en zal je regelmatig nieuwe features moeten bouwen. Maar het is compleet wat anders dan een product from scratch bouwen. En ja, dat soort banen zijn een stuk lastiger om te vinden. De makkelijkste manier is via consulting clubs; bij grote bedrijven worden de initiatie gedaan door gespecialiseerde clubs waarna het 'afmaakwerk' in-house of door een grotere integrator gedaan wordt.


[...]


Nou nee. Ik krijg meer het idee dat een hoop mensen hier het vervelend vinden te horen dat ze niet het maximale uit hun ontwikkeling halen. Dat is an sich prima maar als je gaat stellen dat er geen verschil is in product fases, dan hou je jezelf pas echt voor de gek.

Ik heb momenteel beide werelden. Ik ben actief aan het ontwikkelen aan een nieuwe applicatie, daarnaast beheer ik er nog een stuk of 5 (bugfixes, maandelijkse maintenance). Het is daarmee dat het niet zo zwart wit is, Ik hou er ook niet van om veel bugs op te lossen maar dat compenseert wel aangezien ik ook met toffe zaken bezig ben (zoals nieuw ontwikkeling met the latest and greatest...).

Als hij enkel fase1 ontwikkeling wil doen, dat hij dat dan maar zoekt, helaas zit zijn ego in de weg om te beseffen dat hij deel van het probleem is. Dat wij dagelijks code van zulke mannetjes mogen oplossen. Want eenmaal de initiele fase voor bij (bv in productiestelling) dan zijn zulke mensen ook als eerste weer weg. En dan kunnen andere mensen alle shit oplossen.

En elke developer die beweert dat hij geen bugs schrijft, tja dan weet ik ook hoe serieus ik die moet nemen,

Hydra schreef op maandag 2 januari 2017 @ 14:17:
[...]


Dat is dus gewoon niet waar. Accenture bijvoorbeeld heeft hier aparte teams voor; die zijn vaak sterk gespecialiseerd in een bepaald gebied (bijvoorbeeld identity management) en zetten de basisarchitectuur neer waarna als het eenmaal staat de rest van het werk door meer algemeen ervaren developers gedaan wordt.

In de bankenwereld worden bedrijven als Xebia (en dit is ook waar wij vaak in zitten) uitgenodigd voor de initiele architectuur. De nieuwe Wehkamp big data architectuur bijvoorbeeld is ook neergezet door een stel Xebianen waarna de zaak overgenomen wordt door in-house developers.

dus als ik het goed versta zitten de meer ervaren developers in-house? Ik lees tussen de lijnen door dat er gewoon een halve assemblage lijn is opgezet bij accenture waar dan bepaalde mensen veel hetzelfde doen (architectuur opzetten) en van zodra het geraamte opstaat gaan ze toch voor interne developers? Wat is dan de meerwaarde van in zo'n team te zitten? Dat je 1 bepaald soort architectuur per jaar kan opzetten maar je developt niets?

[ Voor 17% gewijzigd door Tarkin op 02-01-2017 14:27 ]

[NMe]

Hydra schreef op maandag 2 januari 2017 @ 14:19:
[...]

Ik heb jaren terug een sollicitatie gedaan bij Cap Gemini (meer om te zien wat ik waard was maargoed) en dat was ook een onderhoudstoko.

Er is niks mis met niet bij bedrijven willen werken die alleen aan onderhoud doen. Maar dat is niet wat de TS zegt. Hij wil onder geen beding onderhoud plegen aan bestaande software. Dat bestaat gewoon niet, in geen enkele baan.

[Hydra]

Tarkin schreef op maandag 2 januari 2017 @ 14:23:
En elke developer die beweert dat hij geen bugs schrijft, tja dan weet ik ook hoe serieus ik die moet nemen,

Het zou fijn zijn als mensen stromannen achterwege zouden laten. De TS beweert nergens dat hij geen bugs produceert; dat doet iedere dev. Waar hij het over hebt is devs / teams die technical debt produceren. En dat is compleet iets anders en daarnaast een software killer.

Serieus iedereen; kom op. Op iedere conferentie zijn dit soort zaken gewoon enorm populaire onderwerpen. Hoe ontwikkel je software die ook op de lange termijn werkbaar blijft. Als je als bedrijf hier gewoon met de pet naar gooit en alleen maar developers aanneemt en houdt die zo snel mogelijk 'features' bouwen zonder daarbij te testen en te refactoren ben je slecht bezig. Het is niet meer dan normaal dat een bepaalde categorie developers die dit soort shit serieus neemt dan niet voor je wil werken.

[gold_dust]

@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

[Tarkin]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

Wat je dan zoekt is werken in een agile omgeving met een "you build it, you maintain it" manier.

Als je het in die richting verwoord, ga je misschien wat meer kans hebben om het kaf van het koren te scheiden op je sollicitatie.

Puur uit interesse, over hoeveel ervaring langs jouw kant spreken we? Medior/senior/iets anders?

[Hydra]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen.

Don't worry. Dit is een normale fase waar veel developers doorheen gaan als ze hun vak erg (/ te ) serieus gaan nemen. Ik zit zelf ook altijd 't liefst in de eerste fase, dan kun je het nog goed op zetten. De meeste van m'n consultant collega's zitten er een beetje hetzelfde in; als je het goed opzet (goeie test coverage, test automation, continuous integration / deployment) heb je daar de rest van je lifecycle profijt van. Als dat niet gebeurd is en het een een grote teringzooi dan ben je 2 weken bezig met een feature die je een dag zou moeten kosten gewoon omdat iedere keer alles omdondert.

Het fijne aan projecten met een hoge mate van maturity is dat je nooit terug hoeft te komen in de avonden / weekenden. Shit werkt gewoon. Software gaat echt niet 'zomaar' opeens in de avond stuk. Dan was het al stuk en was je d'r gewoon nog niet achter gekomen. Voor dat soort software pas ik ook; dan laat ik met alle plezier de mensen die de rotzooi gemaakt hebben die ook opruimen.

[NMe]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

En hoe bepaal je op je solliciatiegesprek zonder inzage gehad te hebben in het bestaande systeem of het goed geschreven code is?

[Hydra]

Tarkin schreef op maandag 2 januari 2017 @ 14:23:
dus als ik het goed versta zitten de meer ervaren developers in-house?

Nee, ik beschreef het onduidelijk (sorry): wat ik bedoel is developers met ervaring die meer in de breedte zit dan in de diepte. Dus minder gespecialiseerd en vaak ook minder ervaren.

Ik lees tussen de lijnen door dat er gewoon een halve assemblage lijn is opgezet bij accenture waar dan bepaalde mensen veel hetzelfde doen (architectuur opzetten) en van zodra het geraamte opstaat gaan ze toch voor interne developers? Wat is dan de meerwaarde van in zo'n team te zitten? Dat je 1 bepaald soort architectuur per jaar kan opzetten maar je developt niets?

Nee. Wat je meestal ziet is dat een X aantal externe developers aangenomen worden om de eerste 6-12 maanden ofzo het begin neer te zetten. Incluus alle laatste best practices e.d. (project waar ik nu op zit is een microservice architectuur met Java, Spring Boot, Docker, Kubernetes, extreem hipster ). Na verloop van tijd worden externen langzamerhand vervangen door internen waarbij een tijd in parallel gewerkt wordt zodat deze best practices overgedragen worden.

Er wordt vaak erg lacherig gedaan over "consultants" en als je alleen maar met mensen van Cap of Logica gewerkt hebt snap ik dat ook wel. Maar over het algemeen zijn dit soort mensen juist door een uitgebreide ervaring (de meeste van mijn collega's zitten ook meer dan 10 jaar in 't vak) wel erg goed in wat ze doen. En kunnen de in-house developers hier veel van leren.

NMe schreef op maandag 2 januari 2017 @ 14:38:
En hoe bepaal je op je solliciatiegesprek zonder inzage gehad te hebben in het bestaande systeem of het goed geschreven code is?

Gewoon vragen om eens mee te kunnen kijken (eventueel indien nodig na tekenen van een NDA). Waarom zou een bedrijf jou de hemd van 't lijf mogen vragen maar niet hun eigen shit op tafel moeten leggen?

[ Voor 12% gewijzigd door Hydra op 02-01-2017 14:42 ]

[CodeCaster]

Hydra schreef op maandag 2 januari 2017 @ 14:27:
Hoe ontwikkel je software die ook op de lange termijn werkbaar blijft. Als je als bedrijf hier gewoon met de pet naar gooit en alleen maar developers aanneemt en houdt die zo snel mogelijk 'features' bouwen zonder daarbij te testen en te refactoren ben je slecht bezig. Het is niet meer dan normaal dat een bepaalde categorie developers die dit soort shit serieus neemt dan niet voor je wil werken.

Volgens mij stelt niemand hier dat ter twijfel.

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt

Dat heb ik je al in een paar posts proberen uit te leggen: omdat je begrippen misbruikt om jouw ongenoegen kenbaar te maken. Mensen die onderhoud plegen op bestaande software zijn wél ontwikkelaars. Code die perfect is opgezet maar niet gedocumenteerd is géén legacy. Mensen die bugs fixen zijn niet per definitie ondergeschikt aan mensen die nieuwe systemen ontwerpen.

Begrijp me niet verkeerd, ik kan me verder helemaal vinden in je verhaal. Volgens mij vindt niemand het leuk om ongeteste, ontestbare, veel te lange lappen code te onderhouden die van toevalligheden aan elkaar hangen en waar iedere collega al jaren met een grote boog omheen loopt. Volgens mij solliciteert niemand bewust op een rol waarin ze op een doodlopende techniek met een slecht opgezet stuk software moeten gaan werken. Dat is namelijk niet goed voor je persoonlijke ontwikkeling, voor je stressniveau, voor de eer van je werk en voor je toekomstkansen.

Het enige dat ik, en enkele anderen met mij hier, proberen te vertellen is dat je moet stoppen met zo schamper te doen over onderhoud. Het hóórt bij het vak, en imperfecties in het proces en product zijn een gegeven. Zo niet, dan mag je je in je handen wrijven dat je een fijne werk- of opdrachtgever hebt gevonden, maar in mijn ervaring (nu zeven jaar fulltime werkzaam bij uiteenlopende werk- en opdrachtgevers) zijn die uitzonderlijk zeldzaam.

Dus als je vraag nu is hoe je zo'n baas vindt: dat is een goede vraag, en de nuttige tips dáárover druppelen nu in de laatste paar reacties het topic binnen. De rest is ruis.

[ Voor 15% gewijzigd door CodeCaster op 02-01-2017 15:00 ]

[Tarkin]

Bij ons is het helaas de andere kant van de medaille.

Het huidig project waar ik nu zit kan met alle moeite van de wereld geen inhouse developers vinden (België en toch een niet al te kleine partij in de sociale zekerheid). Dus wat doen ze, ze huren vrolijk externe mensen in.

Er heerst ook nog steeds een hoog cowboy gehalte bij ons, iedereen die binnenkomt wilt natuurlijk vooral nieuw development doen en heeft duidelijke ideeën wat hij wil en waar hij naartoe wil. Met als gevolg dat we een gigantische verscheideneid aan stacks hebben. Noem alle hypes van de laatste 15 jaar in java gebied en we hebben wel een applicatie die we ondersteunen. Heel veel van de mensen blijven ook maximum 2 jaar, daarna zijn ze weg met als gevolg dat er een gigantische legacy hell is.

Er komen weer nieuwe developers bij en die zien dan wat een troep het allemaal is, ze zagen en klagen er over en ze krijgen een nieuw projectje (want ze willen de externen ook een beetje te vriend houden zodat ze er toch op z'n minst een jaartje zitten) en die gaan dan ook hun eigen inzichten erin steken. Iedereen weet dat we het aantal technologien moeten verminderen en toch blijven we jaar na jaar vrolijk hetzelfde doen.

90% van deze issues komt door mensen zoals TS hier. Ze hebben van zichzelf een heel hoge dunk, hebben geen zin om een teamplayer te zijn (want mijn idee is het enige goede idee, afspraken die de code quality bevorderen gebeuren niet want dan moeten ze misschien iets doen waar ze principieel tegen zijn). Na 2 jaar zijn ze weg wegens niet interessant genoeg meer en kan de rest van het bedrijf de shit opkuisen.

Om dan nog eens hier op een techforum te komen doen alsof 95% van de developers 2erangs developers zijn, tjah dan ga je hier en daar wel een tegenwoord krijgen. Maar hoge bomen vangen nu eenamal veel wind. Daarom dat ik benieuwd ben naar zijn ervaring en zijn verwezelijkingen. Misschien is het wel de nieuwe Martin Fowler of Kent Beck, who nows?


edit: even ter verduidelijking ik ben ook een externe hier

[Hydra]

CodeCaster schreef op maandag 2 januari 2017 @ 14:53:
Dat heb ik je al in een paar posts proberen uit te leggen: omdat je begrippen misbruikt om jouw ongenoegen kenbaar te maken.

Mensen zouden ook eens kunnen proberen uit te vogelen wat een ander bedoelt in plaats van maar lekker Hollands meteen in de verdediging te schieten. Ik ben het er best mee eens dat de TS het niet goed verwoord heeft maar het was ook overduidelijk gewoon niet goed verwoord. Als je (niet jij persee maar mensen hier in het algemeen) dan meteen boos gaat lopen wezen dan heeft dat het effect dat je ook niet meer probeert te zien wat iemand nu echt bedoelt.

Komt nog eens bij dat "software in maintenance mode" gewoon een compleet bekende algemene term is. Dus het is de normaalste zaak van liever niet willen werken aan software in maintenance mode. Dat mensen dit hier dan opvatten als geen bugs willen fixen (of nog erger, je eigen bugs niet willen fixen) licht echt compleet aan de mensen die kennelijk om een of andere reden die terminologie niet kennen. Dat is dus wat anders dan geen "maintenance" willen doen.

[ Voor 24% gewijzigd door Hydra op 02-01-2017 15:04 ]

[Tarkin]

Hydra schreef op maandag 2 januari 2017 @ 15:01:
[...]


Mensen zouden ook eens kunnen proberen uit te vogelen wat een ander bedoelt in plaats van maar lekker Hollands meteen in de verdediging te schieten. Ik ben het er best mee eens dat de TS het niet goed verwoord heeft maar het was ook overduidelijk gewoon niet goed verwoord. Als je (niet jij persee maar mensen hier in het algemeen) dan meteen boos gaat lopen wezen dan heeft dat het effect dat je ook niet meer probeert te zien wat iemand nu echt bedoelt.

Geef toe dat hij dan toch echt beter zijn best kan doen, als je zegt dat het grootste deel van de developers tweederangs zijn, dan krijg je inderdaad dat soort reacties

Ik zie in ieder geval een verschil tussen een ontwikkelaar die nieuwe dingen ontwikkelt en iemand die alleen maar onderhoud en bug-fixing doet en dan vaak ook nog in de puinhoop die door iemand anders is achtergelaten. Uit de reacties hier peil ik dat veel 'ontwikkelaars' van het tweede type zijn en bedrijven ook naar dit type 'ontwikkelaar' op zoek zijn. Daar was ik me tot nu eigenlijk niet bewust van en het is gewoon niet wat ik zoek.

[Tsurany]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

Waarom daar zo op gereageerd wordt is omdat jij developers die niet aan deze fasen werken weg zet als mensen die mindere ontwikkelaars zijn, minder capaciteiten hebben en tevreden zijn met "simpel werk". Dat is een groot bord voor je kop hebben.


Ik vind de eerste fase van projecten ook veel leuker. Met een geheel nieuw team vanaf scratch beginnen en kijken welke uitdagingen je tegen komt, hoe je dat gaat oplossen en hoe je een architectuur gaat neerzetten die meerdere jaren mee kan. Dat is persoonlijke voorkeur, dat kan prima. Dat betekent echter niet dat ik developers die in een andere rol zitten weg ga zetten als mindere developers. In welke fase van een product je zit zegt namelijk helemaal niks over je kwaliteiten als developer.

Ik heb genoeg goede developers gezien die een mainframe systeem keurig overeind kunnen houden en kunnen debuggen en uitbreiden wanneer nodig inclusief testen en documentatie. En ik heb genoeg developers gezien die met nieuwe technieken een project opstarten, nieuwe applicatie neerzetten en een ongedocumenteerde puinhoop achterhalen waar niets mee aan te vliegen is.

[Hydra]

Tarkin schreef op maandag 2 januari 2017 @ 15:11:
Geef toe dat hij dan toch echt beter zijn best kan doen, als je zegt dat het grootste deel van de developers tweederangs zijn, dan krijg je inderdaad dat soort reacties

Het tweederangs deel is jouw interpretatie. Een test automation engineer doet ook compleet wat anders. Maakt hem dat tweederangs? Nee. Daarbij snap ik best dat hij na al die aanvallen hier wat gepikeerd reageert; men gooit continue met stromannen om hun eigen boze reacties te kunnen plaatsen. Voorbeeld:

Ik kan niet overal op reageren maar dit is een goede. Ik zal voortaan tijdens een sollicitatiegesprek direct vragen of het gaat om voornamelijk bux-fixen en onderhoud of nieuwe ontwikkeling, waarbij het ene het andere natuurlijk niet helemaal uitsluit.

Over het "voornamelijk" wordt voor het gemak maar even heengelezen. De TS zegt niet dat hij niet wil bugfixen. Als mensen gewoon eens goed lezen wat de TS daadwerkelijk zegt en plaats van het in hun eigen hoofd te laten escaleren naar "als je bugs fixt ben je geen developer".

Er is, nogmaals, een enorm verschil tussen software in maintenance mode (of erger; in sterfhuis mode) en software in de initiele fase. En zo is er ook een groot verschil in developers die een voorkeur voor de eerste of de laatste hebben. Die reacties hier tonen volgens mij aan dat de meeste mensen uberhaupt nog nooit van product life cycle gehoord hebben.

Tsurany schreef op maandag 2 januari 2017 @ 15:13:
Waarom daar zo op gereageerd wordt is omdat jij developers die niet aan deze fasen werken weg zet als mensen die mindere ontwikkelaars zijn, minder capaciteiten hebben en tevreden zijn met "simpel werk". Dat is een groot bord voor je kop hebben.

Komop zeg. Niet inzien dat er een enorm verschil is in een architectuur neerzetten en een beetje de laatste issues in een pakket dat volgens jaar vervangen gaat worden; dat is pas een bord voor je kop hebben.

En sorry maar als je als developer continue werkt aan een systeem dat met duct-tape aan elkaar hangt en bij iedere release er aan alle kanten dingen stuk gaan, waarom blijf je dan doorsukkelen? Als developers neem je of je werk serieus of niet. Als je je werk wel serieus neemt ga je volgens mij de situatie verbeteren; dus door je team een kant op te krijgen of (als het eerste niet lukt) het ergens anders te zoeken. Is het nu zo moeilijk gewoon eens de OP nog eens goed te lezen in plaats van te gaan hakke-takken over terminologie?

[ Voor 26% gewijzigd door Hydra op 02-01-2017 15:25 ]

[Soundless]

Even de topic geskimt:

Is het voor OP niet een idee om dan te solliciteren bij bedrijven die klantspecifieke producten maakt en niet bij bedrijven die 1 groot product hebben waarop voortborduurt wordt.

Je komt dan waarschijnlijk in de web of mobile wereld terecht. Of je moet je detacheren, daar is dat volgens mij ook zo dat je vooral nieuwe dingen maakt (geen ervaring mee).

Voor de rest ben ik het wel met de meesten hier eens dat het een totaalpakket is. Ook bij bedrijven waar nieuwe producten worden gemaakt, moet nog onderhoudt gepleegd worden aan oudere producten. En daar ga je geheid ook aan werken.

Succes iig met je zoektocht

[Cloud]

Hydra schreef op maandag 2 januari 2017 @ 15:21:
Komop zeg. Niet inzien dat er een enorm verschil is in een architectuur neerzetten en een beetje de laatste issues in een pakket dat volgens jaar vervangen gaat worden; dat is pas een bord voor je kop hebben.

Dat verschil zien we allemaal wel toch? Het probleem was dat de TS de scheiding legde tussen 'architectuur neerzetten' is ontwikkelen en al het andere is 'beheer'. Zelfs toen er voor de duidelijkheid nóg eens naar gevraagd werd. Dat schoot vermoedelijk veel mensen in het verkeerde keelgat

En zo is er ook een groot verschil in developers die een voorkeur voor de eerste of de laatste hebben.

Volgens mij is er geen ontwikkelaar die de voorkeur geeft aan sterfhuis software, toch? Of ontwikkelaar die het liefst onderhoud pleegt op een product dat nu actief is. De meeste ontwikkelaars zullen het liefst aan nieuwe dingen werken maar het meeste developmentwerk (uitzonderingen daargelaten) is dat simpelweg niet. Of je krijgt situaties zoals Tarkin beschrijft en dat wil je óók niet. Althans als bedrijf moet je dat niet willen.

Die reacties hier tonen volgens mij aan dat de meeste mensen uberhaupt nog nooit van product life cycle gehoord hebben.

Dat is wel heel kort door de bocht en niet de reden dat het topic de kant op ging die het ging.

Soundless schreef op maandag 2 januari 2017 @ 15:30:
Je komt dan waarschijnlijk in de web of mobile wereld terecht. Of je moet je detacheren, daar is dat volgens mij ook zo dat je vooral nieuwe dingen maakt (geen ervaring mee).
[...]

Detachering vraag ik me af of dat wel zo vaak zo is. Mijn ervaring (via een kennis die in die wereld zit) is dat detacheerders er vaak pas bij gehaald worden als het mis dreigt te gaan, dus als projecten niet gaan zoals ze moeten gaan. Dan is die mooie 'schone lei'-fase al lang voorbij. Maar goed, er zijn ongetwijfeld ook detacheerders die niet in die fase werken maar daar moet je dan wel op letten

[scrappy.doo]

Soundless schreef op maandag 2 januari 2017 @ 15:30:
Of je moet je detacheren, daar is dat volgens mij ook zo dat je vooral nieuwe dingen maakt (geen ervaring mee).

Paar jaartjes detachering gedaan en dat is over het algemeen hartstikke leuk, omdat je zo in een relatief korte tijd veel verschillende aspecten van het vak en verschillende bedrijven kan ervaren. Het heeft mij zeker geholpen om te ontdekken wat ik nu echt leuk vind.

Het is echter zeker geen garantie dat je als detacheerder vooral nieuwe dingen maakt. Voor mij persoonlijk was het 50/50 nieuwe projecten vs legacy (waaronder ook echt 3/4 jaar niks anders dan bugs fixen wat gewoon niet leuk is en demotiverend werkt, voor mij in ieder geval)

[Hydra]

Soundless schreef op maandag 2 januari 2017 @ 15:30:
Is het voor OP niet een idee om dan te solliciteren bij bedrijven die klantspecifieke producten maakt en niet bij bedrijven die 1 groot product hebben waarop voortborduurt wordt.

Het probleem is juist dat er in die "web agency" wereld veel prutsers actief zijn. Daar wordt ook veel meer op kosten gezeten dan bij de clubs waar je aan grote complexe software werkt.

scrappy.doo schreef op maandag 2 januari 2017 @ 16:15:
Het is echter zeker geen garantie dat je als detacheerder vooral nieuwe dingen maakt. Voor mij persoonlijk was het 50/50 nieuwe projecten vs legacy (waaronder ook echt 3/4 jaar niks anders dan bugs fixen wat gewoon niet leuk is en demotiverend werkt, voor mij in ieder geval)

Het is een beetje afhankelijk van waar je werkt. De kleinere gespecialiseerde clubs hebben over 't algemeen meer werk dan mensen en doen er alles aan om hun mensen niet weg te jagen. Dus daar heb je over het algemeen een stuk meer inbreng wat betreft welke klus je krijgt dan bij de grote handelaren in warm vlees.

[ Voor 25% gewijzigd door Hydra op 02-01-2017 17:13 ]

[CurlyMo]

Hydra schreef op maandag 2 januari 2017 @ 14:17:
[...]


Dat is dus gewoon niet waar. [...] die zijn vaak sterk gespecialiseerd in een bepaald gebied [...]

Hierop terugkomende, je hebt helemaal gelijk, maar dat zijn zoals je zegt gespecialiseerde clubs. Mijn punt gaat nu juist over een reactie een stukje later:

Hydra schreef op maandag 2 januari 2017 @ 15:21:
En sorry maar als je als developer continue werkt aan een systeem dat met duct-tape aan elkaar hangt en bij iedere release er aan alle kanten dingen stuk gaan, waarom blijf je dan doorsukkelen? Als developers neem je of je werk serieus of niet. Als je je werk wel serieus neemt ga je volgens mij de situatie verbeteren; dus door je team een kant op te krijgen of (als het eerste niet lukt) het ergens anders te zoeken. Is het nu zo moeilijk gewoon eens de OP nog eens goed te lezen in plaats van te gaan hakke-takken over terminologie?

Punt is nu juist dat TS afhaakt wanneer code 'legacy' blijkt te zijn, terwijl je je kwaliteit ook kan inzetten om verbeteringen aan te brengen in de code of het werkproces. Ik vind dat zelf kort door de bocht.

Ik zie in mijn eigen organisaties het juist daar mis gaan. ICT'ers worden binnen gebracht als zendelingen: "Wij gaan met slimme ICT oplossingen je probleem oplossen" en het antwoord is dan "Ik wist niet dat ik een probleem had". Oftewel, vaak een onbewuste onbekwaamheid. In mijn organisatie is er juist veel behoefte aan het type ICT'er die de verbinding kan leggen met de medewerker die ook de legacy code schreef én er nog wel werkt. Hem of haar proberen mee te nemen in een nieuw werkproces.

Het staat TS vrij om daar af te haken, maar dan mis je ook mooie kansen.

[mekkieboek]

Hydra schreef op maandag 2 januari 2017 @ 14:13:
Ik snap echt niet waarom mensen hier nu zo buitengewoon agressief reageren. Nog nooit van de product lifecycle gehoord kennelijk:

Voor agile / iteratief ontwikkelen, wat je steeds vaker ziet, is dit model niet meer correct of zelfs achterhaald. Je itereert in feite doorlopend door fase 2, 3 en 4. Dat betekent dat je als architect, ontwikkelaar en tester voorturend in een mix zit van ontwerp / ontwikkeling, bugfixing, refactoring, code af laten sterven.

Het is trouwens interessant om te zien of agile / iteratief ontwikkelen op termijn gaat leiden tot minder spaghetti code. Dit omdat je minder in een kortlopend project een grote bak met code ontwikkelt (binnen budget en na jou de zondvloed). Maar meer over langere tijd features toevoegt en toe moet kunnen blijven voegen. En door die langere tijdspanne dus ook de voordelen gaat merken van (bijvoorbeeld) onderhoudbare code. Voeg daaraan toe pair programming waarbij devvers zich aan elkaar kunnen optrekken naast het voorkomen van (ontwerp)fouten.

[onetime]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

Tot en met het onderstreepte zullen de meeste mensen geen probleem met je mening hebben.

De haren gaan overeind staan bij het vette deel, met namen het door jou zelf al gecursifeerde deel.
Over het algemeen zijn er coderingsstandaarden. Als het daar niet aan voldoet, zou het niet geaccepteerd behoren te zijn. Alles wat geaccepteerd is is dus per definitie voldoende netjes. En daar twijfel jij aan...?

[RagingPenguin]

onetime schreef op maandag 2 januari 2017 @ 22:02:
[...]

Tot en met het onderstreepte zullen de meeste mensen geen probleem met je mening hebben.

De haren gaan overeind staan bij het vette deel, met namen het door jou zelf al gecursifeerde deel.
Over het algemeen zijn er coderingsstandaarden. Als het daar niet aan voldoet, zou het niet geaccepteerd behoren te zijn. Alles wat geaccepteerd is is dus per definitie voldoende netjes. En daar twijfel jij aan...?

"Voldoende netjes" is natuurlijk een erg rekbaar begrip. En ik denk dat als je er van uit gaat dat ieder bedrijf strikt omgaat met codestandaarden dan ben ik bang dat je iets te optimistisch bent.

[CMD-Snake]

Als ik zo de reacties van de TS lees lijkt het van een enorme ego te getuigen. Alleen maar leuke dingen doen en geen zin hebben in onderhoud van bestaande zaken. Als je een toetje wil zal je ook eerst je groente moeten opeten.

Geen idee of TS net uit de schoolbanken is met die houding, maar let erop als je solliciteert. Als het hier er vanaf druipt, dan merkt elke interviewer dat ook. Met zo'n houding kan je heel eenvoudig een sollicitatie verpesten. Die enorme hautain over andermans code kan heel snel in het verkeerde keelgat schieten.

[Harm_H]

OP, je hebt helemaal gelijk. Je moet zeker streven naar transparante, version-controlled, otap apllicaties!

Het meest irritante is als er niet objectief wordt besproken. 'Senioriteit' an sich is geen argument (te lui om uit te leggen waarom x zo gaat, of bang om vervangen te worden).

Hoe vind je gedegen code omgeving?
- Niet, want ben je dan nodig?
- Start-up
- Game developer
- Website bouwer (mits nieuw)
- Apps (veelal nieuwe technologie)

Ps. Als je ook echt goed bent moet je simpelweg bij een premium detacheerder gaan werken, xebia, werd al genoemd, die zijn te duur voor bug fixing en onderhoud.

[ Voor 16% gewijzigd door Harm_H op 03-01-2017 03:11 ]

[BarôZZa]

CMD-Snake schreef op maandag 2 januari 2017 @ 23:24:
Als ik zo de reacties van de TS lees lijkt het van een enorme ego te getuigen. Alleen maar leuke dingen doen en geen zin hebben in onderhoud van bestaande zaken. Als je een toetje wil zal je ook eerst je groente moeten opeten.

Geen idee of TS net uit de schoolbanken is met die houding, maar let erop als je solliciteert. Als het hier er vanaf druipt, dan merkt elke interviewer dat ook. Met zo'n houding kan je heel eenvoudig een sollicitatie verpesten. Die enorme hautain over andermans code kan heel snel in het verkeerde keelgat schieten.

Wat een ramp. Als je een beetje kan programmeren dan is een sollicitatiegesprek vooral om te kijken of het bedrijf iets voor jou is. Niks mis met beleefde eerlijkheid.

Als je gevoel al slecht is, dan moet je er nooit aan de slag gaan. Als het werkelijk zo slecht is dan is de kans groot dat:

1.Het enorm slecht voor je ontwikkeling is. Je leert niks van baggercode doorspitten en waarschijnlijk is er weinig kennis in huis om van te leren. Er is ook een risico dat je jezelf verkeerde gewoontes gaat aanleren.
2. Dat je in de toekomst niks hebt aan de kennis van die legacy libraries en dat je een achterstand hebt opgelopen omdat je beter iets anders had kunnen leren.
3. Dat de bedrijfsvoering chaotisch zijn en de werksfeer niet zo geweldig is. Klinkt als zo'n bedrijf waarbij alles gisteren al klaar had moeten zijn, waarbij elk dubbeltje omgedraaid moet worden en er druk uitvoeren om iets maar snel erin te hacken in plaats van dat je de tijd krijgt om een goede oplossing uit te denken.

Snap het gezeur richting de TS niet echt.Ik heb zat developers meegemaakt die liever geen echt nieuwe dingen maakten of grote beslissingen namen, maar zich comfortabeler voelden bij het fixen van bugs en dergelijke. Die liever concreet afgebakende problemen oplosten en weinig met abstractie hadden.

Andere developers leggen de lat wat hoger. Dat heeft weinig met een houding te maken. Het is dood normaal om ambities te hebben en een baan op het juiste niveau te willen.

Dat is overigens wel zuur aan de cultuur hier in Nederland. Heb zelf liever iemand als TS in m'n team die duidelijke doelen stelt, zich uit durft te spreken en kwaliteit belangrijk vindt. Helaas hebben mensen liever dat niemand boven het maaiveld uitsteekt. Vooral niks uitspreken, maar je aanpassen aan de meute. Baggerwerk wordt goed gepraat omdat het zo'n harde werker is, terwijl iemand die kwaliteit nastreeft de arrogante betweter is.

Tarkin schreef op maandag 2 januari 2017 @ 14:53:
Iedereen weet dat we het aantal technologien moeten verminderen en toch blijven we jaar na jaar vrolijk hetzelfde doen.

90% van deze issues komt door mensen zoals TS hier. Ze hebben van zichzelf een heel hoge dunk, hebben geen zin om een teamplayer te zijn (want mijn idee is het enige goede idee, afspraken die de code quality bevorderen gebeuren niet want dan moeten ze misschien iets doen waar ze principieel tegen zijn). Na 2 jaar zijn ze weg wegens niet interessant genoeg meer en kan de rest van het bedrijf de shit opkuisen.

Je maakt jaar op jaar dezelfde fouten, maar het is de schuld van de nieuwe developers die blijkbaar alle vrijheid krijgen omdat er geen structuur of visie is .

Als het fijn werken is en ze er genoeg kansen zijn om je door te ontwikkelen, dan zullen ze wel langer blijven. Dat teamplayergelul is helemaal vermoeiend als het over development gaat. Ik heb liever een groep getalenteerde mensen die kritisch naar elkaars werk kijken dan dat je een hecht teampje van middelmaat dat het altijd met elkaar eens is. Sowieso de term 'team' bij development. Standaard op het sollicitatiegesprek. Hecht en gezellig team. Alleen zit iedereen altijd doodstil achter z'n eigen bureau aan z'n eigen zaken te werken. Wat een onzin.

[ Voor 48% gewijzigd door BarôZZa op 03-01-2017 07:13 ]

[Hydra]

mekkieboek schreef op maandag 2 januari 2017 @ 21:14:
Voor agile / iteratief ontwikkelen, wat je steeds vaker ziet, is dit model niet meer correct of zelfs achterhaald.

Absoluut niet. Je verwart de product lifecycle met het waterval model. Producten hebben over het algemeen een bepaalde levensduur. Hoe je dat product ontwikkelt heeft daar helemaal niks mee te maken.

CMD-Snake schreef op maandag 2 januari 2017 @ 23:24:
Als ik zo de reacties van de TS lees lijkt het van een enorme ego te getuigen.

Ik zie hier vooral een flink aantal mensen zich om een of andere reden bijzonder aangesproken voelen en dat dan vooral maar persoonlijk gaan maken naar de TS toe. Er is niks mis met een voorkeur hebben voor nieuwbouw (er zijn niet voor niets teams en bedrijven die zich daarin specialiseren) en er is niets mis met klaar zijn met pruts bedrijven waar pruts developers vooral technical debt creeeren.

Als je bij een dergelijk bedrijf werkt en je de TS mateloos arrogant vindt moet je toch echt eens bij jezelf gaan kijken of je niet al een paar jaartjes compleet stil staat in je ontwikkeling; zoals een hele grote groep developers in Nederland compleet stil staat.

BarôZZa schreef op dinsdag 3 januari 2017 @ 07:01:
Dat is overigens wel zuur aan de cultuur hier in Nederland.

Absoluut. En dat is wel iets dat enorm Nederlands is. Vooral overal op lopen zeiken maar ondertussen zelf een enorme zesjesmentaliteit hebben. Kijk ook maar in dat Logica/CMG/Whatever-tegenwoordig topic waar mensen jarenlang lopen te emmeren over hoe slecht het is als werkgever maar er wel gewoon blijven werken.

[ Voor 15% gewijzigd door Hydra op 03-01-2017 08:06 ]

[Tarkin]

BarôZZa schreef op dinsdag 3 januari 2017 @ 07:01:
[...]


[...]

Je maakt jaar op jaar dezelfde fouten, maar het is de schuld van de nieuwe developers die blijkbaar alle vrijheid krijgen omdat er geen structuur of visie is .

Als het fijn werken is en ze er genoeg kansen zijn om je door te ontwikkelen, dan zullen ze wel langer blijven. Dat teamplayergelul is helemaal vermoeiend als het over development gaat. Ik heb liever een groep getalenteerde mensen die kritisch naar elkaars werk kijken dan dat je een hecht teampje van middelmaat dat het altijd met elkaar eens is. Sowieso de term 'team' bij development. Standaard op het sollicitatiegesprek. Hecht en gezellig team. Alleen zit iedereen altijd doodstil achter z'n eigen bureau aan z'n eigen zaken te werken. Wat een onzin.

Nope dat is de fout van de seniors in het team. Die denken van al het oude is troep en daar kijken we niet meer naar om, maar dat laatste nieuwe hier, dat gaan we gebruiken.

Als je een deftige product lifecycle hebt, dan kan je nog met de latest and greatest werken, maar dan heb je misschien 2 stacks die je moet onderhouden en geen 35 zoals we nu doen. Die enorme kortzichtigheid is waarom we nu op deze puinhoop werken. Ik kan nu inderdaad zeggen van meh, bekijk het maar, maar ik doe dat niet. Ik probeer het van binnenuit te veranderen, bepaalde oude technologieen laten afvloeien, kijken wat we kunnen uitschakelen (sommige applicaties draaien al 5 jaar zonder dat iemand ze ooit nog gebruikt bv).

Qua teamplayergevoel. In de teams waar dat echt heerste (je weet wel, een Agile extreme programming omgeving met veel pair programming) ging het echt goed vooruit, iedereen kon werken aan code dat iemand anders geschreven heeft, weinig problemen, weinig haantjes gedrag ook. Nu waar ik nu zit kan ik geen 2 applicaties opendoen en de coding stijl is nooit hetzelfde, zelfs de manier warop de projecten zijn opgezet.
Dus we hebben nu jouw visie, 10+ developers die op hun eigen eilandje zitten te coden en die van hunzelf vinden dat ze de beste zijn. Dat kan misschien waar zjin maar dat is nooit het beste voor het bedrijf. Waar jij middelmatigheid verfoeid is dat iets wat er meer moet komen juist. Ipv altijd opnieuw het wiel uit te vinden (ik heb gevallen van code waar ze keer op keer zelf iets uitgevonden hebben dat perfect al in 1 of ander framework zat, dat we dan ook gebruikten!). Het hele coderen is helemaal nog niet matuur.


Wat iemand anders hierboven ook zei, als je agile werkt zit je eigenlijk constant alles te doen. En dat is net een van de sterktes hiervan. Geen lesson's learned op het einde van een waterfall project om er dan daarna nooit meer iets te doen, nee elke 2 weken (of einde van de sprint) een retro om te zien waar we goed zijn geweest en waar we de mist zijn ingegaan. Dat heeft veel meer mijn voorkeur.

[Hydra]

Tarkin schreef op dinsdag 3 januari 2017 @ 08:33:
Nope dat is de fout van de seniors in het team.

Meer een management issue m.i. Als het goed is heb je een architectuur lead / CTO die dit soort overkoepelende zaken bepaalt.

[mekkieboek]

Hydra schreef op dinsdag 3 januari 2017 @ 08:03:
Producten hebben over het algemeen een bepaalde levensduur. Hoe je dat product ontwikkelt heeft daar helemaal niks mee te maken.

Afgezien daarvan, hier laat ik het bij, dit topic is mij te gepolariseerd.

[BarôZZa]

Tarkin schreef op dinsdag 3 januari 2017 @ 08:33:
[...]

Qua teamplayergevoel. In de teams waar dat echt heerste (je weet wel, een Agile extreme programming omgeving met veel pair programming) ging het echt goed vooruit, iedereen kon werken aan code dat iemand anders geschreven heeft, weinig problemen, weinig haantjes gedrag ook. Nu waar ik nu zit kan ik geen 2 applicaties opendoen en de coding stijl is nooit hetzelfde, zelfs de manier warop de projecten zijn opgezet.
Dus we hebben nu jouw visie, 10+ developers die op hun eigen eilandje zitten te coden en die van hunzelf vinden dat ze de beste zijn. Dat kan misschien waar zjin maar dat is nooit het beste voor het bedrijf. Waar jij middelmatigheid verfoeid is dat iets wat er meer moet komen juist. Ipv altijd opnieuw het wiel uit te vinden (ik heb gevallen van code waar ze keer op keer zelf iets uitgevonden hebben dat perfect al in 1 of ander framework zat, dat we dan ook gebruikten!). Het hele coderen is helemaal nog niet matuur.


Wat iemand anders hierboven ook zei, als je agile werkt zit je eigenlijk constant alles te doen. En dat is net een van de sterktes hiervan. Geen lesson's learned op het einde van een waterfall project om er dan daarna nooit meer iets te doen, nee elke 2 weken (of einde van de sprint) een retro om te zien waar we goed zijn geweest en waar we de mist zijn ingegaan. Dat heeft veel meer mijn voorkeur.

Wat een warrige conclusies maak je.

Die van zichzelf vinden dat ze de beste zijn? Mensen die in zichzelf blijven investeren en het hoogste resultaat willen behalen zijn juist diegene met de meeste zelfkritiek, dat is tenslotte waarom ze verbeteren. En juist die mensen zie ik meestal anderen helpen omdat anderen met vragen naar ze toekomen.Ik herken dat rare geschetste beeld niet echt.

Nieuwe oplossingen bedenken is simpelweg een andere kwaliteit dan fouten opsporen in al een bestaande oplossing. Het is vrij logisch dat als je je uitdaging vindt in het eerste, dat het dan onaantrekkelijk wordt om vooral het tweede te moeten doen. Er zijn weinig zaken die deprimerender en frustrerender zijn dan werk onder je niveau te moeten doen als je op zoek bent naar de intellectuele uitdaging.

Extreme programming werkt alleen goed als tenminste één van de twee een goede programmeur is. Bij minder goede programmeurs heb je er niet zoveel meer aan. Het is inderdaad zo dat er meestal maar één oplossing is die het meest optimaal en efficiënt is. De democratische weg heeft weinig zin.. Dat betekent overigens niet dat dat er geen samenwerking mogelijk is of dat er geen afspraken gemaakt kunnen worden. Het is alleen dat dat ik alleen dat ik altijd wat ongemakkelijk word van zo'n geforceerd teamgedoe, terwijl programmeren in de essentie toch een vrij eenzaam beroep is.
Als je het al als een team ziet, dan moet je optimaal gebruik maken van de kwaliteiten en niet iedereen geforceerd hetzelfde laten doen. Een software architect de hele dag bugs laten fixen is net zoiets als Van Nistelrooy op doel zetten. En dat van Nistelrooy niet op doel wil staan is niet omdat hij zich beter voelt dan iedereen, maar omdat hij zijn kwaliteiten kent. Een team kan zich omhoogtrekken aan een goede programmeur, maar het niveau van de programmeur omlaag trekken zodat hij maar gelijk is aan de rest is een slecht plan. Maar verder is het meer een estafetteloop dan een een echte teamsport.

Het verband met het wiel opnieuw uitvinden volg ik ook niet echt. Al is het begrijpelijk dat je geen 35 frameworks gaat doorspitten. Maar ik heb voor de rest geen idee over wat voor code het gaat. Ik weet ook niet waar je vandaan haalt dat middelmatigheid zou betekenen dat ze alle frameworks van voor tot einde kennen en het dan niet meer zou voorkomen.

Maar waar het uiteindelijk over ging is dat mensen hier dol worden omdat ze denken dat ze tweederangsdevelopers worden genoemd. Dat heb ik nergens gelezen, maar er is toch ook een duidelijk verschil in niveau in de meeste gevallen? Ik snap niet waarom mensen op de kast zitten als het over werk gaat.

[spacy]

Ik werk zelf voor een grotere detacheerder, en heb inmiddels al in een aantal projecten meegewerkt waar we iets nieuws konden bouwen. Dit soort partijen hebben vaak grote bedrijven en overheden als klant, die hele specifieke maatwerk software willen. Dit beantwoord mogelijk je vraag waar je eens zou moeten zoeken.

Aan de andere kant in dit soort nieuwe projecten, is het een illusie te denken dat alles vlekkeloos gaat, een team bestaat uit een combinatie van ervaring en expertise, en tja niet iedereen is groot fan van documentatie, of werkt soms niet erg netjes zijn. Ik heb mij ook meerdere keren geërgerd, of plaats vervangende schaamte gehad voor bepaalde bugs door het team gecreeerd. Maar ook vaak genoeg mezelf moeten verslijten voor sufferd die op een niet al te helder moment van een dag toch een crappy oplossing bedacht had.

Bovendien ben ik in onderhoudssituaties ook leuke uitdagingen tegen gekomen, neem een productie versie van een webservice, waar maar weinig tests van waren, laat staan documentatie. De tests kon ik dus flink kunt uitbreiden, code refactoren, en daarmee uiteindelijk problemen rondom stabiliteit kunnen herleiden naar de juiste oorzaken.

Ook is er nog de vraag welke werkwijze de teams toepassen. Als je in een DevOps omgeving terecht komt, is bestaande code beheren uiteraard een deel van je werk. En dat is wel hoe steeds meer IT teams ingericht worden. Daar hoort in sommige gevallen nog veel meer bij dan alleen het code onderhoud, denk ook aan beheer van databases en servers, dit is iets dat niet elke ontwikkelaar graag doet, maar waar je met de juiste insteek en drive ook leuke uitdaging uit kunt halen.

Als laatste kun je altijd nog voor jezelf in eigen tijd apps bouwen, of bijdragen aan open source projecten, hier heb je meer vrijheid om met een hoog niveau van netheid en structuur te kunnen werken, zonder dat tijdsdruk en geld de release bepalen.