[alg] Develop structuur binnen organisatie

[flowerp]

Sinds een maand heb ik een nieuwe baan bij een bedrijfje wat een online (J2EE) applicatie ontwikkeld. Men is daar nu met ongeveer 2 man zo'n 4 jaar mee bezig. Vergeleken met mijn vorige baan, waar ik aan een soortgelijke applicatie mee bouwde, is de organisatie echter een enorme schok voor me:

-Er wordt gewoon -niet- aan design gedaan. Niet een beetje, of een beetje slordig, gewoon 0,0. Requirements worden even doorgenomen en meteen geimplementeerd.

- Een beetje samenhangend hiermee is er dus ook geen documentatie van het software systeem. Als nieuwe programmeur moet je dus de source lezen, waar ook al geen commentaar in staat, en waar er commentaar voorkomt zijn dit kromme zinnen die door zwaar dyslectische personen zijn opgeschreven.

- Het testen is een complete ramp. Er zijn geen test-plannen, geen intergration tests, al helemaal geen unit-tests. Testen bestaat uit een paar uur voor het live gaan nog even snel door de applicatie heen klikken. Daarbij gaat er code live waar men een half uur geleden nog aan zat te werken.

- De 'projecten' voor de programmeurs worden opgedeeld in kleine en grote projecten. Een klein project is dan een halve dag tot een dag, en een groot project is een paar dagen tot 1 week, of uitzonderlijk 2 weken.

Men wil het liefst dat je enkel aan "kleine dingen werkt die zo snel mogelijk zo veel mogelijk winst op leveren". Het beter structureren van de source code (zodat ik deze als nieuwkomeling beter kan begrijpen) is uit de boze. Kreten die ik hoor zijn dan "De klant heeft helemaal niks te maken met source-code." en "We gaan nog wel eens een betere structuur opzetten, maar als we mogen niet meer bestaan hebben we daar ook niks aan." Volgens een senior programmeur die al 4 jaar mee draait wordt dat laatste overigens als vanaf het begin gezegd.

Het gevolg is een source-base die werkelijk bol staat van code die niet meer van toepassing is. Vorige week mijn hele weekend besteed aan het proberen te begrijpen van een stuk code waar ik niet uitkwam. Maandag ochtend om hulp gevraagt, zegt de verantwoordelijk programmeur dat dat stuk oud is niet meer wordt gebruikt. Echter, tijdens het draaien van de applicatie werd het nog wel gewoon aangeroepen!

Het rare is echter dat de applicatie opzich wel goed draait. Ik heb altijd geleerd dat je zonder structuur rampzalige software krijgt, maar dat valt (aan de buitenkant) best wel mee.

Omdat dit pas mijn 2de echte baan is vraag ik me af of een dergelijke werkwijze gebruikelijk is binnen een klein bedrijf (in nederland).

[Verwijderd]

Ik ben totaal niet bekend met bedrijven en hun methodieken, maar dit lijkt mij op zich toch wel een uiterste. Gaat het echt op deze manier?

[RobIII]

Ik heb beide kanten van het verhaal gezien. Heb in een klein bedrijf gewerkt waar 't werkelijk een puinzooi was (en is...) zoals jij omschrijft. Maar ook in een multinational waar 't weer té ver was doorgeslagen in mijn opinie. Daar werd zoveel bombarie gemaakt over 't wijzigen van 1 regel code dat 'r zich bij wijze van spreken 16 man over moest buigen en 't pas na weken of maanden werd vrijgegeven als "veilig om live te gaan".

Ik denk dat 't een kwestie is van afstemmen op budget, bedrijfsorganisatie (en cultuur!), soort project en soort programmeurs die je in dienst hebt. Vooral de kleinere bedrijfjes neigen natuurlijk naar je eerder omschreven situatie... Als het je niet bevalt doe je er iets aan en ga je proberen mensen/projectmanagers of desnoods de directie te overtuigen van de noodzaak om te testen e.d. En anders zoek je lekker een andere baan

[ Voor 10% gewijzigd door RobIII op 18-09-2004 17:04 ]

[klinz]

flowerp schreef op 18 september 2004 @ 16:50:
-Er wordt gewoon -niet- aan design gedaan. Niet een beetje, of een beetje slordig, gewoon 0,0. Requirements worden even doorgenomen en meteen geimplementeerd.
[...]
Het rare is echter dat de applicatie opzich wel goed draait. Ik heb altijd geleerd dat je zonder structuur rampzalige software krijgt, maar dat valt (aan de buitenkant) best wel mee.

Welcome in the real world :-)

Ik heb dit al bij een aantal kleine bedrijven aan den lijve ondervonden. Korte-termijn-denken is daar eerder regel dan uitzondering. Er moet snel winst gemaakt worden, anders ben je morgen dood.

[farlane]

RobIII schreef op 18 september 2004 @ 17:03:
Als het je niet bevalt doe je er iets aan en ga je proberen mensen/projectmanagers of desnoods de directie te overtuigen van de noodzaak om te testen e.d. En anders zoek je lekker een andere baan

Ik ben er zelf achter dat als je maar goede argumenten hebt dat je echt dit soort dingen kunt veranderen, ook al lijken ze compleet vastgeroest in het bedrijf.

Accept the things you cannot change,
Have the courage to change the things you can,
and the wisdom to know the difference.

[farlane]

klinz schreef op 18 september 2004 @ 20:45:
Korte-termijn-denken is daar eerder regel dan uitzondering. Er moet snel winst gemaakt worden, anders ben je morgen dood.

Dat zijn de bedrijven die ook daadwerkelijk niet bljiven. De goede denken echt niet op die manier, kleine bedrijven imho zelfs nog minder dan grote heb ik het idee.

[flowerp]

RobIII schreef op 18 september 2004 @ 17:03: Maar ook in een multinational waar 't weer té ver was doorgeslagen in mijn opinie. Daar werd zoveel bombarie gemaakt over 't wijzigen van 1 regel code dat 'r zich bij wijze van spreken 16 man over moest buigen en 't pas na weken of maanden werd vrijgegeven als "veilig om live te gaan".

Das inderdaad natuurlijk ook weer niet super. Ik had begrepen dat IBM zo werkt of werkte, en dat dat de reden is dat microsoft msdos moest 'maken': het externe bedrijfje was een short-cut om hun eigen bureaucratische regels te omzeilen.

Als het je niet bevalt doe je er iets aan en ga je proberen mensen/projectmanagers of desnoods de directie te overtuigen van de noodzaak om te testen e.d.

Ik heb het ook wel gezegd, en ze vinden inderdaad dat goed testen belangrijk is en dat "[ze] het zeker ook gaan doen zodra er meer tijd en geld beschikbaar is". Maargoed, volgens de seniors wordt dat al vanaf het begin gezegd (4 jaar dus nu). Ik ga het iniedergeval wel blijven proberen.

En anders zoek je lekker een andere baan

Tjsa, als iemand die eigenlijk net klaar is met hogere informatica opleiding (amper een jaar werkervaring) liggen de banen natuurlijk niet echt voor het oprapen.

Wat vinden jullie eigenlijk van de indeling van de projecten kwa tijdsduur? In het vorige bedrijfje waar ik werkte was een kort project twee weken tot een maand, een middel-lang een kwartaal en een lang meerdere kwartalen. Mischien is het alleen een kwestie van hoe je de dingen noemt, maar iets wat een halve dag aan werk is wordt hier dus een 'kort project' genoemt. Bij de vorige werkgever waren er niet eens requirements die op een halve dag gescheduled werden, laat staan 'projecten'.

[whoami]

Geef je baas eens het boek 'Refactoring: improving the design of existing code' van Martin Fowler.

[faabman]

Bij geheel nieuwe / vernieuwende applicaties (oftewel entrepreneursprojecten) kan ik me indenken dat processen op een dergelijke manier zijn vormgegeven. Maar aangezien deze organisatie al 4 jaar aan het ontwikkelen is aan dezelfde applicatie verwacht ik niet dat het een dergelijk project is. Klinkt meer als een paar "baasjes" die snel geld willen verdienen en daarbij de ballen verstand hebben van de organisatievorm die geschikt is voor ICT-bedrijven...

[ Voor 4% gewijzigd door faabman op 20-09-2004 09:23 ]

[farlane]

flowerp schreef op 19 september 2004 @ 13:00:
Wat vinden jullie eigenlijk van de indeling van de projecten kwa tijdsduur? In het vorige bedrijfje waar ik werkte was een kort project twee weken tot een maand, een middel-lang een kwartaal en een lang meerdere kwartalen. Mischien is het alleen een kwestie van hoe je de dingen noemt, maar iets wat een halve dag aan werk is wordt hier dus een 'kort project' genoemt. Bij de vorige werkgever waren er niet eens requirements die op een halve dag gescheduled werden, laat staan 'projecten'.

Tja, je kunt dit ook zien als een van de dynamische aspecten van een klein bedrijf. Ik vind het altijd wel een uitdaging om in de ( te korte ) tijd die je krijgt ook te zorgen voor een document waarin staat wat het onderwerp allemaal gaat doen, en wat het zeer zeker niet gaat doen. Je kunt dit dan gaan gebruiken als aanleiding om met de klant te gaan discussieren wat er nog bij in moet en wat eigenlijk wel weg kan. ( Dit kan overigens ook makkelijk als de ontwikkeling zelf al gestart is. Het praat sowieso makkelijker als je al wat kunt laten zien van wat je gemaakt hebt ) Op die manier kun je ook veel beter uitleggen aan de klant dat er voor de dingen die hij er in wil hebben, toch echt iets meer tijd moet worden gereserveerd.

En vergeet niet dat als je eenmaal zelf de discussie met de klant kunt voeren, je veel sneller al in het begin van het traject betrokken wordt in een project. In die positie kun je dan ook meer invloed uitoefenen op de tijd die je er in mag steken. ( Maak vooral duidelijk dat het documenteren en testen van de software ook tijd kost !)

[Gomez12]

flowerp schreef op 18 september 2004 @ 16:50:

- De 'projecten' voor de programmeurs worden opgedeeld in kleine en grote projecten. Een klein project is dan een halve dag tot een dag, en een groot project is een paar dagen tot 1 week, of uitzonderlijk 2 weken.

Dit is een logisch gevolg van de vorige dingen. Zonder design / documentatie en testen kan je inderdaad dingen in een halve dag opzetten. Gevolg hiervan is alleen wel weer dat je alles uit source moet halen. Waar dus weer geen tijd aan besteed is ( denk aan comments etc ).

Het beter structureren van de source code (zodat ik deze als nieuwkomeling beter kan begrijpen) is uit de boze.

Let op dat dit heel veel tijd gaat kosten. Want je moet niet alleen de source code gaan structureren, maar ook je collega's gaan vertellen hoe je hun source code gestructureerd hebt, en hun nog even bijbrengen dat ze op een andere manier moeten gaan coden.

Vorige week mijn hele weekend besteed aan het proberen te begrijpen van een stuk code waar ik niet uitkwam. Maandag ochtend om hulp gevraagt, zegt de verantwoordelijk programmeur dat dat stuk oud is niet meer wordt gebruikt. Echter, tijdens het draaien van de applicatie werd het nog wel gewoon aangeroepen!

LOL . Dit is wel een goed punt om met je baas over te gaan praten. Als het je zoveel tijd kost om iets te gaan begrijpen, dan klopt er iets niet helemaal.

Het rare is echter dat de applicatie opzich wel goed draait. Ik heb altijd geleerd dat je zonder structuur rampzalige software krijgt, maar dat valt (aan de buitenkant) best wel mee.

Is niet zo heel raar. Zonder structuur kan een programma nog best werken. Het werkt alleen niet "optimaal" omdat er stukken code in kunnen zitten die gewoon niets doen etc.

[Verwijderd]

Uiteindelijk moet al het designen, documenteren en structureren wel het gewenste resultaat hebben. De klant moet uiteindelijk gewoon zijn programma krijgen wat hij wou en het moet een beetje vlot en stabiel werken. De meeste programmeurs/ontwikkelaars waarmee ik samen heb gewerkt zijn een beetje beroepsblind of misschien een beetje goedgelovig. Dat een programma achter de schermen goed in elkaar zit is absoluut geen garantie dat het ook goed verkoopt.

Ik heb een paar keer advies mogen geven bij de aankoop van een pakket software en dan zie je dat de klant vooral waarde hecht aan wanneer een product opgeleverd kan worden en wat de mogelijkheden zijn. Natuurlijk haal je als ITer slecht geimplementeerde programma's er vrij makkelijk uit, maar er zijn jammergenoeg maar weinig bedrijven die een 'expert' meenemen bij de gesprekken voorafgaand aan de aanschaf van een software pakket, als zulke gesprekken al gevoerd worden.

Software aan de man brengen is meestal -helaas- gewoon een kwestie van een vlotte verkoopbabbel en een geslaagde demonstratie. Dat een programma goed gestructureerd, gedocumenteerd en gedesigned is, is geen doorslaggevende factor bij onderhandelingen met een klant dus daarom heeft het bij veel IT bedrijven maar weinig prioriteit.

[EfBe]

flowerp schreef op 18 september 2004 @ 16:50:
Sinds een maand heb ik een nieuwe baan bij een bedrijfje wat een online (J2EE) applicatie ontwikkeld. Men is daar nu met ongeveer 2 man zo'n 4 jaar mee bezig. Vergeleken met mijn vorige baan, waar ik aan een soortgelijke applicatie mee bouwde, is de organisatie echter een enorme schok voor me:

-Er wordt gewoon -niet- aan design gedaan. Niet een beetje, of een beetje slordig, gewoon 0,0. Requirements worden even doorgenomen en meteen geimplementeerd.

Ze liggen mooi op ramkoers dus

- Een beetje samenhangend hiermee is er dus ook geen documentatie van het software systeem. Als nieuwe programmeur moet je dus de source lezen, waar ook al geen commentaar in staat, en waar er commentaar voorkomt zijn dit kromme zinnen die door zwaar dyslectische personen zijn opgeschreven.

De mensen die er werken zijn dus niet professionals, maar hobbyisten die toevallig geld krijgen voor het prutsen onder werktijd.

- Het testen is een complete ramp. Er zijn geen test-plannen, geen intergration tests, al helemaal geen unit-tests. Testen bestaat uit een paar uur voor het live gaan nog even snel door de applicatie heen klikken. Daarbij gaat er code live waar men een half uur geleden nog aan zat te werken.

Oh, dit is niet uniek hoor. Ik heb 3 maanden bij Databalk in Veenendaal gezeten waar ze exact zo werkten als jij hier beschrijft (alleen dan in VB.NET), en waar mockup schermpjes gemaakt MOESTEN worden voor klanten die kwamen 'testen' en waar de schijn moest worden opgehouden dat het bijna af was. Sinds het 2e jaar van de HIO heb ik dat soort praktijken niet meer meegemaakt.

- De 'projecten' voor de programmeurs worden opgedeeld in kleine en grote projecten. Een klein project is dan een halve dag tot een dag, en een groot project is een paar dagen tot 1 week, of uitzonderlijk 2 weken.

hehe Maar goed, zonder design of specs kun je niet veel verder vooruit zien natuurlijk, dus dat ze denken in max 2 weken op zich logisch

Men wil het liefst dat je enkel aan "kleine dingen werkt die zo snel mogelijk zo veel mogelijk winst op leveren". Het beter structureren van de source code (zodat ik deze als nieuwkomeling beter kan begrijpen) is uit de boze. Kreten die ik hoor zijn dan "De klant heeft helemaal niks te maken met source-code." en "We gaan nog wel eens een betere structuur opzetten, maar als we mogen niet meer bestaan hebben we daar ook niks aan." Volgens een senior programmeur die al 4 jaar mee draait wordt dat laatste overigens als vanaf het begin gezegd.

Senior programmeur? Senior prutser zul je bedoelen. Mensen die zo werken mogen zich geen senior noemen. Dit soort prutsers haalt de software development branche naar beneden EN titels die daarin gangbaar zijn.

Overigens wat jij beschrijft herken ik wel, ik ben ooit begonnen bij Triple P transport systems (aan roadrunner gewerkt, nu van groeneveld dacht ik). Alles was bedacht door een gesjeesde WB-er en een autodidacte 40-er. Geen theoretisch datamodel, ontwerpen waren alleen opgebouwd rond 'schermen', wat daarachter zat bestond kennelijk niet etc. Ik trok het op een gegeven moment niet meer en had wat tabellen genormaliseerd. (van 1 tabel van 100(!) velden naar een aantal kleinere tabellen). Dat werd me niet in dank afgenomen om het maar zacht te zeggen. Dat pakket ging wel voor 5 ton weg naar klanten. Toen maar besloten ergens anders te gaan werken, want meedoen aan prutswerk en moedwillig klanten afzetten op die manier lijkt me niet de juiste weg.

Het gevolg is een source-base die werkelijk bol staat van code die niet meer van toepassing is. Vorige week mijn hele weekend besteed aan het proberen te begrijpen van een stuk code waar ik niet uitkwam. Maandag ochtend om hulp gevraagt, zegt de verantwoordelijk programmeur dat dat stuk oud is niet meer wordt gebruikt. Echter, tijdens het draaien van de applicatie werd het nog wel gewoon aangeroepen!

haha . Heerremetiid wat een zooi. De enige tip die ik je kan geven: wegwezen daar. Je hebt een keurige opleiding gevolgd, je hebt veel kennis in huis (wellicht meer dan al die sukkels daar bijelkaar) en dat moet je niet verkwanselen bij een clubje prutsers.

Het rare is echter dat de applicatie opzich wel goed draait. Ik heb altijd geleerd dat je zonder structuur rampzalige software krijgt, maar dat valt (aan de buitenkant) best wel mee.

Nee hoor, op zich kan dat wel. Echter heb je soms wel de meest raadselachtige errors, kosten aanpassingen een fortuin, heb je veel meer mensen en tijd nodig om uberhaupt het pakket te upgraden en is er geen beleid voor 'volgende versies' want alle mensen zijn nodig voor bugfixes en andere ad-hoc aanpassingen. Je collega's bezigen zeker ook termen als "Ja soms heb je dat ineens inderdaad, dan krijg je die error" of: "Ja in theorie kan het niet, maar toch komt het voor". Indien mensen dat soort dingen gaan zeggen, wegwezen.

De halve MKB is vergeven met dit soort prutswerk overigens.

Omdat dit pas mijn 2de echte baan is vraag ik me af of een dergelijke werkwijze gebruikelijk is binnen een klein bedrijf (in nederland).

Sommige bedrijven werken inderdaad zo, anderen niet. Het is wel moeilijk een bedrijf te vinden waar het goed gedaan wordt. Het rare is dat veelal interne software afdelingen van grote bedrijven het beter doen dan pure software toko's of consultancy bedrijven.

[Verwijderd]

Dit topic bevestigt het maar weer des te meer: programmeurs zijn eigenwijze mensen en doen het liefst alles op hun eigen manier. Tabellen normaliseren, code leesbaar maken en het management aansturen als simpele voorbeelden

Ik denk dat er een duidelijk onderscheid gemaakt moet worden tussen,
A ) Het uitvoeren van taken die van 'hogere hand'* komen als zijnde werknemer en..
B ) Het runnen van een bedrijf.

*) Het management; de baas.

Waarbij ik denk dat de TS zichzelf af moet vragen of hij wil werken binnen een organisatie waarvan hij klaarblijkelijk van vindt dat het management niet deugt maar waar wel genoeg werk te verzetten is- of dat hij ergens wil werken waar hij wellicht mogelijkheden heeft om zich te bemoeien met de bedrijfsstructuur en waar bij meer vrijheid heeft in het goed opzetten van projecten.

Laatstgenoemde is iets waar het bij vele bedrijven tekort schiet, aangezien het opzetten van goede en degelijke projecten veel geld en tijd kost.
En laat de drijfveer van vele bedrijven nou zijn om geld te verdienen. Niet om het uit te geven..

Wil je goede software maken die waarschijnlijk over een x-aantal jaren nog steeds bruikbaar is en te onderhouden blijft? Ga dan bij een grotere organisatie werken.

/me mompelt iets over voor-jezelf-beginnen

[farlane]

Verwijderd schreef op 20 september 2004 @ 17:07:
Wil je goede software maken die waarschijnlijk over een x-aantal jaren nog steeds bruikbaar is en te onderhouden blijft? Ga dan bij een grotere organisatie werken.
/me mompelt iets over voor-jezelf-beginnen

Wat is dat nou voor b*ll ? Alsof uitsluitend grote bedrijven goede software maken. Er zijn genoeg kleinere bedrijven die wel proberen eerlijk zaken te doen, en een goed product willen afleveren. En ik weet niet hoe jij werkt, maar voor jezelf beginnen doe ja iha in je eentje.

[EfBe]

Verwijderd schreef op 20 september 2004 @ 17:07:
Dit topic bevestigt het maar weer des te meer: programmeurs zijn eigenwijze mensen en doen het liefst alles op hun eigen manier. Tabellen normaliseren, code leesbaar maken en het management aansturen als simpele voorbeelden

Laat ik toch even reageren op deze trollerige steek onder-water.
Ik weet niet wat je doet in het dagelijks leven, boeit ook niet echt, maar kennelijk ben je niet echt doordrongen van het feit dat er mensen zijn op deze aardbol die WAT ze doen ook GOED willen doen. Mijn voorbeeld maar even aanhalend: ik moest iets bouwen, daarvoor kon ik 2 dingen doen: dit nieuwe spul bouwen op een oude verrotte fundering of een nieuwe fundering bouwen. Had ik puur gedaan wat me was opgedragen dan had ik op de oude verrotte fundering verder gebroddeld, en de kwaliteit van mijn eigen werk was dan daar zeer onder gaan lijden.

Als een werknemer, ongeacht wat deze persoon moet doen, iets wordt opgedragen en de middelen waarmee deze werknemer zijn/haar werk moet doen zijn abominabel slecht, dan kun je als werknemer wel erg je best doen maar veel komt er niet uit.

Nu zal het sommige mensen worst zijn. Die doen gewoon wat hen wordt opgedragen, staan om 5 voor 5 met de jas aan bij de deur en rijden in een collone het bedrijventerrein af. Gaat er iets mis? Ach jee, wat boeit het.

Topicstarter behoort kennelijk niet tot die categorie, hij wil GOED werk afleveren. Jij schurkt erg tegen deze halve ambtenaren aan, of althans je kijk op het leven. Niet erg hoor, er moet toch iemand schaapachtig achter mismanagende blauwe blazers aanlopen

Ik denk dat er een duidelijk onderscheid gemaakt moet worden tussen,
A ) Het uitvoeren van taken die van 'hogere hand'* komen als zijnde werknemer en..
B ) Het runnen van een bedrijf.

*) Het management; de baas.

In het leger heb je een leidinggevende. In bedrijven heb je mensen die ander werk doen dan jij en je moet doen wat in je contract staat, niet wat iemand tegen je roept.

Waarbij ik denk dat de TS zichzelf af moet vragen of hij wil werken binnen een organisatie waarvan hij klaarblijkelijk van vindt dat het management niet deugt maar waar wel genoeg werk te verzetten is- of dat hij ergens wil werken waar hij wellicht mogelijkheden heeft om zich te bemoeien met de bedrijfsstructuur en waar bij meer vrijheid heeft in het goed opzetten van projecten.

Mag ik vragen wat JIJ doet de gehele dag? Want software bouwen in rampzalige organisaties zal het niet zijn....

Wil je goede software maken die waarschijnlijk over een x-aantal jaren nog steeds bruikbaar is en te onderhouden blijft? Ga dan bij een grotere organisatie werken.

/me mompelt iets over voor-jezelf-beginnen

Ten eerste is je opmerking over grotere organisaties echt onzin. Ten tweede is je tweede opmerking in strijd met je advies om bij grotere organisaties te gaan werken. Je bent het niet echt eens met jezelf of lijkt dat maar zo?

[.oisyn]

Verwijderd schreef op 20 september 2004 @ 17:07:
Waarbij ik denk dat de TS zichzelf af moet vragen of hij wil werken binnen een organisatie waarvan hij klaarblijkelijk van vindt dat het management niet deugt maar waar wel genoeg werk te verzetten is- of dat hij ergens wil werken waar hij wellicht mogelijkheden heeft om zich te bemoeien met de bedrijfsstructuur en waar bij meer vrijheid heeft in het goed opzetten van projecten.

Laatstgenoemde is iets waar het bij vele bedrijven tekort schiet, aangezien het opzetten van goede en degelijke projecten veel geld en tijd kost.
En laat de drijfveer van vele bedrijven nou zijn om geld te verdienen. Niet om het uit te geven..

Blaat²

Een bedrijf dat software levert levert doorgaans ook support en updates voor die software. De waterval-aanpak mag misschien goed uitpakken voor de wat kleinere projecten of de projecten die niet onderhouden hoeven worden, zodra je met wat langdurige dingen bezig bent is het gewoon financieel voordelig om je design goed op te zetten. Je moet altijd rekening houden met vertrekkende werknemers die moeten worden opgevolgd door nieuwe. Die nieuwe moeten ingewerkt worden, voordat ze daadwerkelijk aan de slag kunnen moeten ze weten waarmee ze aan de slag moeten gaan. Dit is iets dat gewoonweg gigantisch veel meer tijd kost bij een slecht ontworpen systeem, en ook uitbreidingen erop gaan vaak moeizamer. Je hebt aanvankelijk dus snel een werkend product, maar het bijhouden ervan gaat alleen maar langzamer en langzamer. Het "management" zou er goed aan doen dit te onderkennen, puur omdat er op een goede manier van ontwikkelen meer winst (want: minder kosten) gemaakt wordt.

Dat het de "eigenwijze" programmeurs zijn die hiermee komen is niet zo vreemd; zij zijn over het algemeen juist diegenen die er verstand van hebben.


Overigens kun je het designen ook overdrijven; ik zie niet zoveel noodzaak in een van tevoren compleet ontworpen klassediagram met alle pre- en post-condities gespecificeerd. Dit is voor vrij recht-toe-recht-aan projecten wellicht wel te doen, maar zodra je met iets nieuws/ingewikkelds bezig bent kun je gewoon nog niet volledig voorspellen wat je te wachten komt te staan. Je kunt dus wel enorm veel tijd besteden aan een systeem-analyse, uiteindelijk blijkt dat de praktijk toch net iets anders in elkaar zit waardoor je alles weer om moet gooien. Maar goed, misschien ben ik bevooroordeeld, ik ben dan ook pas nog aangenomen bij een bedrijf wat zich voornamelijk met technologie bezig houdt en geen standaard applicaties ontwikkelt

[farlane]

Toch denk ik dat het mogelijk moet zijn om dit soort dingen te veranderen, als je de fut hebt om de moeite ervoor te doen ( Want het is af en toe wel erg frustrerend en het kost erg veel tijd, je moet oppassen dat je niet afknapt op het software ontwikkelen alleen omdat het op die plek zo'n zooi is ).

Aan de andere kant, als je na een tijdje denkt dat wat je krijgt ( collega's, sfeer, beloning, waardering ) niet opweegt tegen de frustraties van het puinzooiruimen kun je altijd nog de pijp (of was het nou een bijl? ) aan Maarten geven ( En overstappen naar je net gevonden nieuwe baan ). Of aan iemand anders. Wat ook wel geinig is om als een eigenwijze programmeur _wel_ zelf de voorbereiding te doen die jij denkt nodig te hebben. ( En zien waar het schip strandt Je doet in ieder geval altijd ervaring op, je weet voor je volgende baan iig hoe het absoluut _niet_ moet.

Op een gegeven moment moeten je collega's toch ook zien dat het wel degelijk voordelen heeft om iets aan ontwerpen te doen.