Solliciteren bij bedrijven met legacy code

[Hydra]

spacy schreef op dinsdag 3 januari 2017 @ 10:33:
Ik werk zelf voor een grotere detacheerder

[...]

Aan de andere kant in dit soort nieuwe projecten, is het een illusie te denken dat alles vlekkeloos gaat

Ja daarom zijn kleine gespecialiseerde detacheerders zoals wij zo populair

[Croga]

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.

Je zegt dus *letterlijk*

"Ik wil de shit van anderen niet opruimen. Ik wil alleen shit creëeren zodat anderen die kunnen opruimen".

Ik ben niet de eerste die het zegt, zal ik niet de laatste zijn: Get over yourself! You're not all that!

Je zit gevangen in het oude dogma van "change" en "run". Het dogma wat stelde dat er "ontwikkelaars" zijn die alleen verantwoordelijk zijn voor het maken/veranderen van het systeem en "beheerders" die verantwoordelijk zijn voor het stabiel laten draaien van het systeem. Het gevolg van dit dogma was dat er continue oorlog tussen deze twee was. Daarom zijn we daar van af gestapt. In moderne software ontwikkeling (en ik weet dat dit nogsteeds maar een klein percentage van de nederlandse bedrijven is maar we doen ons best...) is er één set aan software engineers die verantwoordelijk zijn voor de volledige levenscyclus van een stuk software. Dat is de enige manier om te zorgen dat er een sterke incentive is om kwaliteit te leveren; doe je dat namelijk niet dan mag je je eigen shit opruimen.

Dat betekend dus ook dat JIJ, TS, zult moeten accepteren dat je een stuk software onder je verantwoordelijkheid krijgt waar je zult moeten zorgen dat dit stabiel draait TERWIJL je zorgt dat er nieuwe functionaliteit bij komt.

Van je posts concludeer ik dat je nog niet heel veel ervaring in de branche hebt. Ik zou je sterk adviseren van je veel te hoge paard af te stappen en te accepteren dat je beeld van het werk niet overeen komt met de werkelijkheid en dat het aanpassen van de werkelijkheid in dit geval te hoog gegrepen gaat zijn voor je.

[gold_dust]

Croga schreef op dinsdag 3 januari 2017 @ 10:40:
[...]

Je zegt dus *letterlijk*

"Ik wil de shit van anderen niet opruimen. Ik wil alleen shit creëeren zodat anderen die kunnen opruimen".

Ik ben niet de eerste die het zegt, zal ik niet de laatste zijn: Get over yourself! You're not all that!

Je zit gevangen in het oude dogma van "change" en "run". Het dogma wat stelde dat er "ontwikkelaars" zijn die alleen verantwoordelijk zijn voor het maken/veranderen van het systeem en "beheerders" die verantwoordelijk zijn voor het stabiel laten draaien van het systeem. ...

Ik creëer om jouw bewoording te gebruiken geen 'shit' die anderen moeten opruimen. Het is niet zo heel moeilijk om iets op te zetten wat onderhoudbaar, schaalbaar, gedocumenteerd, getest, etc is. Ik heb daar ook al voldoende positieve feedback van opdrachtgevers over gehad. Wat ik wel een probleem vindt is om bij een bedrijf te starten waar het duidelijk initieel niet goed is opgezet zodat ik de 'shit' van anderen in de latere fases van de productcyclus kan opruimen. Daarom zoek ik gericht iets waar ik zelf invloed heb op de startup fase van een project.

[Cloud]

@gold_dust
Tja.. dan kan ik je slechts aanraden héél goed gebruik te maken van je proefperiode om op zoek te gaan naar oplossingen/code die voldoet aan jouw omschrijving van 'shit'. Want zelfs al laten ze je even meekijken bij je sollicitatie, dat ga je echt niet zo snel uitvissen hoor. Jammer genoeg kun je niet je proefperiode verlengen buiten het wettelijk gestelde maximum (één maand bij aanstelling van < 2 jaar), want dat was voor jou denk ik wel fijn geweest om uit te onderhandelen.

Heel wat van de zaken die je in de TS noemde zijn prima te bevragen maar of alle code en architectuur 'up to snuff' is volgens jouw standaarden is dat gewoon niet. Daar zul je actief en snel op zoek naar moeten gaan, tijdens je eerste werkdagen.

Ik zou het in elk geval niet vragen, niet op de manier zoals in dit topic. Hooguit of ze vaker from scratch nieuwe projecten doen of vaak verder werken in bestaande code bases.

[ Voor 13% gewijzigd door Cloud op 03-01-2017 11:23 ]

[Harm_H]

Croga schreef op dinsdag 3 januari 2017 @ 10:40:
[...]
Je zit gevangen in het oude dogma van "change" en "run". Het dogma wat stelde dat er "ontwikkelaars" zijn die alleen verantwoordelijk zijn voor het maken/veranderen van het systeem en "beheerders" die verantwoordelijk zijn voor het stabiel laten draaien van het systeem. Het gevolg van dit dogma was dat er continue oorlog tussen deze twee was. Daarom zijn we daar van af gestapt. In moderne software ontwikkeling (en ik weet dat dit nogsteeds maar een klein percentage van de nederlandse bedrijven is maar we doen ons best...) is er één set aan software engineers die verantwoordelijk zijn voor de volledige levenscyclus van een stuk software. Dat is de enige manier om te zorgen dat er een sterke incentive is om kwaliteit te leveren; doe je dat namelijk niet dan mag je je eigen shit opruimen.

Dat betekend dus ook dat JIJ, TS, zult moeten accepteren dat je een stuk software onder je verantwoordelijkheid krijgt waar je zult moeten zorgen dat dit stabiel draait TERWIJL je zorgt dat er nieuwe functionaliteit bij komt.

Je hebt gelijk wat betreft oude dogma's. Ik deel de visie om IT te laten ontwikkelen en beheren door dezelfde groep mensen. Ik vermoed ook zeker dat TS een hoop negatieve baggage heeft.

Zijn schrijfstijl en arrogantie neigen eerder naar gebroken passie/vertrouwen. Een angst om kwetsbaar te zijn. Waar dit tegen je gebruikt wordt. Anderzijds geen ruimte krijgt om zijn talenten te benutten.

Desalniettemin is het wel goed van TS om duidelijke standaarden te hebben. Zolang hij bewust is waarom hij deze standaarden ambieert. Daarbij dus niet meer een bedrijf te accepteren dat een verziekte werkcultuur kent met achterhaalde - of zelfs geen - IT standaarden.

[Hydra]

Croga schreef op dinsdag 3 januari 2017 @ 10:40:
[...]

Je zegt dus *letterlijk*

"Ik wil de shit van anderen niet opruimen. Ik wil alleen shit creëeren zodat anderen die kunnen opruimen".

Nee hij zegt dat absoluut niet letterlijk. Zelf niet figuurlijk.

De rest van je betoog over 'dogmas' is je reinste kul. Het is complete onzin dat er geen verschillen in soorten teams zitten. Je hebt dat gewoon zelf nooit meegemaakt. Mensen hier stellen een knap staaltje Dunning-Kruger ten toon; dat jij het niet gezien hebt is een beperking in jouw ontwikkeling. Niks meer.

gold_dust schreef op dinsdag 3 januari 2017 @ 11:06:
Daarom zoek ik gericht iets waar ik zelf invloed heb op de startup fase van een project.

Ik zou het als ik jou was hier gewoon bij laten. Te veel mensen passen je reactie in hun straatje zodat ze er daarna lekker tegenaan kunnen schoppen.

[ Voor 18% gewijzigd door Hydra op 03-01-2017 12:26 ]

[Croga]

Hydra schreef op dinsdag 3 januari 2017 @ 12:24:
De rest van je betoog over 'dogmas' is je reinste kul. Het is complete onzin dat er geen verschillen in soorten teams zitten. Je hebt dat gewoon zelf nooit meegemaakt. Mensen hier stellen een knap staaltje Dunning-Kruger ten toon; dat jij het niet gezien hebt is een beperking in jouw ontwikkeling. Niks meer.

jij noemt het kul, ik noem het de gangbare theorie in IT land die sterk aan het veranderen is en wat ondertussen zo'n 25 jaar mijn vak is. Heeft in het geheel niets met "zelf nooit meegemaakt" te maken, noch met Dunning-Kruger, wel alles met wetenschap en ervaring. Ik zou je dus willen vragen je psychobabble buiten de discussie te houden als het een onderwerp betreft waar je duidelijk geen kaas van gegeten hebt.

[emnich]

Ik snap wel wat TS bedoelt, vrijwel niemand heeft zin om de shit van anderen op te ruimen en als er slecht gewerkt wordt in een bedrijf dan is er gewoon veel shit.

Dit is niet anders bij andere functies. Als je bij HR werkt en de dossierkasten zijn een zooi dan heb je ook geen zin om dat opnieuw in te richten. En als je bouwvakker bent en niemand ruimt z'n troep op zodat je niet lekker kunt werken, zoek je ook snel een nieuwe baan.

Echter je ontkomt er vaak niet aan dat er in het verleden slechte producten gemaakt zijn. Zeker als de code al flink oud is dan voldoet het gewoon niet aan de huidige standaarden. Je enige optie is dan een bedrijf te zoeken wat pas redelijk recent gestart is of die de oude shit al opgeruimd heeft.

Als er bij mij iemand solliciteert die vooraf al aangeeft geen shit te willen op ruimen dan komt ie er niet in. Hoewel het misschien niet terecht is, is het voor mij een slechte werkhouding. In elk bedrijf ontstaat soms iets waar je minder trots op bent en iedereen moet zich dan inzetten om dat weer te verhelpen.

Ik denk vooral dat veel mensen zich er aan storen dat TS een onderscheidt maakt tussen de verschillende ontwikkelaars. Vaak is het moeilijker om bestaande projecten om te bouwen naar de huidige standaarden (zonder dat er dingen kapot gaan) dan vanaf scratch te beginnen met een heel nieuw project. Deze mensen slechts "ontwikkelaars" noemen is dan ook onzin.

[CodeCaster]

Hydra schreef op dinsdag 3 januari 2017 @ 12:24:
Je hebt dat gewoon zelf nooit meegemaakt. Mensen hier stellen een knap staaltje Dunning-Kruger ten toon; dat jij het niet gezien hebt is een beperking in jouw ontwikkeling. Niks meer.
[...]
Ik zou het als ik jou was hier gewoon bij laten. Te veel mensen passen je reactie in hun straatje zodat ze er daarna lekker tegenaan kunnen schoppen.

Wie de schoen past, trekke hem aan. Je weet van jezelf hopelijk dat je regelmatig bijzonder ongenuanceerd reageert door met gestrekt been vol op één begrip of opmerking in te gaan, daarbij het bredere plaatje van de betreffende post uit het oog verliezend, zoals je hierboven demonstreert?

Volgens mij heeft nog niemand hier ontkend dat er bedrijven zijn waarbij er wordt gewerkt met aparte productontwikkelingsteams, die frameworks of basisapplicaties bouwen, implementatieteams die daarop weer features ontwerpen en implementeren en supportteams die onderhoud of klantspecifieke aanpassingen doen, met daarnaast nog eens onderhoudsteams die producten draaiend houden (backporten, patchen, hotfixen, klantsupport) die richting End-of-Life gaan.

Blijkbaar doelt TS met "onderhoud" op de werkzaamheden die laatstgenoemde teams doen, maar dat is niet de gangbare definitie.

In mijn ervaring zijn bedrijven met zo'n scheiding in de verschillende werkzaamheden zeldzaam, of zit er in ieder geval behoorlijke overlap in. Dan kun je mij weer op mijn ervaring gaan aanvallen, maar dat mag je achterwege laten. Koppel daaraan nog eens dat bedrijven waarin het goed toepassen van SCRUM, OTAP, CI/CD, OO, DevOps, documenteren, testen en wat dies meer zij minstens even zeldzaam zijn en voilá: de combinatie daarvan is schijnbaar onvindbaar, en daar hebben we exact het probleem waar TS tegenaan loopt.

Misschien is het ook wel zo dat als iemand moet vrágen naar waar zulke bedrijven zijn, dat ze niet naar diegene op zoek zijn. Anders had het bedrijf wel contact met hen gezocht.

Jij mag je in de handen wrijven met je situatie, en ik denk dat er genoeg mensen hier jaloers mogen zijn op wat jij voor werk doet, maar het gros van de developers die ik ken en spreek werken voor een middelmatig bedrijf, bouwen middelmatige software en zijn wellicht gewoon ... middelmatig. Ze bouwen "Yet Another Java CRUD Application" (of hoe noemde Joel dat?).

Volgens mij is elke developer met een greintje passie in z'n hart op zoek naar zo'n heilige graal als baan of opdracht, maar zowel jij als de TS mogen wat mij betreft een toontje lager zingen tegen mensen die de échte realiteit kennen en dat hier komen melden, getriggerd door de lompe verwoording van zowel jou als de TS.

Je moet je realiseren dat jíj degene bent die in een uitzonderingspositie zit, en dat de softwaremarkt in ieder geval in Nederland over het algemeen gewoon bagger produceert en dat er jaarlijks miljarden en miljarden euro's worden weggesmeten aan het oplappen en draaiend houden van software die nooit uitgebracht had mogen worden. Dus betrek jouw ervaringen niet op het gehele werkveld.

En ja, ik realiseer me dat die laatste opmerkingen beide kanten op werkt.

Dus voor de laatste keer: ik begrijp TS helemaal, maar het denigrerende gedoe dat verschillende personen hier tentoonspreiden is helemaal nergens voor nodig.

[Hydra]

Croga schreef op dinsdag 3 januari 2017 @ 12:46:
jij noemt het kul, ik noem het de gangbare theorie in IT land die sterk aan het veranderen is en wat ondertussen zo'n 25 jaar mijn vak is. Heeft in het geheel niets met "zelf nooit meegemaakt" te maken, noch met Dunning-Kruger, wel alles met wetenschap en ervaring. Ik zou je dus willen vragen je psychobabble buiten de discussie te houden als het een onderwerp betreft waar je duidelijk geen kaas van gegeten hebt.

Na alle stromannen komt je nu met een appel op autoriteit? Ik werk zelf zo'n 14 jaar in het vak en heb hiervan minimaal 10 jaar als consultant (6 jaar voor een tech bedrijf als integratie consultant, tegenwoordig gedetacheerd vanuit een kleine gespecialiseerde club) een hele hoop projecten van binnen gezien. UWV, IND, ING, Philips, Forensisch Instituut, USG en Randstad om maar een paar bekende namen te noemen. Ik heb hier steevast samengewerkt met zowel in-house developers, grote algemene detacherings clubs (Cap, IBM, Logica, Accenture, Ordina) als met kleine gespecialiseerde clubs (Xebia, Luminus, wijzelf) samengewerkt.

Kom dus niet aan met je 25 jaar. Je bent een goed voorbeeld van iemand die in een eigen wereldje zit en niet doorheeft dat daarbuiten een hoop andere dingen te zien zijn.

Het is doodnormaal dat er bij dit soort grote complexe projecten in de initiele start-up fase een ander team aan de slag is dan wat er na een jaar of zo aan de systemen werkt; laat staan het team dat in een tien jaar oud systeem in het eind van de levenscyclus bezig is met maintenance. Dat jij en een hoop mensen het "arrogant" vinden dat de TS (en anderen) de initiele fase veel interessanter vinden dan de 3e of 4e fase ligt compleet aan jezelf. Grote integrators als Cap en Accenture hebben daar echt compleet andere teams voor.

Jij en anderen verwarren "agile" en "devops" met de product lifecycle (zoals ik al eerder aangaf). Dat je agile werkt betekent niet dat je in de initiele fase dezelfde mensen hebt als na een jaar of twee. Het is echt de normaalste zaak van de wereld dat bedrijven juist externen inhuren om te zorgen dat het faciliterende werk (CI/CD, etc.) gedaan is en langzamerhand die (dure gespecialiseerde) externen vervangen voor in-house medewerkers.

Jij stelt dat er in "modern" software ontwikkeling een set ontwikkelaars verantwoordelijk is voor de hele levenscyclus. Complete bullshit. Hoe ga je dat uberhaupt afdwingen? Door mensen die vooral het architectuur deel leuk vinden niet aan te nemen? Geen specialisten aannemen? Een beetje schamper lopen doen over "die dure consultants" en vinden dat je het allemaal zelf wel kan? Je zal de eerste niet zijn. Maar je hebt dan wel een enorme plaat voor je kop. Wat voor jou en een hoop anderen goed overeenkomt door heel defensief te stellend dat de TS "arrogant" is. Nee; het is een software engineer die het architectuur deel het leukste vindt. En iets leuk vinden is over het algemeen een goeie manier om ergens ook erg goed in te worden. Mensen met een passie hiervoor moet je koesteren i.p.v. af te zeiken.

Edit: What the F? Heb je LinkedIn gecheckt en je bent uberhaupt geen developer! Hoe durf je dan in hemelsnaam iemand zo af te pissen?

CodeCaster schreef op dinsdag 3 januari 2017 @ 13:39:
Dus voor de laatste keer: ik begrijp TS helemaal, maar het denigrerende gedoe dat verschillende personen hier tentoonspreiden is helemaal nergens voor nodig.

Misschien moeten mensen dan woorden als "arrogant" en whatever zelfs nadat de TS aangegeven heeft het vooral over de product lifecycle te hebben en een voorkeur te hebben voor de initiele fase te hebben dan achterwege laten?

De reden dat ik hier redelijk pissig reageer (en dat ben ik serieus ook; in het wereldje waar ik zit heeft zo ongeveer verwacht dat je deze drive hebt) is gewoon omdat veel posts hier volgens een vast patroon geplaatst worden. 1. leg de tekst van de OP op zo'n slecht mogelijke manier uit. 2. negeer elke verdere uitleg die niet in dat straatje past. 3. Pas wat stromannen toe. 4. Fakkel de stromannen af.

Sorry, maar dan verlies ik alle respect voor de desbetreffende personen.

Ik vind dat wat je zegt heel treffend is. Mensen zouden jaloers zijn op mijn situatie? Heb je enig idee hoe lastig het is voor ons en de bedrijven waar wij ingehuurd worden om goeie ontwikkelaars te vinden? Die "meewerkers" zijn geen probleem. Software engineers die from scratch een microservice architectuur neer kunnen zetten; daar is niet aan te komen. Nog erger: goeie data engineers! Uurtarieven van 200E per uur zijn geen uitzondering.

Als dan in een topic gedaan wordt of middelmatigheid de norm is en de TS een arrogante zot is om daar uit te willen ontsnappen is om te huilen! We zijn dacht ik hier toch zo trots op ons opleidingsniveau en onze kenniseconomie? Als je na 4 jaar met je papiertje van school af komt begint het leren pas. Als je gezapig op je dikker wordende reet wil blijven zitten, 20 jaar bij hetzelfde bedrijf: prima. Maar ga dan niet iemand compleet af lopen fakkelen (en die mods doen er lekker aan mee) als hij wel meer wil.

[ Voor 24% gewijzigd door Hydra op 03-01-2017 14:08 ]

[BarôZZa]

CodeCaster schreef op dinsdag 3 januari 2017 @ 13:39:
[...]

Je moet je realiseren dat jíj degene bent die in een uitzonderingspositie zit, en dat de softwaremarkt in ieder geval in Nederland over het algemeen gewoon bagger produceert en dat er jaarlijks miljarden en miljarden euro's worden weggesmeten aan het oplappen en draaiend houden van software die nooit uitgebracht had mogen worden.

Dat is inderdaad wel de essentie vaak, dus de vraag van de TS vind ik niet vreemd. Toen ik mijn eerste sollicitaties had verbaasde ik me ook over de kwaliteit van veel toko's. Hoe is het mogelijk dat je als jong onervaren broekie al meteen de brakheid en onkunde kan waarnemen. Het is een krankzinnige situatie, je zou juist moeten leren van de ervaren mensen. Wat hebben die al die jaren gedaan?

Eerste bedrijf waar ik zat ook. Functies met 1000 regels aan if-statements. Pagina inladen kon een minuutje duren. Bij 75 gelijktijdige bezoekers ging de site plat. Beveiliging was ook droevig.

Maar iedereen vond het de meest normale zaak van de wereld. En het geld bleef binnenrollen, want klanten legden de lat ook niet hoog. Je zou verwachten dat het einde verhaal zou moeten zijn, maar in Nederland gaat zoveel geld rond dat dit soort bedrijven eindeloos lang kunnen bestaan. Sterker nog, ze denken dat ze het goed doen en een prachtig product afleveren. Het levert geld op, dus durven ze er niet veel aan te vernieuwen.

Ik denk niet dat TS er vanuit ging dat hij nooit een bug zou moeten oplossen. Maar er zijn behoorlijk veel bedrijven waarbij je weet dat je de komende jaren weinig zal bouwen en meer een eindeloze lijst krijgt met bugs die je niet structureel kan oplossen, maar waarvoor je een mooie hack mag bouwen.

[CMD-Snake]

Hydra schreef op dinsdag 3 januari 2017 @ 08:03:
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.

Het is wel komisch dat je beschuldigingen uit dat we het persoonlijk maken en in de alinea die volgt maak je het persoonlijk.

Het kan mij overigens werkelijk niets schelen, ik geef enkel een advies. Als je zo fixeert op bepaalde zaken maak je jezelf ongelukkig. En dergelijke 'eerlijkheid' kan bij een sollicitatie ook verkeerde gevoelens oproepen. Het feit dat ontwikkelaar gewild zijn betekent niet dat men alles bereid is om te accepteren.

Over 'technical debt' gesproken. Software die vandaag op zijn best is, is dat mogelijk over vijf jaar niet meer. Inzichten veranderen. Code die vandaag wordt geschreven is de technical debt van morgen. Dat geldt voor alles in de IT.

[GoldenSample]

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

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.

Dit. En ja knap versie beheer etc. Is wel iets dat je moet kunnen verwachten bij een professionele organisatie zulke zaken zou ik ook op afknappen.

Voor de rest is het een keuze: wen er aan of accepteer dat je vaak toch in de wat 'simpelere' systemen blijft/je naar een positie moet gaan toe werken waar je van project naar project hopt overal en nergens. Een complex systeem wordt langer gebruikt -> langer onderhouden -> extra functies toegevoegd/fixes voor een veranderende wereld -> gelijt vanzelf naar meer en meer lagacy code.

En ja het is net wat je wilt. Een groot complex systeem heeft ook weer zijn voordelen en heel andere positief uitdagende kanten.

Oh en Agile Scrum? Ben er opzich in veel situaties wel fan van (ben zelf geen programmeur/Developer maar heb er erg veel mee te maken, team dat voor mij dingen maakt werkt ook met een variant) maar besef je wel dat dat ook als nadeel heeft: documentatie is niet niet belangrijk maar wel minder belangrijk dan functionaliteit.

Overigens heeft Hydra weldegelijk een punt. Denk dat je in zo'n situatie inderdaad niet op de interne ontehoudskant moet gaan zitten nee. Vraag is alleen: ben je er wel goed genoeg/geschikt/ervaren genoeg voor om zoiets te gaan doen. Bij, noem een dwarsstraat, Accenture zit je toch in een iets ander bedrijf dan een MKBer om de hoek (dat zullen we dan maar die 'drive' noemen ) en bij Accenture is het merendeel ook gewoon in de modder aan het worstelen. Maw. wees realistisch en neem een lampje mee om deze sweetspot te zoeken.

Hell binnen een bedrijf kan t zo veel schelen. Zit zelf binnen een enorm bedrijf met hele afdelingen met allemaal legacy shit uit het jaar kruik. Ondertussen draag ik bij aan een platform (waar ook veel legacy meuk in zit) waaraan hard ontwikkeld wordt, veel nieuwe dingen gedaan worden en totaal nieuwe functionaliteit soms vrijwel vanaf Scratch wordt neergezet. Een heel andere wereld dan soms letterlijk een gangpad verder.

[ Voor 30% gewijzigd door GoldenSample op 03-01-2017 20:29 ]

[makato2003]

Als engineer blijf je continue leren, ook van legacy (misschien wel juist van...) code.
Die ervaring pas je toe, stel je bij. Dat is een continue proces.

Scrum zegt niets over prioriteit van documentatie, laat staan het niet maken ervan. Dat is echt complete onzin. Een onderkend probleem is waarborging van architectuur; het systeemontwerp.

Scrum is een tijdmanagement methode. Niet meer. niet minder.

Zoals in ieder vak heb je goede mensen die netjes werken en minder goede mensen die de kantjes eraf lopen. Dit is (helaas) van buitenaf niet te zien. Je zult in de praktijk met beide types te maken hebben, altijd.

[unezra]

Ik zit echt met verbazing dit topic te lezen.
Zelf geen developer maar systeembeheerder, heel andere tak van sport dus. Development heeft me nooit echt getrokken, op het incidentele shellscript na.

Toch zie ik wel overeenkomsten.

- Je hebt OVERAL legacy en ongeveer iedere beheerder begint met het opruimen van de troep van anderen, bewijs jezelf eerst maar voordat je aan een nieuwe implementatie van wat dan ook mag beginnen
- Iedere beheerder maakt fouten en genereert precies dat waarover de volgende generatie beheerders binnen het bedrijf gaat klagen: troep
- Iedere beheerder denkt na een jaar, 2 jaar "waarom in vredesnaam heb ik dat ooit zo gedaan"
- Je leert ongelooflijk veel van puinruimen, de systemen doorgronden, hoe bepaalde dingen in het bedrijf werken, samenwerking tussen platformen, etc, etc, etc.

Wat me ook verrast is dat veel mensen hier aangeven het opruimen van troep niet leuk te vinden (da's de milde variant) en zelfs neer te kijken op mensen die dat wel leuk vinden.

Waarom?

Ik ben dus juist een van die mensen die het geweldig vind om, binnen mijn eigen vak, de zooi van anderen op te ruimen. Daar valt eer te behalen. Het is ook lastig. Je hebt namelijk te maken met bestaande systemen en impact op de organisatie. Mensen zijn gewend op een bepaalde manier te werken en je moet zorgen dat het systeem verbeterd word (of zelfs vervangen) zonder dat daar al te veel gezeur door komt.

Natuurlijk vind ik het ook fijn om met nieuwe dingen bezig te zijn, compleet nieuwe functionaliteit te ontsluiten, maar vaak is "nieuwe functionaliteit" binnen mijn vakgebied ook het vervangen van een bestaand systeem door een nieuw systeem, waarbij de overgang niet al te heftig moet zijn.

Voor sommige projecten die eenmalig zijn huren we externen in, die sturen we dan zelf aan. Die externen doen zo'n implementatie 100x, wij zouden het 1x moeten doen. Voor hen is het standaard werk bij een nieuwe klant. Zij doen dus eigenlijk niets nieuws en wij besteden een klus uit waarbij het netto voordeliger is dan eerst onszelf helemaal op te leiden voor een klus die we maar 1x in ons leven hoeven te gaan doen.

Daar zit dus ook een overeenkomst. Je kunt prima bij een tent gaan werken die voor klanten alleen nieuwe code schrijft, maar volgens mij doe je dan nog steeds 100x hetzelfde ding maar voor verschillende klanten.

Terug naar mijn eigen vak, als hier een nieuwe beheerder binnen komt die alleen met nieuwe projecten bezig wil zijn en geen zin heeft bestaande implementaties te verbeteren is het gesprek snel afgelopen. Die ruimte is er niet. Komt diegene net van school af, is het gesprek *nog* sneller afgelopen omdat ik me in dat geval af zou vragen of zo iemand wel enige redelijkheid bij te brengen is of zelf na 3 maanden bedankt, neus in de lucht, op zoek naar een volgende werkgever.

Mijn 0,02 EUR.

EDIT (nabrander):

spacy schreef op dinsdag 3 januari 2017 @ 10:33:
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.

Dat is maar voor een deel van de OSS projecten maar zeker niet voor allemaal. Heel veel grotere OSS projecten worden gerund door commerciële bedrijven en die kennen ook gewoon release cycles en zijn afhankelijk van klantwensen. Dat is niets nieuws. RedHat ontwikkelde al vanaf het prille begin eigen code. Tegenwoordig heb je bedrijven als Canonical (Ubuntu), Suse, Combodo (iTop CMDB), Promox GmbH, Zabbix, etc, etc, etc, die allemaal zelf code schrijven en programma's voor eindgebruikers. De structuren daar zullen niet veel anders zijn.

Dus ja, er zijn OSS projecten waarbij je die vrijheid hebt maar er zijn ook heel veel OSS projecten die net zo werken als eigen projecten van reguliere commerciële organisaties.

[ Voor 18% gewijzigd door unezra op 04-01-2017 09:28 . Reden: OSS misvatting ]

[L0we]

makato2003 schreef op woensdag 4 januari 2017 @ 09:00:
Als engineer blijf je continue leren, ook van legacy (misschien wel juist van...) code.
Die ervaring pas je toe, stel je bij. Dat is een continue proces.

Scrum zegt niets over prioriteit van documentatie, laat staan het niet maken ervan. Dat is echt complete onzin. Een onderkend probleem is waarborging van architectuur; het systeemontwerp.

Scrum is een tijdmanagement methode. Niet meer. niet minder.

Zoals in ieder vak heb je goede mensen die netjes werken en minder goede mensen die de kantjes eraf lopen. Dit is (helaas) van buitenaf niet te zien. Je zult in de praktijk met beide types te maken hebben, altijd.

Scrum kan ook wel degelijk gebruikt worden om een bepaalde procesgang te borgen, het is aan jezelf hoe je dat inricht.

Bij mijn vorige werkgever was het zo dat als er geen documentatie was, je iets niet als 'af' kon beschouwen. Dat was ook onderdeel van de code review, of de documentatie duidelijk & volledig is. Op die manier kan je heel goed borgen dat de kwaliteit hoog blijft (zowel van code als documentatie)

Het fijne van zo'n proces vind ik wel dat iedereen geacht wordt om het te volgen, en aangezien er altijd een code review gebeurt, vallen de mensen die de kantjes er vanaf lopen zo door de mand.