Nieuwe werkgever maakt 'slechte' software.

[Verwijderd]

Ik werk nog niet zo lang, maar heb tijdens mijn studie mij heel intensief verdiept in alle theorie (boeken, weblogs, experimenten, code voorbeelden enz enz). Ik ben geen zgn. 'zealot' maar ik zie voordelen in de huidige beweging naar standaards. Ook ben ik een zeer nauwkeurig persoon, dit weerspiegelt zich in mijn manier van werken ('uiterlijk' van mijn code, logica van naamgeving, indeling van bestanden, scheiding van taken). Ik ben in de veronderstelling dat mijn manier van werken niet alleen 'goed' is, maar ook dichtbij de ideale manier van werken ligt.

Maar nu mijn probleem. ik kom bij een bedrijf dat er dus een absolute zooi van maakt.

Dit is niet de eerste keer dat ik dit zie bij een bedrijf. Tijdens mijn stage bij een ander bedrijf was het ook al zo. Dus ik loop rond met een kop vol kennis, en dan zie ik dat al dat moois wat ze bij MS, Macromedia, W3C en waar dan ook bedacht hebben, totaal genegeerd wordt. Ze weten hier niet eens hoe het allemaal anders zou kunnen, ze zijn nooit de tabellen en de echo "everything and the kitchen sink" ontgroeit.

Maar deze bedrijven bezigen allemaal de corporate speak op hun website, ze beloven van alles (database gestuurde whatever), maar ik weet dat het dus echt onder de maat is. Maar de bottom-line is, dat ze geld verdienen. En dus is er in principe geen noodzaak om het anders te doen! Wat maakt het voor het bedrijf uit of je je XML regel voor regel naar een bestand schrijft of dat je een XML object in geheugen opbouwt met de juiste API en deze opslaat. De klant betaalt voor beiden bizarre bedragen en weet toch niet beter.

To the point: wie heeft deze ervaring ook en hoe ga je ermee om? Ik kan zo dus niet werken (wijzigen in die zooi aanmaken, functionaliteit toevoegen) dus ik wordt langzaam gek. Maar hoe verkoop je je baas dat kwaliteit belangrijk is. Ik werk er nog maar net, dus hoe geloofwaardig ben ik: ze verdienden zonder mij al jaren geld, en nu zeg ik dat het niet goed is.

Hoe ga je om met collega's die dit dus niet belangrijk vinden, en dan met name collega's die er een zooitje van maken (geen commentaar, geen nette code) maar daar zelf wel bij varen.

Lange post, maar ik hoop toch op reacties, want ik vind het maar een lastige situatie.

[Sherlock]

Als het echt bedrijfscultuur is verander je het niet. Dan kan je het beste op zoek naar een andere baan, voglens mij is het zelfs een pré bij een eventueel sollicitatiegesprek als je dit als reden aanvoert waarom je daar weg wil.

[mjszwo]

Ik denk niet dat je dit als iets negatiefs moet ervaren, maar als iets waar voor jou grote kansen kunnen liggen.
Als iedereen er echt een soepzootje van maakt, en jij echt uitblinkt, kan jij je waarschijnlijk flink opwerken in dat bedrijf. Wanneer je dan wat meer te vertellen hebt, kun je ook bepaalde eisen stellen aan de kwaliteit van de producten. Dan heb je voor jezelf een win-win situatie gecreeerd.

[Gerco]

Ik heb ongeveer dezelfde ervaring (wel wat minder extreem gelukkig). Commerciele bedrijven werken vaak volgens het "goed genoeg" principe. Als het goed genoeg werkt is het goed, hoe het in elkaar zit en of het onderhoudbaar is, is niet relevant.

Het enige wat je daaraan kan doen is je collegas warm proberen te maken voor het schrijven van onderhoudbare software (vooral niet vertellen dat ze crap maken als je er nog langer mee wilt samenwerken), benadruk vooral de voordelen voor het bedrijf en maak duidelijk dat het geld bespaart.

Dit kun je natuurlijk niet direct gaan doen, dan vlieg je er in je proeftijd nog uit omdat je niet in het team past, je moet het langzaam opbouwen, kleine verbeteringen per keer. Wanneer er een ramp optreed (en dat gebeurt), ga dan analyseren wat er beter had gekund en presenteer dat aan je manager. Met een beetje mazzel sleep je er een promotie uit en gaat de software er nog op vooruit ook.

Op die manier ben ik ook van codeslaafje naar lead-developer opgeklommen in een korte tijd, op die plaats heb ik heel wat standaarden en regeltjes ingevoerd en ik hou mezelf voor dat dat de software flink heeft geholpen. Er zijn ook een boel andere dingen gebeurd die de kwaliteit bevorderen, zoals een goede teststructuur en design voor het coden, ander management, etc.

Ik ben na 2 jaar vertrokken bij die afdeling en ben bij een andere afdeling gaan werken binnen dezelfde holding, die mensen dachten er grotendeels net over als ik en daar voelde ik me beter op mijn plaats. Dat ik daar inmiddels al weer weg ben had daar niets mee te maken overigens.

[ Voor 15% gewijzigd door Gerco op 17-08-2005 13:50 ]

[RM-rf]

Verwijderd schreef op woensdag 17 augustus 2005 @ 13:39:

To the point: wie heeft deze ervaring ook en hoe ga je ermee om? Ik kan zo dus niet werken (wijzigen in die zooi aanmaken, functionaliteit toevoegen) dus ik wordt langzaam gek.

Om eerlijk te zijn: 'leer dat gewoon' ...
in bedrijven geld geen perfecte scholingssituatie, maar gelden de wetten van de praktijk, inclusief consultants en managers die idiote wensen op een eigenlijk te laat brengen, en zul je vaak domweg in een situatie zitten waar je gevraagd wordt zulke 'slechte' aanpassingen te doen ...

waar het klanten betreft is het een probleem om die klanten een dure aanpassingen te laten betalen, waarvan ze geeneen verschil merken.
Je kunt proeren met account-managers erover te praten en hen ook op het hart te drukken daar wel pogingen toe te doen ... maar op dat puntmoet je je goed realiseren dat de 'slechtere programmeur die doet wat hij vraagt' hem liever zal zijn dan de 'hele goede programmeur, die enkel bij opdrachten komt met wat hij niet wil doen, maar niets uitvoert' ...

Je kun ook pogen in specifieke situaties voorstellen doen om een module opnieuw te ontwikkelen, en zelf nastreven om een betere ordening in bestaande projecten te krijgen, maar het is bedrijfsmatig niet haalbaar om alles 'opnieuw' op te bouwen, vanaf het begin ...
Vraag jezelf ook wat je er precies mee denkt te winnen, en stop er niet meer energie in dan je kan en wil missen... omdat het vaak enorm veel inzet van jou vergt en je er wat betreft carriere binnen een bedrijf niet eens zoveel mee wint (met als belangrijkste reden dat de leidinggevenden geen zicht hebben op _wat_ precies anders is aan jou werkwijze, en de andere programmeurs door jou zich mogelijk 'aangevallen' voelen, omdat je hun bestaande werkwijze bekritiseerd).

In veel gevallen kan het gewoon ook zinnig zijn om je eigen kwaliteitsnormen ook gewoon voor persoonlijke projektjes te bewaren, domweg juist omdat je daarin veel vrijer bent ... dat is ook een grond waarom zulke individuele en persoonlijke projecten, veelvuldig efficienter zijn dat programmatuur die door grote instituten en/of bedrijven ontwikkeld zijn ...

[Alarmnummer]

Ik denk dat je bij ieder bedrijf wel dingen aan zult treffen die niet zijn opgezet volgens jouw manier van werken/of aan jouw standaarden voldoen.

Maar als het je zo slecht bevalt (lees je hebt geen plezier in je werk) waarom probeer je er niet met je baas uit te komen? Of anders gewoon gaan verkassen. Ieder bedrijf heeft zijn eigen cultuur en manier van werken.. misschien toch beter een bedrijf opzoeken die meer bij je past.

[PaulZ]

Wat even bij me opkomt:
Voor een beetje commercieel bedrijf wordt het toch een kosten-baten-analyse.
Levert het euri op als ze jouw goede manier gaan implementeren (zowel op korte als lange termijn)?

Ja: dan zullen ze wel mee gaan.
Nee: dan blijft het zo.

Je zal wel van hele goede huize moeten komen en met mega-argumenten als je een al jaren ingesleten werkwijze wilt veranderen.

Kortom: hier gaat een hoop energie inzitten en genereert een boel frustratie (stress, burn-outs etc). Leg je er bij neer of ga weer kijken op de banenmarkt...

[Rac-On]

zoals RM-rf min of meer zegt gelden er in het bedrijfsleven hele andere normen en regels dan je geleerd hebt. Alles netjes doen kost nu eenmaal flink wat extra tijd en tijd is geld.
onderhoud boeit trouwens weining. Een aanpassing aan het produkt is gewoon een nieuwe offerte met bijbehorende betaling.

[Gerco]

Ik moet er wel even bijvertellen dat de software van mijn voormalige werkgever te omschrijven viel als een bugmijnenveld met een domino day rivaliserende kwetsbaarheid. Met meer dan 4 miljoen regels code is dat dwijlen met de kraan open. Het kon alleen maar beter en de medewerkers en de klanten) wisten dat er snel iets moest gebeuren omdat anders het produkt direct de vuilnisbak inkon en het bedrijf er achteraan.

Dat is natuurlijk wel een ideale omgeving om eens flink de bezem door te vegen, als het allemaal wel goed gaat is het bijna onbegonnen werk om zo'n cultuur om te draaien en dat moet je ook vooral niet proberen. Daar wordt je helemaal knettergek van, dan kun je beter op zoek naar iets anders.

[HellPunk]

Ik heb dezelfde ervaringen binnen mijn bedrijf, al is het dan in een andere afdeling'. Ik doe hier
namelijk de vertalingen van offertes, brieven e.d. voor buitenlandse klanten. Toen ik hier begon was de trend 'quick and dirty': je kreeg een uur om twee pagina's te vertalen en dus moest ik vaak voor de eenvoudigste oplossing kiezen, al was het dan niet altijd op de manier die op school geleerd had.

We zijn nu zes jaar later en door allerlei reorganisaties ben ik ondertussen zelf degene met de meeste ervaring. Zo kan ik nu zelf wat meer mijn stempel drukken op 'het beleid' en dat wil zeggen dat vertalingen pas de deur uit gaan als ik er tevreden over ben.

Nu besef ik beter dat je als nieuwe werknemer niet in een paar maanden een hele bedrijfscultuur kan gaan omgooien, maar uiteindelijk kan je wel degelijk een verschil maken. De vraag is alleen of je zo lang binnen die bedrijfscultuur kan blijven functioneren, maar dat is een persoonlijke zaak.

[remco_k]

rac-on schreef op woensdag 17 augustus 2005 @ 13:56:
zoals RM-rf min of meer zegt gelden er in het bedrijfsleven hele andere normen en regels dan je geleerd hebt. Alles netjes doen kost nu eenmaal flink wat extra tijd en tijd is geld.
onderhoud boeit trouwens weining. Een aanpassing aan het produkt is gewoon een nieuwe offerte met bijbehorende betaling.

^^ met hem

Bij ons gebeurt dat ook. Sommige projecten moeten soms snel af of moeten el-cheapo (van de klant). In dat geval word het een pakketje waterval code en in een paar werkdagen tijd (soms zelf minder dan 1 dag) word een project van begin tot eind bedacht en gemaakt. Niet netjes, wel effectief. Ik zie het zelfs als een specialiteit van mezelf, om zoiets voor elkaar te krijgen wat nog perfect werkt ook. (I've been there, diverse keren zelfs nooit meer feedback over bugs oid gehad)

Bij de grotere projecten (bv meer dan een half jaar werk voor meerdere programmeurs) onstaat er bij ons wel een goede structuur en moeten wij (de programmeurs) eerst aangeven bij sales hoeveel tijd/energie en vooral ergernis kosten wij kwijt zijn. Dat resulteerd dan vaak in genoeg tijd om alles duidelijk, goed en vooral gestructureerd te maken. Deze projecten zijn achteraf dan prima onderhoudbaar en gemakkelijk te debuggen.

TS: Wat jij bij dat bedrijf ziet, gebeurd bij veel bedrijven, op zich is er niets mis mee.
Als je een kopieer tooltje moet maken om elk uur 1 file te kopieren is het ook niet echt zinvol om aan te geven dat je daar 2 weken werk voor nodig hebt waarvan 4 uur programmeerwerk en de rest om de boel te documenteren en te testen. Dat zou jouw software markt niet echt ten goede komen en de klant gaat naar een ander die het binnen 3 dagen of nog minder kan doen.

[alienfruit]

uurtje-factuurtje

[justmental]

Al bedrijf wil je gewoon een flexibele goed communicerende ontwikkelaar die functioneel bouwt wat nodig is.
Gezeur over techniek en standaarden levert geen knikkers op en kan dus genegeerd worden.
Tot er echte pijn is, bijvoorbeeld in de beheerkosten, maar dat gebeurt bijna nooit.

[Croga]

Verwijderd schreef op woensdag 17 augustus 2005 @ 13:39:
Ik ben in de veronderstelling dat mijn manier van werken niet alleen 'goed' is, maar ook dichtbij de ideale manier van werken ligt.

Persoonlijk vindt ik het aardig arrogant om te stellen dat jij, als schoolverlater, het beter weet dan de mensen die al jarenlang hun brood er mee verdienen, en dat blijkbaar nog goed doen ook nog (anders hadden ze óf geen baan, óf geen opdrachten meer gehad).......

Mischien is het slimmer om je oor eens te luisteren te leggen bij het bedrijf, en ze te vragen waarom er op deze manier gewerkt wordt. Zoals al eerder vermeld: Over het algemeen is de commerciele haalbaarheid een heel stuk belangrijker dan de theoretische netheid van de code..... Tenslotte kun je niet eten van perfecte programma code......

[Verwijderd]

Ik heb zelf ook deze ervaring.

Toen ik bij mijn huidige werkgever kwam werken was de code zo'n enorm groot zooitje, dat wil je niet weten. Alle java code (+- 150.000 regels) stond in 1 grote package. De java files stonden in de CVS, maar de rest van de delen van de web applicatie niet. Om onduidelijke reden stonden de JSP bestanden in een shared directory op een centrale test server. (er was wel een reden: de mensen die aan de JSP bestanden werkte snapte niet hoe CVS werkte en hoe ze lokaal een webserver moesten draaien). Alleen al het compileren van de app was een ware hel. Niemand wist meer hoe dat moest van scratch. Er was 1 developper die het draaiend had, maar zelf die kon je niet vertellen hoe het moest. Hij had een paar honderd directories in zijn classpath staan en weet ik hoeveel instellingen die ie ooit gedaan had maar nu niet meer wist.

Daarnaast was de code zelf ook erg chaotisch. Lappen business code stond midden op JSP pages. Erg veel copy/paste werk. Er waren geen designs en geen documentatie.

Ik heb dit juist een beetje als uitdaging gezien. 1 van de eerste dingen die ik deed was het gebruik van een IDE introduceren (Eclipse), en in stapjes alles onder versie controlle zetten. Vreemd genoeg was er hier in het begin nog echt wel wat weerstand tegen. Men vond het onzin om SQL onder versie controlle te gaan zetten (toch ook snel een regeltje op 100.000), dus dat heeft nog een paar maanden geduurd.

Vervolgens heb ik gewerkt aan het maken van een handleiding hoe je stap voor stap het project in zijn geheel uit de CVS moest halen, compileren, en deployen. Als er nu een nieuwe developper komt, heeft deze binnen een uur een complete local installatie van de software draaien via Eclipse. Dit duurde eerst minstens een week.

Een ander eigenaardigheidje hier was dat men niet geloofde in procedures. Gevolg was dat 5 minuten voordat een versie live ging, de programmeurs nog met rood aanlopende hoofden de laatste bugs zaten te verwijderen. Ik heb toen een hele simpele regel ingevoerd dat een versie die live moet gaan altijd eerste een week naar een development server gaat, en pas vanaf de development server live mag. Ook hier was eerst enorme weerstand tegen. Men kon de gedachte niet aan dat je een week lang niks aan de code mocht veranderen maar alleen in een CVS branch of lokale versie verder mocht werken. Maar gaande weg zag men in dat zo'n code freeze toch wel een enorm grote rust bracht (men had eerder klachten van stress en RSI).

Een zelfde verhaal geldt voor de business logic op JSP pagina's. Men begint er steeds meer van overtuigd te raken dat je dit niet moet doen, en deze code in aparte java business logic classes moet plaatsen.

Gaande weg wordt het bedrijfje dus volwassener. Natuurlijk moet je het invoeren van een dergelijke structuur (=omgooien van bedrijfscultuur) wel leuk vinden om te doen, en niet verwachten dat het in 1 nacht gaat.

[Tomatoman]

Slechte software is slechte software, daar zullen we het over eens zijn. Voor een klant is het vanuit gebruikersoogpunt echter irrelevant hoe de software achter de schermen in elkaar steekt. Of dat nou prachtig gestructureerde code is of een rommeltje, de gebruiker merkt geen verschil.

Wel is het zo dat slechte code vaak resulteert in matige software. Indirect merkt de gebruiker daardoor vaak toch wel wat van de kwaliteit van de code. Dat laat onverlet dat slechte code lang niet altijd een probleem hoeft te zijn voor de klant. Hij betaalt voor het resultaat en niet voor schitterend geïmplementeerde design patterns, naamgeving van source files en correcte indentatie van de broncode.

Ik kan me Krimszons ergernis levendig voorstellen, ik heb me ook rot geërgerd aan de brakke code van collega's. Zoals aangegeven is dat echter vooral een ergernis voor de programmeur, niet voor de eindklant. Sterker nog, de klant kan er zelfs baat bij hebben!

Dat zal ik toelichten . Een in een uurtje in elkaar geflanst dialoogvenster kost de klant het equivalent van een uur werk. Als datzelfde scherm op een nette manier wordt geprogrammeerd is het eindresultaat misschien (maar niet zeker) net wat gelikter, maar het heeft wel drie uur werk gekost. Het is maar de vraag of de klant er twee uur extra voor overheeft, hij ziet immers nauwelijks of geen verschil in het eindresultaat.

Al met al moet je je afvragen in hoeverre 'de ideale manier van werken' in het voordeel van de klant werkt. Tot op zekere hoogte moet je kwaliteit leveren, maar in principe niet meer dan waar de klant om vraagt (want wie betaalt de ongevraagde extra kwaliteit?). Een bedrijf dat er een zootje van maakt is daarom slecht, maar een bedrijf dat geen enkele consessie aan kwaliteit wil doen is voor de klant niet veel beter. Als ik lees dat je 'een zeer nauwkeurig persoon' bent, loop je een tamelijk groot risico om in je hang naar perfectionisme een beetje door te schieten . Is de klant daar echt bij gebaat?

[Verwijderd]

justmental schreef op woensdag 17 augustus 2005 @ 14:18:
Tot er echte pijn is, bijvoorbeeld in de beheerkosten, maar dat gebeurt bijna nooit.

*kuch*

Dat gebeurd zeer zeker wel. De reden dat ik in mijn bovenstaande verhaal de cultuur verandering er door heen kon krijgen was dat men tegen enorme beheer en uitbreidings kosten opliep. Wij hebben namelijk 1 hoofdapplicatie die al meerdere jaren in ontwikkeling is. De werk situatie begon echt uit de hand te lopen. Bugs waren bijna niet op te lossen omdat de structuur van de code zo compleet ondoorgrondelijk was. Op het laatst werden bijna alle bugs terzijde geschoven als "rare VM errors" of "rare hardware errors".

[Verwijderd]

Croga schreef op woensdag 17 augustus 2005 @ 14:18:
[...]


Persoonlijk vindt ik het aardig arrogant om te stellen dat jij, als schoolverlater, het beter weet dan de mensen die al jarenlang hun brood er mee verdienen,

Ben ik het niet mee eens. De schoolverlaters, en dan met name mensen die van de universiteit afkomen, zijn wel geschoold in de laatste ontwikkelingen en moderne technieken. Veel werknemers in een bedrijf hebben of uberhaupt geen opleiding gehad. Vvergeet niet dat veel mensen in de ICT hype tijd zijn aangenomen en deze hebben in de praktijk wat programmeren geleerd. Hun aanpak is structureel fout. Dat er geld wordt verdiend is mischien wel zo (en dat is altijd het standaard argument), maar dat betekend niet dat je werkwijze goed is. Een oplichter verdient immers ook geld, een inbreker verdient ook geld, en zelfs Microsoft verdient (veel!) geld. (ok dat laatste was een trollerig grapje ).

Het is vaak arrogant om te denken dat een pas afgestudeerde helemaal niks waard is en dat ALLEEN ervaring telt. Uiteindelijk gaat het om een combinatie van opleiding en ervaring. De pas afgestudeerde zal inderdaad ervaring moeten opdoen, maar de werknemers (vooral die zonder opleiding) zullen moeten leren dat je niet alles op de PHP werkwijze kunt doen en dat structuur ook belangrijk is, zeker op de wat langere termijn.

Mischien is het slimmer om je oor eens te luisteren te leggen bij het bedrijf, en ze te vragen waarom er op deze manier gewerkt wordt.

Vaak weet men gewoon niet hoe het anders of beter kan. Men heeft nooit geleerd wat een design pattern is. Men weet niet wat een architectuur is. De noodzaak van synchronisatie in parallele omgevingen ziet men niet omdat het toevallig nu goed gaat, etc etc...

Ik las laatst nog een artikel dat in tegenstelling tot wat men vaak denkt, jongere dokters in sommige situaties beter zijn dan oudere ervaren dokters. Jonge dokters zijn op de hoogte van de laatste technieken, waarbij oudere dokters blijven vasthouden aan oudere technieken.

In de programmeurs wereld heb je dit ook. De zogenaamde senior die een "dino" geworden zijn: ze hebben altijd procudereel gewerkt en KUNNEN gewoon niet omschakelen naar OO. De generatie de met OO is opgegroeid maar nooit met threading/parallel werken bezig is geweest kan die overstap weer niet maken, etc.

[Jochemmol]

Eigenlijk kan je er zoals gezegd niet veel aan doen. Het is natuurlijk afhankelijk van hoe groot het bedrijf is maar wat je kan proberen is de "standaarden" die ze hebben als ze die hebben heel voorzichtig met goede argumenten "omver" te werpen. en als ze die niet hebben moet je voor jou code wel op de "goede" manier programmeren.

Dan zullen je collega's vanzelf zien dat jou code begrijpbaar is.

Maar ga vooral geen lange discussies aan omdat je daarmee de niet echt in de kijker speeld en dan zullen ze je ook niet meer serieus nemen want je bent dan in hun ogen de zeurkous.

Het beste is denk ik gewoon je werk doen en je collega's bewijzen dat jou manieren "goed" zijn en werken. Want zoals al gezegd een bedrijfcultuur verander je niet zomaar.

En als je het echt niet zint allemaal dan zit er niks anders op om eens met je baas te praten en als dat gesprek je geen genoegdoening geeft dan is de beste oplossing een andere baan zoeken. Maar daar is zul je ook dingen tegenkomen die jij graag anders doet.

Dus als je dat niet zint zou je, je eigen bedrijfje moeten oprichten en dan kan je programmeren zoals jij dat wilt

[Verwijderd]

Croga schreef op woensdag 17 augustus 2005 @ 14:18:
[...]


Persoonlijk vindt ik het aardig arrogant om te stellen dat jij, als schoolverlater, het beter weet dan de mensen die al jarenlang hun brood er mee verdienen, en dat blijkbaar nog goed doen ook nog (anders hadden ze óf geen baan, óf geen opdrachten meer gehad).......

Nee ik ben zeker niet arrogant. Maar ik snap wat je zegt, maar als je gezien hebt wat ik heb gezien, zou je het zeker begrijpen. Ze verdienen geld omdat er geen klant is die de code ziet, die zien alleen het resultaat.

Voorbeeld:

code:

xml = "<?xml version=\"1.0\" encoding=\"utf-8\">";
xml = Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(
Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(origineel, "ß", ß)"é", ž) ' Enz enz enz voor alle 'problematische' karakters
Response.Write(xml);

Dat was de code, ik kom vers van de school, en ik weet dat er uitgebreide XML api's zijn. Dus begin ik met:

code:

set xmlDoc = server.CreateObject("MSXML2.DOMDocument.4.0")
set piXML = xmlDoc.createProcessingInstruction("xml", "version='1.0' encoding='utf-8'")
xmlDoc.appendChild(piXML)

Maar dat laatste vereist dus dat je echt hele bergen ondoorzichtige code gaatherschrijven. Dus heb ik mij beperkt tot het aanpassen van:

code:

xml = "<?xml version=\"1.0\" encoding=\"utf-8\">";

naar:

code:

xml = "<?xml version=\"1.0\" encoding=\"utf-16\">";

Die karakters vormen geen enkel probleem, maar als je de encoding al verkeert specificeert, dan krijg je wel problemen ja. Maar zelfs iemand net uit school kan ff op MSDN opzoeken wat de standaard encoding op een IIS NT4 bak is. En nog steeds kan dus de code veel beter, als je ook nog ff de API gebruikt.

Begrijp je nu waar ik met mijn opmerking vandaan kom? Dat is toch niet arrogant? En geloof me, ik heb nog veel meer voorbeelden!

PS: de code heb ik ff snel ter illustratie neergezet, duszal vast wel fouten bevatten, maar t gaat ff om de andere insteek om iets tedoen, en problemen op te lossen, cq te voorkomen.

[ Voor 30% gewijzigd door Verwijderd op 17-08-2005 15:01 ]

[Verwijderd]

"Tenslotte kun je niet eten van perfecte programma code......"

Maar het kan er wel voor zorgen dat deze slechte programma code uiteindelijk resulteerd in projecten die ver over de uren gaan. Projecten die fungeren als een framework voor verdere ontwikkeling, en die vervolgens ongetest in produktie gaan onder het mom "kijk eens wat de offerte waard is".

Vervolgens wordt er op die slechte basis een 15tal projecten in een rap tempo opgeleverd, waarbij elk project bestaat uit overrides van methodes om de bugs in dat framework te ontlopen en niemand meer weet wat nu de oorzaak was van die bug.

Wat later denkt het management, ja, die kosten per project kunnen lager al mopperend op de ontwikkelafdeling dat het allemaal steeds langer duurt, en waarbij de toch al zichzelf indekkende project managers vervolgens prompt hun eigen bureau schoonvegen en met een schijnheilig gezicht zeggen "Ja dat heb ik al eerder geconstateerd" terwijl het uur daarvoor nog meerdere keren is vermeld aan die persoon dat het zo niet langer kan.

Vervolgens moeten er ingrijpende wijzigingen worden aangebracht, en kan er in al die 15 projecten nogmaals worden geinvesteerd. Er is geen goede documentatie waar al die fixes in staan, er is geen idee van het model, en elke wijziging resulteerd in 2 fouten ervoor terug.

Dit is ongeveer een situatie die je erg veel hebt en die ik vermoed hier erg veel mensen herkennen.

[ Voor 7% gewijzigd door Verwijderd op 17-08-2005 14:58 ]

[mulder]

Begrijp je pijn, heb het zelf soms ook, maar je moet ook realistisch blijven. De praktijk is namelijk geen ideale ontwikkelomgeving.
1) Doel heiligt de middelen, standaarden zijn leuk, tot een zekere hoogte (neem dat gezeik over het gebruik van tabellen vaak *gelul*)
2) Software heeft vaak een geschiedenis

[Verwijderd]

justmental schreef op woensdag 17 augustus 2005 @ 14:18:
Gezeur over techniek en standaarden levert geen knikkers op en kan dus genegeerd worden.

Maar waarom ontwikkelt 'men' dan deze techniek?

Waarom heeft dreamweaver een functionaliteit genaamd snippets of templates, als we vervolgens dat niet gebruiken?

Waarom heeft W3C de moeite genomen om diverse standaarden te publiceren en validators te maken?

Waarom ontwikkelen Microsoft en de Apache-groep api's om XML te genereren?

Waarom staan de winkels vol met boeken over dergelijke functionaliteit en standaarden?

Waarom zijn mensen zoals Nielsen of Zeldman zo gepassioneerd over hun vak, als dat genegeerd kan worden?

En zo kan ik wel doorgaan.

Ik leg me daar echt niet bij neer hoor. Ik denk dat je geld kunt verdienen én goed kunt werken, en ik zou dan toch echt een stuk beter slapen. Je ruimt thuis toch ook de rommel op, levert dat geld op?

[ Voor 4% gewijzigd door Verwijderd op 17-08-2005 15:09 ]

[Verwijderd]

To the point: wie heeft deze ervaring ook en hoe ga je ermee om? Ik kan zo dus niet werken (wijzigen in die zooi aanmaken, functionaliteit toevoegen) dus ik wordt langzaam gek. Maar hoe verkoop je je baas dat kwaliteit belangrijk is. Ik werk er nog maar net, dus hoe geloofwaardig ben ik: ze verdienden zonder mij al jaren geld, en nu zeg ik dat het niet goed is..

Ik werk nu samen met een andere jongen (ook 18) bij een bedrijf en sinds wij er werken word er 'plotseling' aan alle regels van het w3c gehouden en netjes php geprogged, heeft de jeugd van tegenwoordig toch nog een positieve invloed

Als je zelf eens een nieuw project krijgt die helemaal opnieuw opgebouwd moet worden maak het dan eens volledig uit netjes geschreven css met div's en uit goed gedocumenteerde php. Als er in de toekomst dan eens iets veranderd moet worden zien ze vanzelf in dat netjes werken toch beter is.

[P_de_B]

Vaak heb je natuurlijk te maken met een software pakket dat al jaren op de markt is, je kunt niet van een bedrijf verwachten dat ze al die code ineens even overboord gooien en overnieuw beginnen. In een ideale wereld zou je gelijk hebben, maar de wereld is niet ideaal.

[pgussow]

Verwijderd schreef op woensdag 17 augustus 2005 @ 14:35:
De schoolverlaters, en dan met name mensen die van de universiteit afkomen, zijn wel geschoold in de laatste ontwikkelingen en moderne technieken. Veel werknemers in een bedrijf hebben of uberhaupt geen opleiding gehad.

Sorry hoor, maar dit soort opmerkingen zijn redelijk kortzichtig. Ik heb gemerkt dat in de praktijk weinig verschil zit tussen de programmeer skills van HBO-er en WO-ers. Ik denk dat zelfs in de meeste gevallen de HBO-ers net wat beter zijn als het om programmeren gaat. De HBO-ers worden namelijk hoofdzakelijk tot programmeur opgeleid en WO-ers theoretischer en breder. Ook is het sterk afhankelijk van de opleiding in hoeverre ze echt de allerlaatste technieken gebruiken. Een lesprogramma moet samengesteld worden en geintroduceerd worden. Ook dat kost een hoop tijd. Dus ook als je van school afkomt kun je nog best achterlopen. In de ICT moet je zelf een brede intresse hebben en actief de nieuwe standaarden bijhouden. Anders red je het niet en word je idd een 'dino'

Vergeet niet dat veel mensen in de ICT hype tijd zijn aangenomen en deze hebben in de praktijk wat programmeren geleerd. Hun aanpak is structureel fout. Dat er geld wordt verdiend is mischien wel zo (en dat is altijd het standaard argument), maar dat betekend niet dat je werkwijze goed is.

Dit is wel een heel valide punt. Eind vorige eeuw hoefde je maar te roepen dat je wist hoe je een computer kon aanzetten en je werd aangenomen. Hup, 2 maandjes cursus en maar programmeren. Daar kun je in de markt nog steeds de nadelen van voelen. Maar het hangt ook heel erg af van het bedrijf waar je werkt. Gemiddeld zul je bij een softwarehuis veel minder van dit soort mensen aantreffen dan bij een bedrijf waar IT niet de core business is. Of ik heb gewoon mazzel met het bedrijf waar ik werk (waar IT dus wel core business is).

Het is vaak arrogant om te denken dat een pas afgestudeerde helemaal niks waard is en dat ALLEEN ervaring telt. Uiteindelijk gaat het om een combinatie van opleiding en ervaring.

Het mes snijdt aan 2 kanten. Net zoals je 'slechte' mensen met ervaring hebt, hebt je ook 'slechte' afgestudeerden. Toen ik afstudeerde waren er met mij een aantal die afstudeerden die ik nog niet eens mijn hond zou uitlaten.

[Croga]

Verwijderd schreef op woensdag 17 augustus 2005 @ 14:56:
"Tenslotte kun je niet eten van perfecte programma code......"

Maar het kan er wel voor zorgen dat deze slechte programma code uiteindelijk resulteerd in projecten die ver over de uren gaan. Projecten die fungeren als een framework voor verdere ontwikkeling, en die vervolgens ongetest in produktie gaan onder het mom "kijk eens wat de offerte waard is".

<doomsday scenario even weg geknipt om ruimte te besparen>

Dit is ongeveer een situatie die je erg veel hebt en die ik vermoed hier erg veel mensen herkennen.

Hoewel de situatie vaaglijk beekend in de oren klinkt, zal een bedrijf wat zo'n situatie vaker tegenkomt binnen korte tijd failliet zijn.... Óf ze moeten meer kosten maken voor hun projecten en verdienen daardoor geen geld meer, óf de klant wordt met de kosten opgezadeld en komt nooit meer bij het bedrijf terug (dat kun je maar bepaalde tijd volhouden; op een gegeven moment zijn de potentiele klanten gewoon op....)

Ergo; ga er maar rustig van uit dat een bedrijf wat al langere tijd mee gaat, dat soort scenarios niet vaak mee maakt. Nog sterker: Dat soort bedrijven zal de ".COM crash" niet overleeft hebben.

Ik zeg niet dat het niet gebeurt. Nog sterker: Ook ik heb dit wel eens mee gemaakt (en ben of huilend weg gerend, of heb de hele zooi opnieuw geschreven ). Toch denk ik dat het eerder uitzondering is dan regel......

En inderdaad, TS, ervaring is niet heilig. Maar de zaken die je op school leert (en dan vooral op universitaire opleidingen) zijn vaak theoriën die het licht van de praktijk niet kunnen overleven vanwege de lage realiteitszin. Ik ben groot voorstander van gestructureerd werken, maar zodra het aanbrengen van structuur meer tijd kost, dan dat de structuur naar verwachting op zal leveren is het beter om ad-hoc te werken.....

[RM-rf]

Verwijderd schreef op woensdag 17 augustus 2005 @ 15:08:
[...]


Maar waarom ontwikkelt 'men' dan deze techniek?

zulke technieken worden door technici ontwikkeld en door goede echte consultants en experts ...

maar in het bedrijfsleven wordt het echte geld verdient door account-managers en die begrijpen er weinig van ... als je het dan over documentatie, standaards hebt, vraagt die enkel aan jou, wat levert dat dan op?

De meeste technici zeggen dan dat een nette opzet van programmatuur, documentatie en gebruik van gestandaardiseerde werkwijze, in het onderhoud van software veel tijd bespaart , en daar snij je je dan voor een account-manager weer in de vingers ... omdat voor onderhoud juist leuke uur-offertes worden uitgeschreven ... het idee dat dat werk dan in de helft van de tijd gebeurt, betekent al snel dat hij daar niet meer op kan verdienen ...

In plaats daarvan worden de begin-offertes duurder en juist op dat punt moet je vaak concurreren met andere concurrenten die ook een eerste offerte indienen ... dus een accountmanager zet liever eerst een bagger-project in veels te weinig tijd op, waarna er ellenlang aan meerwerk-offertes bijverdiend kan worden ... dan dat hij een dure beginofferte heeft, waarna weinig meer te verdienen is, aan meerwerk...

Ik vind het zelf ook verschrikkelijk, maar het is wel een beetje de praktijk zoals ik hem ook ervaar, zonderdat je aan die beginsituatie structureel veel kunt veranderen, sterker nog, ik heb me 5 jaar terug in een brun-out gewerkt in een poging dingen te veranderen ... wel met enig resultaat, maar zonder dat ik er persoonlijk zoveel beter van werd .... dat moet je ook realiseren.

[Rac-On]

Croga schreef op woensdag 17 augustus 2005 @ 15:29:
Ik ben groot voorstander van gestructureerd werken, maar zodra het aanbrengen van structuur meer tijd kost, dan dat de structuur naar verwachting op zal leveren is het beter om ad-hoc te werken.....

* Rac-On is het er mee eens en murmelt iets over de juiste balans vinden en zo

[Sallin]

ik vind deze opmerking wel toepasselijk bij dit topic:

Verwijderd schreef op dinsdag 16 augustus 2005 @ 09:54:
In het algemeen (zo is de opvatting van de meerderheid van mensen) moet je nooit code gaan vervangen , ook al is het een enorme WTF.

Ik heb laatst een topic geopend wat precies hierover gaat:

[rml][ alg] Herschrijven brakke code collega's?[/rml]

Zelfs de experts zijn er duidelijk over: blijf met je poten van andermans code af. Als het werk, dan werkt het.

Alleen in het geval dat je toch een bug moet fixen in de code of echt groot (radicaal) onderhoud moet plegen, kun je overwegen een WTF weg te halen, maar dan moet je wel eerst met de grootste voorzichtigheid en diplomatie je WTF'ende collega benaderen.

Uit dit topic gekopieerd

[leeke1984]

Ik heb zelf niet super veel verstand van programmeren, maar ben BI'er (Bedrijfskundig Informaticus) en zou dus iemand zijn die dit soort problemen zou oppakken. Probleem is dat cultuurveranderingen niet makkelijk te weeg zijn te brengen.

Wil je dit veranderen, dan zal je er heel veel tijd in moeten steken! Je zult alle mensen moeten overtuigen van jouw betere methode van werken. Dit zal niet makkelijk zijn, aangezien je zeer waarschijnlijk de 'jonge snotneus' bent binnen het bedrijf. De oudere mensen denken al gauw dat ze het beter weten, omdat ze er al langer werken. Dit is natuurlijk een verkeerde gedachte, maar zie ze dat maar eens aan de man te brengen. Vaak is het dan ook belangrijk om eerst het management / de leidinggevende van de afdeling (indien het een groot bedrijf is) te overtuigen. Deze kan je helpen druk te zetten op de andere medewerkers. Dit kan je doen door het management in te laten zien wat voor meerwaarde jouw manier van werken heeft. Op de korte termijn zal het waarschijnlijk negatieve gevolgen hebben voor het bedrijf, maar op de lange termijn...

Mogelijke argumenten kunnen zijn:

• Het makkelijker opleiden van nieuwe werkkrachten wordt in de toekomst veel makkelijker en minder tijdrovend. Immers kan iedereen makkelijk de code begrijpen door commentaar bij de code.
• Het updaten van code wordt makkelijker, omdat alles beter ingedeeld is. Hierdoor is de up te daten code makkelijker terug te vinden en dus zal dit veel tijd en dus kosten bepalen.
• Het maken van add-ons is makkelijker in te passen in de producten. Zelfde namen enz. worden gebruikt en dit zal veel tijd besparen en dus wederom kosten
• Indien de codes universeel zijn kunnen ze apart opgeslagen worden in classes (althans in java is dat zo, maar gok dat dit overal wel kan) die opgeroepen kunnen worden. Deze classes kunnen ook bij nieuwe projecten veel tijd besparen, omdat ze zo gekopieerd kunnen worden.

Dit tot zover op het programmeerniveau. Ik denk echter dat je zelf er meer over weet dus je zult het ook wel beter kunnen onderbouwen enz.

Je kunt echter ook nog op een hoger niveau denken en zeggen dat het verbeteren van de code zoveel tijdwinst oplevert, dat de klant zijn producten zoveel sneller krijgt, door gestandaardiseerde codes (lange-termijn). Dit kan een belangrijk concurrentievoordeel zijn, waardoor er meer klanten komen. Meer klanten kunnen ook geholpen worden (met dezelfde hoeveelheid medewerkers), vanwege de gestandaardiseerde code. Zo hebben ze dus meer geld in het laatje.

Nu is het voor jou alleen nog zaak dit mooi over te brengen en de kosten tegen de baten goed neer te zetten en het management overtuigen dat het ze een investering kost, maar daarna ook veel gaat opleveren. Eerst is de keuze aan jou: Wil jij je werpen in deze rotzooi? Reken erop dat je veel tegenstribbeling gaat krijgen van de werkvloer!

VEEL SUCCES!

[Verwijderd]

[b]Verwijderd schreef op woensdag 17 augustus 2005 @ 13:39:Ik ben in de veronderstelling dat mijn manier van werken niet alleen 'goed' is, maar ook dichtbij de ideale manier van werken ligt.

Er is geen ideale manier van werken. Punt!
Ieder project is anders, en vraagt een andere aanpak. Voor een klein programma wat 1 simpele taak uitvoerd ga je geen groot plan opstellen. Als je dan ook nog weet dat het programma tijdelijk hoeft te draaien, dan kun je zelfs nog afvragen of je commentaar/documentatie moet toevoegen. (hmm... gevaarlijke uitspraak)
En bij een groot project begin je niet zomaar met coden.

Maar goed, daar ging het eigenlijk niet om.
- Hoeveel vrijheid heb je om je taak uit te voeren? Zit je vast aan een bepaalde werkmethode, of kun je zelf bepalen wat je doet, en hoe, en wanneer?
- Staat je leiding gevende open voor nieuwe ideeen/ontwikkelingen?
- Wordt jouw code door andere mensen bekeken/gebruikt?

Wat je kunt proberen is gewoon je eigen gang gaan. Laten zien dat jouw manier van werken sneller betere code oplevert. Laat je baas weten wat je gedaan hebt, hoe je dat gedaan hebt en waarom je dat zo gedaan hebt. Schrijf zelf documentatie bij andermans code. Hierdoor snap je die code beter, en is het makkelijker voor andere medewerkers om die code ook te snappen. Op een gegeven moment gaat het opvallen dat jij je zaakjes WEL voor elkaar hebt, en dan wordt het ineens interessant om naar jouw manier van werken te kijken...

En heb geduld...

[Chilly_Willy]

Ik maak dit dus nu mee van de andere kant. Ik was eerst externe ontwikkelaar en overgestapt naar de klant zeg maar. Nu krijg ik dus de code vaak opgeleverd en dat is vaak ook niet goed. We leveren nu ook onze code en web standaarden aan waar aan voldaan moet worden, en we gaan hier ook op controleren. Het gebruikt van standaarden is essentieel om enigsinds te kunnen garanderen dat het is meerdere browsers werkt, nu en in de toekomst en draaid op de volgende versies van de applicatieserver of iig makkelijk te migreren is.

Maar iid is het vaak zo dat bij klanten geen eigen ICT club is die de software opgeleverd krijgt en daarna in beheer neemt en zelf de aanpassingen moet doen. Dit gebeurd vaak via een SLA met de leverancier.

[Slagroom]

Je moet voor je zelf beginnen, en het personeel dat je aanneemt dwingen jouw stijl te gebruiken...

Waar je wel rekening mee moet houden dat je niet te arrogant moet gaan doen. Anders heeft iedereen binnen de kortste keren een hekel aan jou. Over het algemeen houden mensen er niet van om op hun fouten gewezen te worden, vooral de stok vaste senior ICT'ers en de loodgieters die in een NTI cursus van een half jaar hebben geleerd hoe ze moeten programmeren.

[Verwijderd]

Verwijderd schreef op woensdag 17 augustus 2005 @ 15:49:
Ieder project is anders, en vraagt een andere aanpak

Als het goed is niet

[Alarmnummer]

Verwijderd schreef op woensdag 17 augustus 2005 @ 16:44:
[...]
Als het goed is niet

In de praktijk zie je wel dat er grote verschillen zijn met de manier van aanpak. Voor kleine projecten kan het vaak niet uit om het helemaal op de officiele manier te doen.. dus tja.. er zit wel degelijk verschil tussen de manier van aanpak mbt de omvang van de klus.

En voor de TS: nogmaals.. als ik het echt niet kon fixen, en ik zou er ongelukkig van worden, dan zou ik echt uitkijken naar iets anders. Ik werk bij een klein bedrijf en in het begin was het voor mij ook een enorme cultuur omschakeling (daarvoor heb ik een jaar of wat bij de Rijks Universiteit Groningen gewerkt: lees formeel en weinig druk). Maar we beginnen steeds meer naar elkaar toe te groeien.. ik ben/was iets te onpraktisch.. en ik vond ze soms iets te praktisch. Maar we leren duidelijk van elkaar.. we groeien (mede door mij) in de techniek.. maar ik ben nu een stuk commercieeler ingesteld dan helemaal in het begin. Ik heb wel het voordeel dat ik bij een klein bedrijf werk en daardoor alles ook een stuk minder formeel is, en dat we aan het groeien zijn.. dus er zijn meerdere oren voor mijn ideeen en suggesties.

[ Voor 7% gewijzigd door Alarmnummer op 17-08-2005 17:01 ]

[Verwijderd]

Verwijderd schreef op woensdag 17 augustus 2005 @ 13:39:
Ik ben in de veronderstelling dat mijn manier van werken niet alleen 'goed' is, maar ook dichtbij de ideale manier van werken ligt.

Dat is nogal een grote veronderstelling. Hoe goed je ook geschoold bent en hoe goed je kennis ook is, je zult merken dat er nog veel meer is om te leren. Hoe meer je leert, hoe meer je zult beseffen dat je kennis beperkt is.

Blijf dus open staan om te leren, en beperk je daarbij niet tot het puur technische maar ook in de menselijke, procedurele en bedrijfsmatige kanten van het ontwikkelen van software.

Maar nu mijn probleem. ik kom bij een bedrijf dat er dus een absolute zooi van maakt.
[...]

Ik denk dat je je moet beperken tot hoe jij er zelf bij voelt. Vanuit je posts in deze thread ben je een techneut in hart en nieren, die houdt van mooie oplossingen en enigszins perfectionalistisch is. Dat maakt je tot een waardevolle medewerker voor een bedrijf dat jouw kennis echt aanspreekt, maar het geeft je ook een enorme blinde vlek: ICT is voor bedrijven een middel tot een doel en niet een doel op zich. ICT moet in eerste instantie dus geld opleveren, en dat is iets wat je in je werk moet accepteren. Zo niet, dan zal je overal ongelukkig worden.

To the point: wie heeft deze ervaring ook en hoe ga je ermee om? Ik kan zo dus niet werken (wijzigen in die zooi aanmaken, functionaliteit toevoegen) dus ik wordt langzaam gek. Maar hoe verkoop je je baas dat kwaliteit belangrijk is. Ik werk er nog maar net, dus hoe geloofwaardig ben ik: ze verdienden zonder mij al jaren geld, en nu zeg ik dat het niet goed is.

Eerlijk gezegd denk ik dat je op zoek moet naar een bedrijf waarbij je kennis veel meer zal worden aangesproken, en ik denk dat je ook zelf moet erkennen dat je te weinig kritisch hebt gekeken naar waar je gesolliciteerd hebt, want je had waarschijnlijk vooraf al kunnen bedenken dat de cultuur van dit bedrijf niet bij jou past. Zoek eerder naar grotere bedrijven, liefst met een eigen R & D afdeling, die diep investeert in kennis op het gebied wat jij interessant vindt.

Hoe ga je om met collega's die dit dus niet belangrijk vinden, en dan met name collega's die er een zooitje van maken (geen commentaar, geen nette code) maar daar zelf wel bij varen.

Laatst was nog een topic over het herschrijven van brakke code van collega's en dat topic is hierboven al ergens genoemd. Neem dat nog maar eens goed door, je zult er veel van kunnen leren.

Lange post, maar ik hoop toch op reacties, want ik vind het maar een lastige situatie.

Veel succes! Maak het jezelf makkelijker door een werkgever te zoeken die beter bij je past, maar probeer wel realistisch te zijn en te accepteren dat ICT in bedrijven om geld draait, en niet om mooie technologie.

[Gomez12]

Verwijderd schreef op woensdag 17 augustus 2005 @ 14:56:
[...]


Nee ik ben zeker niet arrogant. Maar ik snap wat je zegt, maar als je gezien hebt wat ik heb gezien, zou je het zeker begrijpen. Ze verdienen geld omdat er geen klant is die de code ziet, die zien alleen het resultaat.

Voorbeeld:

code:

xml = "<?xml version=\"1.0\" encoding=\"utf-8\">";
xml = Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(
Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(origineel, "ß", ß)"é", ž) ' Enz enz enz voor alle 'problematische' karakters
Response.Write(xml);

Dat was de code, ik kom vers van de school, en ik weet dat er uitgebreide XML api's zijn. Dus begin ik met:

code:

set xmlDoc = server.CreateObject("MSXML2.DOMDocument.4.0")
set piXML = xmlDoc.createProcessingInstruction("xml", "version='1.0' encoding='utf-8'")
xmlDoc.appendChild(piXML)

PS: de code heb ik ff snel ter illustratie neergezet, duszal vast wel fouten bevatten, maar t gaat ff om de andere insteek om iets tedoen, en problemen op te lossen, cq te voorkomen.

Dit vind ik wel een goed voorbeeldje van code, want hoelang bestaat de code al en hoelang bestaan de api's al?

Want wat ik in de praktijk vaak zie is dat een bedrijf een stuk code heeft, dit x jaar onderhoud en dat er dan een heleboel nieuwe mensen komen die vinden dat de code zo slecht is. Alleen is een groot gedeelte al van x jaar oud ( en toen bestonden de standaarden etc nog niet allemaal ) en als het werkt dan werkt het.

Of je moet even als bedrijf voor de lol ( want de klant ziet er niets van dus weigert deze voor dit soort dingen te betalen ) elk jaar een complete rewrite gaan doen, waardoor elke programmeur kan leren hoe de nieuwste technieken te gebruiken of je moet accepteren dat er veel "foute" code in staat en dat er nou eenmaal veel mensen zijn die al jaren op de "foute" manier werken ( "Fout" maar het werkt wel ) en die niet snel het nut inzien van overstappen van iets wat werkt naar iets anders wat ook werkt, maar wat een boel tijd en geld kost.

Vb: wij hebben hier een software pakket draaien wat al 15 jaar oud is ( wordt nog steeds doorontwikkeld ) maar waar totaal geen documentatie van bestaat. Het bedrijf waarvan het software pakket is weet dat het geen goede situatie is, maar nu eventjes een documentatie schrijven zou volgens hun eigen schatting 1,5 jaar kosten tegen heel erg weinig opbrengsten. Dit is dus gewoon te duur en "komt ooit nog wel eens". Dit is gewoon de praktijk.
Wat nu standaard is kan over 2 jaar al compleet verouderd en "fout" zijn, ga jij dan al jouw code herschrijven naar de dan geldende standaard???

[DDemolition]

Dit voorbeeld heb ik ook, altans niet in programmeer taal oid.
Dit zie ik bij een klant al, waarvan ik de server beheer die bv. van de mailboxen al een grote t*ringzooi maakt. Dit resulteerd uit verschillende mailboxen van +- 900mb waarvan de gebruiker niet eens weer wat er ook al weer in staat .
De bestands structuur is bij sommige ook een puinzooi met bv. dan wel hoofdlettergebruik en dan weer niet.
Tja, wat doe je er aan? iedereen achterna lopen en de mappen hernoemen? Of gewoon zorgen dat je eigen dagelijkse dingen 'schoon' zijn lijkt mij de makkelijkste oplossing.

[ Voor 2% gewijzigd door DDemolition op 17-08-2005 19:49 . Reden: typo ]

[MSalters]

Het klassieke boek op dit gebeid is natuurlijk "Refactoring", en daarin staat ook hoe je het moet verkopen. De uiteindelijke reden is business. Als het niet goedkoper is om het op jouw manier te doen, dan is jouw manier niet goed. Maak dus aannemelijk dat jouw manier goedkoper is. Wat is de prijs van het fixen van een bug bij jullie?

[Verwijderd]

Maar wat levert die refactoring op aan tijd, geld, resultaat en wat moet er daarin worden geinvesteerd. Die factoren zijn stuk voor stuk lastig in te schatten bij voornamelijk grote projecten.

Je zit dus al met een situatie waar je mensen moet gaan overtuigen van een betere situatie, dan nog een situatie dat je argumenten en feiten moet hebben. Die feiten die moet je met elkaar verzamelen en evalueren, maar voordat je daar aan toekomt moet je al tijd beschikbaar krijgen voor het analyseren (zie overtuigen weer). Dan hebben we nog het standaard gedrag waarbij beslissingmakers zich indekken en zo weinig mogelijk risico durven te nemen en het cirkeltje is rond. Want je kunt puur komen met schattingen op basis van worse case - best case en wie wil dat risico met grote projecten nog nemen.

Eventueel kun je nog wat regelen om in samenwerking met de klant een shared risk traject aan te gaan, maar wat levert het die klant op, .. daar gaan we weer met analyseren.

Verschrikkelijk moeilijk zulke situaties.

[ Voor 20% gewijzigd door Verwijderd op 17-08-2005 20:33 ]

[whoami]

Verwijderd schreef op woensdag 17 augustus 2005 @ 20:30:
Maar wat levert die refactoring op aan tijd, geld, resultaat en wat moet er daarin worden geinvesteerd. Die factoren zijn stuk voor stuk lastig in te schatten bij voornamelijk grote projecten.

Tja, refactoren doe je in kleine stapjes, en dat hoeft niet altijd veel geld / tijd te kosten.
Refactoren moet je natuurlijk ook niet doen, als je tegen een deadline zit te werken, of als het belangrijker is om bepaalde functionaliteit eerst te implementeren.
Je hoeft ook niet meteen het hele project op de schop te nemen. Een kleine wijziging, zoals het veranderen van een method-name, kan de code al heel wat duidelijker maken.

[MrBarBarian]

TS klinkt als een typische schoolverlater: mooie gedachtes die vooral in theorie bestaan..

De praktijk is nou eenmaal anders, daar moeten centen worden verdient.. hoe dat gebeurt is veelal van ondergeschikt belang.. Begrijp me niet verkeerd, ze zijn er wel, bedrijven die nette software schrijven! Volgens mij zijn dit doorgaans wat kleinere bedrijven waar ontwikkelaars zelf e.a. in te brengen hebben. Maar daar staat weer wel tegenover dat het hard werken is (incl privetijd dus).. want die centen moeten uiteraard nogsteeds worden verdient!

[Verwijderd]

MrBarBarian schreef op woensdag 17 augustus 2005 @ 21:38:
TS klinkt als een typische schoolverlater: mooie gedachtes die vooral in theorie bestaan..

Hij heeft wel een punt. Bedrijven die totaal chaotisch werken rijden zichzelf later alleen maar in de wielen. Het is triest, DIEP TRIEST dat bedrijven nog steeds op deze manier redeneren. Geen zorg voor kwaliteit, als er maar snel geld uit de klanten kan worden gezogen. Vroeger dacht men ook zo over huizen bouwen en over bruggen bouwen. Gelukkig is dat een echt ambacht geworden en halen nog waar weinig het in hun hoofd om een grote(!) brug te bouwen zonder uitvoerige designs en testen.

De software industrie is grotendeels nog erg onvolwassen. De TS is niet zomaar een 'schoolverlatertje" maar iemand met visie die rebelleert tegen de huidige luie en niet nadenkende medemens. Hulde!

Ik voorspel dat men over 100 jaar met ongeloof zal reageren als men sommige reacties hier leest. Wat dat betreft doet MrBarBarian zijn naam alle eer aan!

En ja, ik heb idd eerder gezegd dat je niet bestaande code moet gaan aanpassen om het mooier te maken, maar daar mee bedoel ik niet dat dat aanpassen per definitie slecht is, maar dat je er grote onrust op de werkvloer mee veroorzaakt als je dat zomaar doet. Voornamelijk voor nieuwe code is het zowieso goed (voor iedereen) om tenminste een beetje structuur en netheid toe te passen.

Begrijp me niet verkeerd, ze zijn er wel, bedrijven die nette software schrijven! Volgens mij zijn dit doorgaans wat kleinere bedrijven waar ontwikkelaars zelf e.a. in te brengen hebben.

Hangt er sterk vanaf wat de instelling van die paar progammeurs in kleine bedrijven is. Ik heb zelf in een klein bedrijf gewerkt en daar waren de 2 andere programmeurs chaoten. Als ik dan aankwam met de stelling dat je netjes moest werken werd dat altijd afgewimpeld door te zeggen dat netjes werken alleen belangrijk is in grote organisaties maar dat wij klein genoeg waren om alles te overzien, ook zonder designs, regels, en test procedures.

Tegenwoordig participeer ik een mini bedrijfje dat ik mede opgezet heb, en er zijn inderdaad weer mensen die vinden dat we te klein zijn om een noodzaak te hebben voor regels. Ik zelf denk daar anders over. Natuurlijk is inkomen voor mij ook belangrijk, des te meer omdat dat in mijn geval direct van de winst afhangt. Hebben we een slechte maand dan is het bedrag wat ik mag bijschrijven op mijn rekening lager dan wat een 16 jarige scholier in a'dam west bij de AH verdient.

Maar ik zie ook dat we competatief moeten zijn op de langere termijn. Goed, we kunnen een voordeel halen tov van de concurentie door nu brakke code te gaan schrijven en snel met nieuwe features te komen. Maar als dan over 6 maanden de klanten gaan weglopen omdat we allemaal vage bugs hebben die we niet snel kunnen fixen, wat dan? Wat als we over 12 maanden amper meer grote dingen kunnen toevoegen omdat de (niet bestaande) architectuur uit zijn voegen barst en elke developper hoofdpijn krijgt als hij ook maar het kleinste dingetje moet toevoegen? Op zo'n moment kun je niet meer competatief zijn en blijf je na een aanvankelijk snelle start in de marge rommelen.

Zoals eerder gezegd, het blijft moeilijk om een evenwicht te vinden. Als techneut zijnde wil ik stiekum eigenlijk code tot in de perfectie opleveren, maar dan verzand je soms in details die idd amper wat opleveren.

Moeilijk moeilijk moeilijk...

[prototype]

Henk, je bent idd de man, dankzij je post hoef ik eigenlijk niet meer te reageren
Zelf herken ik de scenario maar al te goed dat slechte code gerechtvaardigd wordt. Redenen die dan aangevoerd worden is dat het op tijd af moet zijn en dat het toch maar een keer gebruikt zal worden 'dus het is geoorloofd'. Niet geheel onredelijk, maar mijn eigen ervaring is dat iets ZELDEN maar 1x gebruikt wordt als het goed geschreven is.
Zo is het me in het verleden wel eens voorgekomen dat een collega 3x binnen een bepaalde termijn een soortgelijk component TOTAAL OPNIEUW moest bouwen, omdat de vorige te gammel (lees: specifiek) in elkaar staken om het opnieuw te gebruiken; iets dat in mijn mening met abstractie en compositie vele malen keren had kunnen worden voorkomen.
Toen ik dan ook met dit idee kwam en ook zei dat dit op den duur efficienter / goedkoper zou zijn, was men geheel oor, maar daar bleef het alleen bij... Ik ben dan ook om deze reden al meerdere malen weggegaan bij dit soort bedrijfjes, omdat ik zelf van mening ben dat het anders MOET. Als een bedrijf je simpelweg aan het touwtje houdt met de notie dat men er wel eens ooit naar zal luisteren, maar dat deze dag tussen nu en nooit plaats kan vinden... tsjah, waar blijft je eigen inbreng dan. Dit gebeurt vaak bij kleine bedrijfjes heb ik gemerkt (die moeten w.s. ook het dubbeltje wat vaker draaien), en in veel mindere mate bij grote bedrijven, waarbij men tenminste verder in de toekomst kijkt dan 'lunchtijd'.

[MrBarBarian]

Nee hoor, begrijp me niet verkeerd; ik geloof absoluut dat een investering in techniek/methodiek uiteindelijk terug zal betalen. Ik programmeer niet meer, maar heb een hoop tijd gestoken in het goed leren programmeren in J2EE. Dat was bij zo'n klein bedrijf waar je als programmeur nog wat in te brengen had Vervolgens werdt ik tijdelijk op een project gezet (asp overigens) waar er heel weinig aandacht was besteed aan methodieken.. Het aanpassen van die applicatie nam veeeel meer tijd in beslag dankzij de slechte code.. Om eens een voorbeeld te noemen..

Het is vooral in het voordeel van de ontwikkelaar zelf om nette code te schijven. Nette code is beter te onderhouden en doorgaans flexibeler.. dus heeft je applicatie meer potentieel dan een slecht geschreven applicatie.. Maar leg dat maar eens aan de eindgebruiker uit:

"mijn applicatie is 2x zo duur, maar wel flexibeler voor de toekomst omdat hij volgens methodiek a, b en c is geschreven"... Doorgaans boeit een klant dat helemaal niet, die wil een functionerende applicatie voor zo min mogelijk geldt.. (uiteraard uitzonderingen daar gelaten)

[Alarmnummer]

Verwijderd schreef op woensdag 17 augustus 2005 @ 22:23:
[...]
Hij heeft wel een punt. Bedrijven die totaal chaotisch werken rijden zichzelf later alleen maar in de wielen. Het is triest, DIEP TRIEST dat bedrijven nog steeds op deze manier redeneren.

Het is niet altijd het bedrijf die zo redeneert, maar de klant kan hier soms ook de oorzaak van zijn. Het is lastig om een klant uit te leggen dat een betere structuur misschien nu een paar centen extra kost en dat quick-fixes het systeem misschien tijdelijk uitbreid maar op lange termijn tot een onbeheersbaar geheel maken.

Een architect (van huizen) kan aan een klant veel beter duidelijk maken wat de gevolgen zijn van een bepaalde aanpak. Maar software ontwikkeling is extreem abstract en zal door maar een fractie van de mensen begrepen worden.

En dan kan je als bedrijf nog wel zo laag en hoog springen als je wilt, maar uiteindelijk betaald de klant de rekeningen. En als de klant iets kiest waarbij je het niet helemaal eens bent... de klant betaald de rekeningen.. idealisme niet.

De software industrie is grotendeels nog erg onvolwassen. De TS is niet zomaar een 'schoolverlatertje" maar iemand met visie die rebelleert tegen de huidige luie en niet nadenkende medemens. Hulde!

Mwuah.. visie vind ik een groot woord. Het is meer jonge idealisme dat nog niet kapot geslagen is door de harde werkelijkheid.

Ik voorspel dat men over 100 jaar met ongeloof zal reageren als men sommige reacties hier leest. Wat dat betreft doet MrBarBarian zijn naam alle eer aan!

En ja, ik heb idd eerder gezegd dat je niet bestaande code moet gaan aanpassen om het mooier te maken, maar daar mee bedoel ik niet dat dat aanpassen per definitie slecht is, maar dat je er grote onrust op de werkvloer mee veroorzaakt als je dat zomaar doet. Voornamelijk voor nieuwe code is het zowieso goed (voor iedereen) om tenminste een beetje structuur en netheid toe te passen.

Als een bedrijf het accepteert dat mensen zo maar in de code gaan wroeten... misschien. Maar mijn 'idealistisch' gedachtengang is intussen in de praktijk ook flink in elkaar gerost. Neem bv java.. java platform onafhankelijk.. kan makkelijk onder linux als onder windows draaien... in theorie misschien.. maar in de praktijk kom je altijd stomme dingen tegen.. en soms is het niet eens iet wat je onder controle hebt! Iedere wijziging van dingen die werken, die leveren vaak problemen op.. wij noemen het de 'magic factor'.. de oorzaak is vaak klein... maar de kosten groot.

Concreet voorbeeld:jdbc is in principe database onafhankelijk... je kan zo eenvoudig een ms sql server vervangen door een postgresql db... maar je komt gewoon stomme dingen tegen.. key generators.. brakke gui`s.. brakke database`s.. brakke rechten systemen.. en alles zal uiteindelijk verklaard kunnen worden. Maar simpele dingen op omgevingen waarin je geen professional bent, die herbergen een schatkist met adders + gras + landmijnen en borstenvallen. Je kunt dan nog wel zo idealistisch zijn... maar de praktijk is dat het tijd kost... en tijd kost gewoon geld.

Ik ben trouwens ook (nog steeds) geil op goed geschreven software hoor Ik ben bezig met een aantal libraries waarin ik al mijn kennis/plezier kan uiten en die zich niets aantrekken van alle dagelijkse problemen.

Maar ik zie ook dat we competatief moeten zijn op de langere termijn. Goed, we kunnen een voordeel halen tov van de concurentie door nu brakke code te gaan schrijven en snel met nieuwe features te komen. Maar als dan over 6 maanden de klanten gaan weglopen omdat we allemaal vage bugs hebben die we niet snel kunnen fixen, wat dan?

Tja... ik heb als developer het gevoel in een totaal andere wereld te leven dan de klant. Dingen die ik extreem belangrijk vind.. die vind een klant totaal niet interessant (en andersom). Ik ben echt zo blij met goed geschreven software, maar het zal een klant echt totaal aan zijn kont roesten. Techniek is voor een klant echt totale bijzaak.. tenzij je werkt voor klanten die deze technische kwaliteit kunnen waarderen, denk ik niet dat je ooit op zult kunnen boxen tegen andere clubs.

Wat als we over 12 maanden amper meer grote dingen kunnen toevoegen omdat de (niet bestaande) architectuur uit zijn voegen barst en elke developper hoofdpijn krijgt als hij ook maar het kleinste dingetje moet toevoegen? Op zo'n moment kun je niet meer competatief zijn en blijf je na een aanvankelijk snelle start in de marge rommelen.

Tja.. (nog een keer)... je moet niet vergeten dat veel andere bedrijven nog veel grote crap maken dan jij ooit zult kunnen maken in je stoutste dromen.. zij redden het ook.. Techniek is leuk (ik vind het persoonlijk het enigste dat leuk is), maar de praktijk is dat de techniek totaal oninteressant is. Alleen echt clubs die in de techniek zitten, kunnen deze moeite waarderen.. maar verder.. ik denk niet dat techniek en goed afgewerkte producten kunnen concureren met goeie sales (hoe pijnlijk dit ook klinkt). Je zult uiteraard een naam hoog moeten houden... als je bekend staat als prutser tja.. dan zal het wel ophouden.. maar zo lang je redelijk werkende software maakt.. en goeie sales mensen hebt... dan heb je (vanuit commercieel oogpunt) een hogere kans om te slagen dan als het technisch allemaal uitstekend in orde is (imho).

Zoals eerder gezegd, het blijft moeilijk om een evenwicht te vinden. Als techneut zijnde wil ik stiekum eigenlijk code tot in de perfectie opleveren, maar dan verzand je soms in details die idd amper wat opleveren.

Zo word ik ook wel eens beschreven bij het bedrijf waar ik werk. Gelukkig geven ze me de ruimte om dit soort niet-direct-geld-opbrengde-gedrag te uiten... Maar ik ben zelf in ieder geval al redelijk gedesillusioneerd in technisch perfectionisme en de directe winst die je eruit kunt halen. Uiteraard zul je als je technisch goed doorontwikkeld, ook de betere klanten naar binnen kunnen halen. Maar sales zorgt daarvoor... techniek maak het alleen maar waar..

Het is dat ik techniek-geil ben... maar anders zou ik zeggen dat goeie sales belangrijker is dan goeie techniek.

[ Voor 15% gewijzigd door Alarmnummer op 17-08-2005 23:14 ]

[Croga]

Verwijderd schreef op woensdag 17 augustus 2005 @ 16:44:
Als het goed is niet

Als het goed is wel.....

Een project om een eenmalige mail-merge database op te zetten zal heel anders aangepakt moeten worden dan een project om een ERP systeem te customizen en implementeren voor een bedrijf van 100000 werknemers....

In het eerste geval is quick'n'dirty zonder meer toegestaan. Als je daarmee de develop-tijd kunt halveren levert het alleen maar geld op, en nazorg zal er toch niet zijn. In het tweede geval moet je daar niet mee aankomen aangezien bij de eerste organisatie wijziging het hele pakket instort.

Ieder project is anders. Iedere klant is anders. Iedere afdeling is anders. Iedere gebruiker is anders. Als je niet in staat bent je manier van werken op de omgeving af te stemmen kun je beter een andere baan zoeken....

Verwijderd schreef op woensdag 17 augustus 2005 @ 22:23:
Hij heeft wel een punt. Bedrijven die totaal chaotisch werken rijden zichzelf later alleen maar in de wielen. Het is triest, DIEP TRIEST dat bedrijven nog steeds op deze manier redeneren. Geen zorg voor kwaliteit, als er maar snel geld uit de klanten kan worden gezogen.

Als de klant aan 2 leveranciers offerte vraagt. Jij bent er één van en staat er op om het hele project zo uitgebreid mogelijk te doen. Inclusief zo uitgebreid mogelijke specificaties, documentatie, project management, versie beheer en eXtreme Programming als basis. De andere aanbieder focust op wat de klant wil en past zijn manier van werken daar op aan. Daardoor kan de andere aanbieder met minder inspanning óók datgene leveren wat de klant wil. Dat heeft niets te maken met "geld uit de klant zuigen", dat heeft te maken met goed weten dat ook die klant tot doel heeft om geld te verdienen en daar kun je als leverancier aan meehelpen door hem niet te laten betalen voor zaken waar hij niet om vraagt.....

Mischien vindt je het diep triest. Maar ondertussen zul jij naar de sociale dienst moeten, terwijl je concurent na afronding van het project lekker naar Mauritius op vakantie kan.

Zoals al gezegd: Ieder project is anders. Er zijn nagenoeg geen projecten te vinden op deze wereld waar "De ideale manier van werken" ook daadwerkelijk de beste is. Er zijn altijd punten waar de klant graag meer aandacht wil, en punten waar minder aandacht nodig is....

[Verwijderd]

Ik kan mij bijna geheel vinden in de TS. Vooral bij de grotere IT bedrijven wordt er door de juniors enorm veel geprutst, zonder dat dit door de seniors wordt opgepakt, domweg omdat de seniors niet de mensen zijn die bewezen hebben het te kunnen ofzo, maar gewoon juniors die toevallig 1 of 2 jaar in dienst zijn geweest.

Daarnaast wordt e.e.a. in dit topic gepresenteerd alsof er maar 2 opties zijn, namelijk snel en geprutst of langzaam en goed.

Dit zal best voor een aantal projecten opgaan, maar in mijn ervaring is er ook nog optie 3, namelijk goed en efficient.

Hierboven noemt iemand als voorbeeld een dialoogvenster (1 uur quick'n'dirty of 3 uur goed). In mijn ervaring hoeft dit niet zo te zijn. Stel je hebt een app met 10 praktisch identieke dialoogvensters, waar toch kleine verschillen in zitten. Iemand die het goed aanpakt gaat dit vangen in classes en komt uiteindelijk over de brug met een generiek dialoogscherm. Resultaat.. de quick'n'dirty prutser moet 10 maal een uur werken voor 10 dialoogjes, diegene die het goed aanpakt heeft in 5 uur een generieke dialoog gemaakt.

Daarbij is de kans dat code reusable is (bv. zelfs in andere projecten) bij een project wat goed opgezet is aanmerkelijk groter.

Dat is dan ook het kortzichtige van het management zoals justmental het voorstaat. Ja op de korte termijn en per project afzonderlijk bekeken kun je de visie 'niet miepen over mooie code, het moet werken, en klant betaalt niet voor mooie code' prima handhaven. Zodra je echter meer dan 1 project hebt lopen, wordt het al interessant om het structureler aan te pakken.

Neem als voorbeeld een bedrijf wat websites bouwt. Als die voor al haar klanten 'quick'n'dirty' een CMS in elkaar draait, zal het allemaal werken en is het mogelijk zelfs zo dat de klanten het financieel wel trekken. Echter als men 1 keer een goed CMS ontwikkeld, kan men daarna volstaan met het verkopen van dat CMS aan een klant + een design voor de website. Men zou dus grof tijd verliezen op het 1e project, maar dat daarna dubbel en dwars terugverdienen.

In realiteit is het natuurlijk allemaal niet zo zwart wit, maar ik wilde iig. aangeven dat iets goed doen helemaal niet perse hoeft te betekenen dat het langer duurt.

Maar goed, eerlijk is eerlijk, soms is de quick'n'dirty fix domweg de beste keuze.

[Verwijderd]

MrBarBarian schreef op woensdag 17 augustus 2005 @ 22:39:
"mijn applicatie is 2x zo duur, maar wel flexibeler voor de toekomst omdat hij volgens methodiek a, b en c is geschreven"... Doorgaans boeit een klant dat helemaal niet, die wil een functionerende applicatie voor zo min mogelijk geldt..

Ik begrijp volledig wat je bedoeld, maar ga nog eens terug naar die brug. De gebruikers van zo'n brug boeit het ook helemaal niet welke aanpakken en architectuur er is toegepast, welke materialen er zijn gebruikt en aan welke test methodiek het geheel is onderworpen. Een gebruiker wil alleen naar de overkant voor zo min mogelijk geld.

Gelukkig is daar dan een overheid die via domain experts het ontwerp en de bouw hiervan reguleert. Dit geldt zelfs voor kleinere bruggen over bijvoorbeeld een zijgracht. Voor het overgrote deel van de consumenten produkten geldt dit ook. Hiervoor gelden regels mbt tot duurzaamheid en betrouwbaarheid. Een individuele consument zal ook hier niet beseffen welke eisen hij precies moet stellen en wil daarom eigenlijk ook weer gewoon dat het werkt voor zo min mogelijk geld. Pas als het fout gaat is de consument boos. In het geval van echt falen is er dan een aansprakelijkheid, waar mensen dan ook van uit gaan.

Je ziet dat software beiden eigenschappen niet heeft. Er zijn geen kwaliteits eisen, ondanks het feit dat de gehele maatschappij steeds meer van computers en software afhankelijk is. Er is echter ook geen aansprakelijkheid. Als producent ben ik daar aan de ene kant wel blij mee (natuurlijk), maar als ik er als prive persoon even wat langer over nadenk dat is dat eigenlijk een hele slechte zaak. Zonder deze aansprakelijkheid hebben bedrijven weinig stimulans om echt goede stabiele software te bouwen. Iets snel op de markt zetten en later wat patches sturen (als dat al gebeurd) is dan ook schering en inslag. Het is iniedergeval een teken dat de software industrie een ad hoc industrie is die nog op weg is naar volwassenheid.

Als de klant aan 2 leveranciers offerte vraagt. Jij bent er één van en staat er op om het hele project zo uitgebreid mogelijk te doen. Inclusief zo uitgebreid mogelijke specificaties, documentatie, project management, versie beheer en eXtreme Programming als basis. De andere aanbieder focust op wat de klant wil en past zijn manier van werken daar op aan.

Het valt me op dat bijna iedereen hier (maar ook dikwijls in andere topics) altijd uit gaat van -de- klant die software op maat besteld bij jou. Is er dan helemaal niemand hier actief in de markt waar je gewoon algemene software maakt die je gewoon per licentie verkoopt? Dus gewoon dingen als een game, een office pakket, een web application die je zelf draaid, etc etc...
In dat geval heb je helemaal geen "-de- klant", maar gewoon een hele markt met klanten voor wie je van te voren iets gaat maken in de hoop dat het goed zal gaan verkopen.

Om die brug er dan maar weer bij te halen. Op het moment dat iemand vraagt aan jou om op zijn prive terein een bruggetje te bouwen en jij neemt de eisen persoonlijk door, dan is dit natuurlijk een hele andere situatie dan wanneer je een openbare brug bouwt (en daar eventueel tol voor gaat vragen.) In het eerste geval is het inderdaad meer eigen risico voor de klant.Wil ie quick 'n dirty dan kan ie dat krijgen. Jammer als dat ding een keertje instort en hij zijn been breekt ofzo.

[ Voor 27% gewijzigd door Verwijderd op 17-08-2005 23:43 ]

[alienfruit]

Neem als voorbeeld een bedrijf wat websites bouwt. Als die voor al haar klanten 'quick'n'dirty' een CMS in elkaar draait, zal het allemaal werken en is het mogelijk zelfs zo dat de klanten het financieel wel trekken. Echter als men 1 keer een goed CMS ontwikkeld, kan men daarna volstaan met het verkopen van dat CMS aan een klant + een design voor de website. Men zou dus grof tijd verliezen op het 1e project, maar dat daarna dubbel en dwars terugverdienen.

Het ligt er natuurlijk helemaal aan hoe je dit wilt gaan verrekenen, als je voor elke klant gewoon een eigen cms maakt, op uurtje-factuurtje. Zou je meer kunnen verdienen dan wanneer je eenmaal een CMS maakt en vervolgens alleen implementatie kosten vraagt, minder uren dus minder opbrengsten. Als je deze CMS' gewoon laat maken door de stagair, heb je kosten zo terug verdiend. De paar honderd per maand die je voor hem betaald. Zo'n stagair mag er van mij zolang overdoen als hij wilt, hij kost toch geen drol.

[ Voor 7% gewijzigd door alienfruit op 17-08-2005 23:39 ]

[Verwijderd]

alienfruit schreef op woensdag 17 augustus 2005 @ 23:35:
Het ligt er natuurlijk helemaal aan hoe je dit wilt gaan verrekenen, als je voor elke klant gewoon een eigen cms maakt, op uurtje-factuurtje. Zou je meer kunnen verdienen dan wanneer je eenmaal een CMS maakt en vervolgens alleen implementatie kosten vraagt, minder uren dus minder opbrengsten. Als je deze CMS' gewoon laat maken door de stagair, heb je kosten zo terug verdiend. De paar honderd per maand die je voor hem betaald.

Wederom een voorbeeld van kortzichtig denken. Uren rechtstreeks in facturen omrekenen.

Stel het maken van een 'ad-hoc CMS' kost 1000 euro en het maken van een 'generiek CMS' kost 10.000 euro. Stel nu eens we verkopen beide 30 CMS-en.

Zeg dat jij een winstmarge van 20% aanhoud. Dan vraag je dus 1200 euro voor je CMS. Jij hebt dus uiteindelijk 30*200 euro = 6000 euro verdiend.

Goed.. ik wil met jou concurreren, dus reken ik hetzelfde voor mijn CMS. Ik verkoop dus 30 CMS-sen voor 30*1200 = 36.000. In totaal heb ik 10.000 euro kosten gehad, dus ik heb 26.000 verdiend, oftewel 20.000 meer dan jij.

Als we nu een prijzenslag gaan houden, ben jij zo ongeveer per direct dood, omdat je altijd minimaal 1000 euro voor je CMS zult moeten vragen. Als ik er 30 verkoop (van het generieke verhaal) zou ik minimaal € 333,- voor een CMS moeten vragen.

Je verdiend dus meer, kunt goedkoper leveren en levert betere kwaliteit. Lijkt mij duidelijk.

Dit nog even los van het verhaal dat de waarschijnlijkheid dat mijn klanten meer tevreden zullen zijn, erg groot is. Mijn ervaring met ad-hoc projecten (en zeker bij een CMS) is dat je jezelf vroeger of later tegenkomt. Onverklaarbare bugs, on-debuggable code of het is schier onmogelijk uitbreidingen te maken.

[ Voor 40% gewijzigd door Verwijderd op 17-08-2005 23:52 ]

[Verwijderd]

alienfruit schreef op woensdag 17 augustus 2005 @ 23:35:
[...]
Zo'n stagair mag er van mij zolang overdoen als hij wilt, hij kost toch geen drol.

Vanwege het gebrek aan stage plaatsen kun je een stagair ook voor niets laten werken. Altijd wel eentje die het toch aanneemt.

Mijn ervaring met stagiares is echter matig. Iedereen moet altijd eerst op stoom komen. In de praktijk blijkt dat de meeste stagiares net een beetje op gang komen als hun stage periode er al weer opzit. Dit betekent niet dat de stagiare opzich slechter is dan iemand die afgestudeerd is, maar dat ze per definitie kort in het bedrijf zijn. Net als ze van alles op de hoogte zijn en hun weg in de source weten te vinden gaan ze al weer weg, komt er weer een nieuw iemand die zich weer helemaal moet inwerken en net als die dan een beetje goede bijdragen gaat leveren moet ie ook alweer weg, ad infinium...

[ Voor 49% gewijzigd door Verwijderd op 17-08-2005 23:55 ]

[Plopeye]

MrBarBarian schreef op woensdag 17 augustus 2005 @ 21:38:
TS klinkt als een typische schoolverlater: mooie gedachtes die vooral in theorie bestaan..

De praktijk is nou eenmaal anders, daar moeten centen worden verdient.. hoe dat gebeurt is veelal van ondergeschikt belang.. Begrijp me niet verkeerd, ze zijn er wel, bedrijven die nette software schrijven! Volgens mij zijn dit doorgaans wat kleinere bedrijven waar ontwikkelaars zelf e.a. in te brengen hebben. Maar daar staat weer wel tegenover dat het hard werken is (incl privetijd dus).. want die centen moeten uiteraard nogsteeds worden verdient!

Ik zou zo zeggen: klooi lekker door dan, je komt er vanzelf achter dit is namelijk de methode korte termijn denken en hoe snel geld schrapen... op de lange termijn zal je op een punt komen dat je voor een bug komt te staan die veroorzaakt dat je eerst 25 voorgaande bugs moet repareren... zet dat dan in een slechte economische tijd en zeg maar dag softwarehuis... weer 1 failliet...

[Croga]

Verwijderd schreef op woensdag 17 augustus 2005 @ 23:24:
Het valt me op dat bijna iedereen hier (maar ook dikwijls in andere topics) altijd uit gaat van -de- klant die software op maat besteld bij jou. Is er dan helemaal niemand hier actief in de markt waar je gewoon algemene software maakt die je gewoon per licentie verkoopt? Dus gewoon dingen als een game, een office pakket, een web application die je zelf draaid, etc etc...
In dat geval heb je helemaal geen "-de- klant", maar gewoon een hele markt met klanten voor wie je van te voren iets gaat maken in de hoop dat het goed zal gaan verkopen.

In feite is "een product" bouwen niets anders dan "een applicatie voor een klant" bouwen. Het enige verschil is dat niet de eindgebruiker "de klant" is, maar de verkoop/neheer organisatie. Ofwel: Je manier van werken moet niet meer aangepast worden op de wensen/eisen van de eindgebruiker, maar op de wensen/eisen van de vekoop en beheer organisatie. De applicatie zal dan wellicht aan andere eisen moeten voldoen dan wanneer je rechtstreeks voor de eindgebruiker bouwt.

Dat betekend echter niet dat er geen geld meer verdient hoeft te worden. Hoe goedkoper jij het product kunt bouwen, des te goedkoper kan het in de markt gezet worden, en des te groter de kans dat het dus ook gekocht gaat worden door eindgebruikers.......

Er is dus geen verschil tussen bouwen voor de eindgebruiker of bouwen voor een product. In beide gevallen moet gekeken worden naar de belangen en afgewogen worden wat de beste manier van werken zal zijn....

[Verwijderd]

Verwijderd schreef op woensdag 17 augustus 2005 @ 22:23:
Hangt er sterk vanaf wat de instelling van die paar progammeurs in kleine bedrijven is. Ik heb zelf in een klein bedrijf gewerkt en daar waren de 2 andere programmeurs chaoten. Als ik dan aankwam met de stelling dat je netjes moest werken werd dat altijd afgewimpeld door te zeggen dat netjes werken alleen belangrijk is in grote organisaties maar dat wij klein genoeg waren om alles te overzien, ook zonder designs, regels, en test procedures.

Twee ontwikkelaars is een peanuts team, en dan is de drempel om te veranderen veel lager dan als je met een team zit van 20+ ontwikkelaars, en ook nog evenzoveel die in het buitenland voor je aan het werk zijn. Het is allemaal erg afhankelijk van de organisatie.

[Verwijderd]

Als je bij een commercieel bedrijf bent gaan werken moet je leren dat de enige reden dat je daar werkt is om zo veel mogelijk geld te verdienen! Als je daar niet mee kunt omgaan moet je op zoek naar een andere job bij een niet winst gedreven idealistische organisatie.

Zolang je niet aantoonbaar kunt maken dat wat jij wilt geld oplevert heb je geen enkele poot om op te staan. En ik ben het daar volledig mee eens! Mocht je het aantaanbaar gaan maken dan zou ik je adviseren om dat objectief te doen! Anders komt de klap wel erg hard aan als het daarna alsnog afgewezen wordt.

Welkom in de echte wereld!

p.s. Je kunt natuurlijk altijd part-time gaan werken en voor het andere deel gratis jouw verbeterende diensten aanbieden! Dan kost het het bedrijf / aandeelhouders niets en je kun toch je verbeter acties uitvoeren! Als je hier nee tegen zegt moet je bij jezelf eens afvragen of je niet zelf niet net zo commercieel bent als het bedrijf waar je voor werkt! Kennelijk is het het dan niet waard! Precies het punt dat ook je werkgever je vertelt!

[Plopeye]

Verwijderd schreef op donderdag 18 augustus 2005 @ 08:40:
Als je bij een commercieel bedrijf bent gaan werken moet je leren dat de enige reden dat je daar werkt is om zo veel mogelijk geld te verdienen! Als je daar niet mee kunt omgaan moet je op zoek naar een andere job bij een niet winst gedreven idealistische organisatie.

Zolang je niet aantoonbaar kunt maken dat wat jij wilt geld oplevert heb je geen enkele poot om op te staan. En ik ben het daar volledig mee eens! Mocht je het aantaanbaar gaan maken dan zou ik je adviseren om dat objectief te doen! Anders komt de klap wel erg hard aan als het daarna alsnog afgewezen wordt.

Welkom in de echte wereld!

p.s. Je kunt natuurlijk altijd part-time gaan werken en voor het andere deel gratis jouw verbeterende diensten aanbieden! Dan kost het het bedrijf / aandeelhouders niets en je kun toch je verbeter acties uitvoeren! Als je hier nee tegen zegt moet je bij jezelf eens afvragen of je niet zelf niet net zo commercieel bent als het bedrijf waar je voor werkt! Kennelijk is het het dan niet waard! Precies het punt dat ook je werkgever je vertelt!

Dit doet mij denken aan de opmerkingen van een vorige werkgever... deze dacht geld te verdienen met goedkope pc'tjes (verdienste op 1 pc was ongeveer 40 euro....) ik heb hem toen uitgelegt dat dit niet kan... ten eerste je moet 2 jaar garantie verlenen ten tweede waren er dusdanig slechte componenten uitgekozen dat het net boomerang machines waren... ze bleven maar terugkomen... (per pc ongeveer 2 uur service verlenen om uit te vissen wat er dit keer weer mis was...) kosten service verlenen: 80 euro - 40 euro verdienste = een negatief saldo van 40 euro per pc... maar ja daar is ie nu te laat achter ik werk er niet meer en hij is nagenoeg failliet... Welkom in de echte harde wereld... (gelukkig goeie contacten dus na 1x koffie drinken andere baan)
Is het zelfde principe en ik was ook zogenaamd een jonge hond die zijn mond moest houden omdat ik niet zou weten waar ik het over had... en nee het is niet mijn bedoeling om arrogant te doen...

[MrBarBarian]

Plopeye schreef op donderdag 18 augustus 2005 @ 08:12:
[...]


Ik zou zo zeggen: klooi lekker door dan, je komt er vanzelf achter dit is namelijk de methode korte termijn denken en hoe snel geld schrapen... op de lange termijn zal je op een punt komen dat je voor een bug komt te staan die veroorzaakt dat je eerst 25 voorgaande bugs moet repareren... zet dat dan in een slechte economische tijd en zeg maar dag softwarehuis... weer 1 failliet...

Waarom val je mij er nu mee aan? Ik zeg nergens dat ik het met de klooi-maar-aan instelling eens ben.. Ik zeg alleen wat ik in praktijk meemaak en meegemaakt heb..

[Plopeye]

Vb: wij hebben hier een software pakket draaien wat al 15 jaar oud is ( wordt nog steeds doorontwikkeld ) maar waar totaal geen documentatie van bestaat. Het bedrijf waarvan het software pakket is weet dat het geen goede situatie is, maar nu eventjes een documentatie schrijven zou volgens hun eigen schatting 1,5 jaar kosten tegen heel erg weinig opbrengsten. Dit is dus gewoon te duur en "komt ooit nog wel eens". Dit is gewoon de praktijk.
Wat nu standaard is kan over 2 jaar al compleet verouderd en "fout" zijn, ga jij dan al jouw code herschrijven naar de dan geldende standaard???

Ja als je bijvoorbeeld wil dat je software straks op een windows vista en dergelijke nog wil draaien...
Dan zal ook je software mee moeten groeien met de standaarden, en ja als je er altijd al een zooi van hebt gemaakt dan heb je er nu een hele hoop werk van... maar als je van het begin af aan netjes en gestructureerd werkt dan is uitbereiden en meegroeien niet zo heel erg moeilijk...

En wat ik uit het verhaal in de topicstart begrijp is dit niet verouderd fout maar gewoon heel erg fout...
Verouderd fout is in een nette situatie relatief snel bij te werken... En met dingen werken die geen standaard zijn doe ik sowieso al niet want dit is vragen om ellende in de toekomst om dat de standaard dan net effe anders blijkt te zijn...

[Verwijderd]

Wauw, bedankt voor alle reacties. Fijn om ook van anderen te horen dat ze met vergelijkbare gevoelens lopen, of vergelijkbare ervaring hebben. Ik wil even reageren op een aantal posts, voor wie dat nog interessant vindt.

Gomez12 schreef op woensdag 17 augustus 2005 @ 19:36:
[...]
Dit vind ik wel een goed voorbeeldje van code, want hoelang bestaat de code al en hoelang bestaan de api's al?

Vorige maand geschreven, das toch best erg? Het is niet zo dat de code zo oud is, de kennis is er gewoon niet, en ook blijkbaar niet de instelling dat je door inzicht inziet dat er een betere methode is, en deze uitzoekt. Ik wist ook niet uit m'n hoofd alle methoden e.d. van die API uit het voorbeeld, maar hebgewoon ff een middagje op MSDN gesnuffeld.

DDemolition schreef op woensdag 17 augustus 2005 @ 19:43:
De bestands structuur is bij sommige ook een puinzooi met bv. dan wel hoofdlettergebruik en dan weer niet.
Tja, wat doe je er aan? iedereen achterna lopen en de mappen hernoemen? Of gewoon zorgen dat je eigen dagelijkse dingen 'schoon' zijn lijkt mij de makkelijkste oplossing.

Ja, ook het netwerk is ernstig dichtgeslibt en zeer onoverzichtelijk. Zorgen dat m'n eigen zaken op orde zijn levert wel rust op ja.

MSalters schreef op woensdag 17 augustus 2005 @ 19:48:
Het klassieke boek op dit gebeid is natuurlijk "Refactoring", en daarin staat ook hoe je het moet verkopen. De uiteindelijke reden is business.

Die ga ik zeker eens bekijken, bedankt voor de tip, met name hoe je zoiets verkoopt vind ik belangrijk, want dat inzicht mis ik dus (zakelijk inzicht in de financiele realiteit).

Verwijderd schreef op donderdag 18 augustus 2005 @ 08:40:
Als je bij een commercieel bedrijf bent gaan werken moet je leren dat de enige reden dat je daar werkt is om zo veel mogelijk geld te verdienen! Als je daar niet mee kunt omgaan moet je op zoek naar een andere job bij een niet winst gedreven idealistische organisatie.

Zolang je niet aantoonbaar kunt maken dat wat jij wilt geld oplevert heb je geen enkele poot om op te staan. En ik ben het daar volledig mee eens!

Ik ben realistisch genoeg om in te zien dat het om geld draait. Maar dit klinkt zo 'zielloos' vind ik. Uiteindelijk zijn we toch gewoon mensen? Jij wil toch ook thuiskomen met een gevoel dat je iets goed gedaan hebt? En dat goede zit 'em dan toch niet alleen in het geld dat je voor het bedrijf verdiend hebt? Dat zit 'em toch ook in jouw persoonlijke inbreng, bijvoorbeeld door kwaliteit te leveren? Geld verdienen voor het bedrijf is niet mijn enige reden dat ik daar werk. Ik krijg per maand betaald, van die 100.000 die een klant voor een project betaald zie ik niet zoveel terug in mijn maandsalaris.

Met alle respect hoor, begrijp me niet verkeerd, maar je zou dus niet bij Google kunnen werken lijkt mij. Daar mogen de programmeurs 20% van hun tijd (dat is dus 1 dag per week!) doen wat ze willen. Dat zou voor jou dus onacceptabel zijn. Maar grote kans dat iets als Google Maps daar z'n oorsprong heeft gehad (en dat is heus wel strak geprogrammeerd hoor), en dat levert Google ongekende kansen op in de markt voor routeplanning, een echte booming business. Ik wil maar zeggen: geld verdienen kan ook anders. Ik doe het dan toch liever anders.

[Verwijderd]

Met een arogante houding kom je over het algemeen niet veel verder dan jezelf frustreren. Zie het als trage processen die echt niet zomaar even veranderen als iemand hard begint te roepen. Als jij wilt dat het schip bij stuurt zul je zelf behoorlijk aan de gang moeten! En ik kan je uit ervaring vertellen dat dat best wil maar niet makkelijk zal zijn! Met roepen bereik je weinig!

mijn advies: accepteer het, en zorg dat je zelf voldoende bijdraagt om het geheel te verbeteren.

[TXC]

DDemolition schreef op woensdag 17 augustus 2005 @ 19:43:
Dit voorbeeld heb ik ook, altans niet in programmeer taal oid.
Dit zie ik bij een klant al, waarvan ik de server beheer die bv. van de mailboxen al een grote t*ringzooi maakt. Dit resulteerd uit verschillende mailboxen van +- 900mb waarvan de gebruiker niet eens weer wat er ook al weer in staat .
De bestands structuur is bij sommige ook een puinzooi met bv. dan wel hoofdlettergebruik en dan weer niet.
Tja, wat doe je er aan? iedereen achterna lopen en de mappen hernoemen? Of gewoon zorgen dat je eigen dagelijkse dingen 'schoon' zijn lijkt mij de makkelijkste oplossing.

Dat is juist een punt waar netwerkinstallatie bedrijven te kort schieten en waar nog wel wat kleine gaatjes in de markt zitten volgens mij. Er zijn heel veel bedrijven die je netwerk aanleggen en installeren, maar verder niet helpen bij het ontwikkelen van een ICT beleid. Een goed ICT beleid (met naming conventions, regels, procedures, call registratie (ook voor statistieken over de beheersafdeling!) schud je niet 1,2,3 uit de mouw.

Momenteel loop ik stage (HBO) bij een grote bank en daar zie ik dat er een enorme bureaucratie is om de gehele ICT in goede banen te leiden. Stel een gebruiker wil een mailbox, dan duurt dat ongeveer 3 tot 5 dagen voor de procedure beëindigd is. Ik wil niet zeggen dat dat ideaal is, maar zoals al gezegd is het denk ik het belangrijkste een balans te vinden tussen de winst die je haalt uit een beter beheersbaar systeem (of programmacode) en een enorme bureaucratie die NIETS aan het toeval (of de programmeur) overlaat. Overigens lijkt het me geen slecht idee om het hier eens met je manager over te hebben, want over het algemeen wordt wat initiatief tonen zeker wel gewaardeerd is mijn ervaring.

[ Voor 46% gewijzigd door TXC op 18-08-2005 11:41 ]

[Infinitive]

Het grappige vind ik trouwens wel dat mensen die er een rommeltje van maken, vaak zelf juist wel heel handig met hun gedeelte van de rommel om kunnen gaan. Vergelijk het met je bureau waar je zelf in de troep altijd wel terug kan vinden wat je hebben moet, maar je opeens rot gaat zoeken wanneer iemand je besluit te helpen door je bureau op te ruimen. Als dat soort mensen iets moeten aanpassen, dan is het ff search replace, hack hack hier, hack hack daar. Compilen en het werkt. Die niet bij elk regeltje code aanpassen mogelijke consequenties zijn voor code executie na dat punt ("de klant laat het vanzelf wel horen als er iets mis gaat").

Maar als ik het overzicht kwijtraak en onzeker wordt over waar ik mee bezig wordt, dan komt er geen regel code uit m'n vingers. Ik weet niet precies hoe ik het moet omschrijven, maar tijdens het programmeren heb ik altijd een bepaald beeld voor ogen en als het overzicht ontbreek dan kan ik me concentreren wat ik wil maar dat beeld wil dan niet ontstaan. Met monitoren gaan gooien haalt de frustratie niet weg.

Dat wil niet zeggen dat ik geen slechte software schrijf voor mijn werkgever. Erger nog, wanneer ik software schrijf voor mijn werkgever dan overtreed ik een heleboel vuistregels waarbij ik heel vaak er bewust van ben dat ik geen goede reden heb om zo'n vuistregel te overtreden. Het het-was-de-avond-ervoor-weer-zo-laat-geworden-voordat-ik-naar-bed-ging-en-nu-geen-zin-principe. Zo, de klus is ongeveer geklaard en de afwerking komt later wel.

Als ik dat vergelijk met de code die ik schrijf voor m'n opleiding dat is dat een dag en nacht verschil. Daar denk ik veel meer voor na en besteed ik erg veel tijd aan een nette afewerking. Daar zit o.a. ook een stukje minder sleur en minder onbelangrijke details bij, zodat het wat interessanter is. Maar de belangrijkste factor is denk ik de werksituatie. Ik werk op school vrijwel altijd samen met dezelfde persoon en we zitten wat enthausiastme, netheid, gedrevenheid en kennis op vrijwel dezelfde hoogte, maar kijkt wel op een andere manier tegen problemen aan dan ik. Je werkt dan met z'n tweeën aan een project, bespreekt oplossingen, programmeerd soms samen achter een pc en soms los, inspecteerd elkaars code, enz. Als je dan lekker op dreef bent, dan heb je echt het gevoel dat je elk probleem in de wereld wel kan oplossen.

Dat laatste mis ik wel een beetje waar ik werk. Daar ben ik toch vooral individueel bezig. Dat sociale controle belangrijk is merk je dan wel en op meer plaatsen dan alleen de kwaliteit van de ontwikkelde software.

[Bbfreak]

Infinitive schreef op donderdag 18 augustus 2005 @ 14:29:
Vergelijk het met je bureau waar je zelf in de troep altijd wel terug kan vinden wat je hebben moet, maar je opeens rot gaat zoeken wanneer iemand je besluit te helpen door je bureau op te ruimen. Als dat soort mensen iets moeten aanpassen, dan is het ff search replace, hack hack hier, hack hack daar.

Dat je deze vergelijking maakt is wel leuk.
Ik denk dat sommige mensen die hun bureau opruimen ook iets gestructureerder werken.
Ik herhaal SOMMIGE.
Ik ben het er alleen niet mee eens dat je altijd je code terug vindt en hack, hack klaar.
Als ik mijn code van een tijd terug bekijk heb ik toch even tijd nodig om te begrijpen wat ik gedaan heb. Daarom dwing ik mezelf ook om netjes te werken.

Infinitive schreef op donderdag 18 augustus 2005 @ 14:29:
Dat laatste mis ik wel een beetje waar ik werk. Daar ben ik toch vooral individueel bezig. Dat sociale controle belangrijk is merk je dan wel en op meer plaatsen dan alleen de kwaliteit van de ontwikkelde software.

Deze "controle" vind ik ook erg goed en zou ik graag ook hebben.
Ik heb op mijn werk de vrijheid om te programmeren zoals ik wil en daarom kan ik er hier gewoon voor zorgen dat er netjes gewerkt worden.
Andere die dit nog niet doen zie ik soms echt met een frons naar hun eigen code kijken.

Om even op de TS terug te komen:
Ik kan me voorstellen dat je iets wil verbeteren, heb ik dus ook maar ik denk dat je voor jezelf na moet gaan wat voor consequenties dat heeft.
Het is gewoon makkelijk praten maar als het er op aan komt. Dit vereist vooral voor "oudere" IT mensen dat ze hier les in krijgen dit kost tijd, lees geld.
En dit zal de manager zien. Ik wens je er veel succes mee iig.

[Michali]

Koop anders het boek "Code Complete" en overweeg daarna je werkgever een kopie aan te laten schaffen voor alle werknemers (in overleg natuurlijk). In dit boek wordt erg goed beschreven wat belangrijke princiepes zijn en waarom. Het is puur gericht op het 'echte werk' en bevat geen theoretische werkwijzen etc., het is dan ook geschreven door iemand die zelf veel ervaring heeft in het vakgebied. Ook wordt hier en daar wat harde gegevens getoond waarin aangegeven wordt wat voor effect iets kan hebben. Er staan ook leuke stukjes in van hoe je bepaalde dingen op iemand anders over moet brengen, soort van argumenten lijstjes. Echt een aanrader imo, iedere programmeur moet deze op zijn plank hebben staan.

[Gomez12]

Verwijderd schreef op donderdag 18 augustus 2005 @ 10:51:
Wauw, bedankt voor alle reacties. Fijn om ook van anderen te horen dat ze met vergelijkbare gevoelens lopen, of vergelijkbare ervaring hebben. Ik wil even reageren op een aantal posts, voor wie dat nog interessant vindt.

[...]
Vorige maand geschreven, das toch best erg? Het is niet zo dat de code zo oud is, de kennis is er gewoon niet, en ook blijkbaar niet de instelling dat je door inzicht inziet dat er een betere methode is, en deze uitzoekt. Ik wist ook niet uit m'n hoofd alle methoden e.d. van die API uit het voorbeeld, maar hebgewoon ff een middagje op MSDN gesnuffeld.

Vorige maand geschreven autsj.... Ik wil niet zeggen dat elke keer dat je iets rottigs ziet dat je dan een middagje op msdn moet gaan snuffelen ( kost veel te veel tijd en is andere uiterste ). 90% procent van mijn programmeerwerk gebeurt nog steeds uit het blote hoofd en zo af en toe een precieze function call naam opzoeken ( adhv de grootte van het project echt uit het blote hoofd of uit een erd ) .
Maar gewoon een paar blogs volgen en eens in de zoveel tijd eens op msdn/php/internet iets opzoeken ,plus gewoon je boeren verstand gebruiken en bedenken dat 10x achter elkaar iets replacen misschien bij wel meer mensen onlogisch overkomt.
Zorgt er bij mij voor dat ik niet 100% state of the art programmeer, maar wel snel en "redelijk" netjes. Als ik een zelf bedachte constructie onlogisch ( zoals 10x replace ) vind maar zelf niets beters kan bedenken kijk ik toch over het algemeen eerst even of er tegenwoordig niet een beter alternatief voor is.

Moraal van mijn verhaal : Je hoeft niet altijd alles te volgen, maar als je een beetje kan programmeren en als je een beetje verstand hebt kun je bij heel veel situaties zelf wel bedenken dat je ergens omheen zit te werken wat waarschijnlijk nog tig mensen over de hele wereld ook doen en dat er dus ondertussen waarschijnlijk wel een goede methode is. Als je deze snel kunt vinden dan gebruik je deze en anders gewoon je eigen methode.

[whoami]

Gomez12 schreef op donderdag 18 augustus 2005 @ 19:02:
[...]

Vorige maand geschreven autsj.... Ik wil niet zeggen dat elke keer dat je iets rottigs ziet dat je dan een middagje op msdn moet gaan snuffelen ( kost veel te veel tijd en is andere uiterste ). 90% procent van mijn programmeerwerk gebeurt nog steeds uit het blote hoofd en zo af en toe een precieze function call naam opzoeken ( adhv de grootte van het project echt uit het blote hoofd of uit een erd ) .
Maar gewoon een paar blogs volgen en eens in de zoveel tijd eens op msdn/php/internet iets opzoeken ,plus gewoon je boeren verstand gebruiken en bedenken dat 10x achter elkaar iets replacen misschien bij wel meer mensen onlogisch overkomt.
Zorgt er bij mij voor dat ik niet 100% state of the art programmeer, maar wel snel en "redelijk" netjes. Als ik een zelf bedachte constructie onlogisch ( zoals 10x replace ) vind maar zelf niets beters kan bedenken kijk ik toch over het algemeen eerst even of er tegenwoordig niet een beter alternatief voor is.

Moraal van mijn verhaal : Je hoeft niet altijd alles te volgen, maar als je een beetje kan programmeren en als je een beetje verstand hebt kun je bij heel veel situaties zelf wel bedenken dat je ergens omheen zit te werken wat waarschijnlijk nog tig mensen over de hele wereld ook doen en dat er dus ondertussen waarschijnlijk wel een goede methode is. Als je deze snel kunt vinden dan gebruik je deze en anders gewoon je eigen methode.

Als je nooit naar een betere oplossing zoekt, of nooit tijd neemt om iets bij te leren, hoe wordt je dan zelf beter ? Hoe evolueer je dan zelf als programmeur ?

[Gomez12]

whoami schreef op donderdag 18 augustus 2005 @ 20:14:
[...]


Als je nooit naar een betere oplossing zoekt, of nooit tijd neemt om iets bij te leren, hoe wordt je dan zelf beter ? Hoe evolueer je dan zelf als programmeur ?

Naar mijn idee evolueer je als programmeur door seminars /cursussen etc. niet door een halve middag op internet te gaan dwalen.
En dat ik nooit naar een beter oplossing zoek zeg ik absoluut niet, ik zoek "altijd" naar een betere oplossing als ik denk dat mijne niet goed. Als ik denk dat mijne goed is (of voldoet voor de situatie, anders kan je vast en zeker in assembler nog wel een hele hoop performance gaan halen ) Dan ga ik echt niet stomzinnig op inet zitten zoeken of er misschien iemand is die een betere oplossing heeft dan ik.
En het tijd nemen om iets bij te leren zit gewoon in mijn werktijd inbegrepen ( in de vorm van cursussen en lossere uurtjes en niet geblokkeerd internet etc ).
Alleen een halve middag op msdn zitten zoeken naar 1 api voor 1 functiecall die lelijk is vind ik echt verloren tijd. Als ik een nieuw project begin wil ik me best nog wel even opfrissen in de huidige materie, maar een rewrite doen met "veel" opzoekwerk ( ook al kan het handig zijn voor in de toekomst ) vind ik echt nutteloos, omdat het in mijn opinie al bij het begin had moeten plaatsvinden of niet, maarja mijn voorbereiding duurt in verhouding ook vrij lang denk ik terwijl mijn coding gewoon in 1 stuk doorgaat. Dit heeft als voordeel dat het bedrijf een redelijke offerte kan neerleggen, want de meeste uitlooptijd zit in mijn geval in de voorbereiding en niet in het coden. Dus als er met de klant een functioneel ontwerp bereikt is dan is de tijd die daarin staat ook echt reeel, omdat ik in mijn hoofd ( /op papier ) alle technieken die ik ga gebruiken heb staan.

[Alex]

Ik doe ene deeltijd studie en heb, in mijn ogen, het idee dat ze jou goed verpest hebben op school.
Theoretische bassisen zijn 100% zeker nodig, maar warav het ana schort is de intergratie met het bedrijfsleven. Men snapt gewoon niet dat als elke schakel er hard aan werkt je voor allen een accepteerbare oplossing hebt. Waarom niet? Ze zijn vanaf dag 1 gewend dat elke sectie alles wat ze kunnen eruit moet slepen en dat betekent dus ook vrije tijd, dus schrijf je quick dirty code.
Ik zie het bij mij op het werk, ik zie het aan de code van de grote jongens van Nederland, alles en iedereen.
Totdat je gaat werken als ambtenaar, dan kun je je geluk niet op.

Gomez12 schreef op donderdag 18 augustus 2005 @ 21:04:
[...]

Naar mijn idee evolueer je als programmeur door seminars /cursussen etc. niet door een halve middag op internet te gaan dwalen.

Ik wél. Hoe denk je dat ik anders mezelf XAML-proleet kan noemen? Misschien is dat wel wat overdreven, maar ik heb die onzin over Avalon / Windows Vista Presentation Foundation?
Niet door een seminar te volgen die er niet zijn.
Je moet je horizon breder maken als de mooie voorgeschreven regeltjes van je opleiding.

[misfire]

Ik vind het op zich wel grappig dat je rond half twee 's-middags een topic opent op GoT. Vakantie of een langere lunchpauze? Alhoewel het me aantrekkelijk lijkt om op GoT surfen de "ideale manier van werken" te noemen is dit volgens mij slechts voor enkelen weggelegd.

Voor mij is "de ideale manier van werken" een manier waarop je fouten en verbeteringen actief detecteert, ze corrigeert en implementeert voor ze een probleem vormen en ervan leert zodat je dezelfde fouten niet nog een keer maakt. Verder zul je wel merken dat iedere omgeving en ieder project wat je doet specifieke eisen stelt aan je manier van werken. Daar zul je actief op moeten reageren en flexibel in moeten zijn. Je zult nooit een bepaalde vaste procedure kunnen volgen die "perfect" is en altijd werkt.

Als je graag verbeteringen wil doorvoeren dan werkt practice-what-you-preach altijd heel goed voor mij. Wil je dat mensen unit-testen schrijven? Schrijf dan zelf unit-tests. Zijn mensen veel aan het vragen over component-afhankelijkheden? Maak een plaatje en hang dat aan de muur. Enz. Je lokt er in ieder geval discussie mee uit, daarmee kun je je best practice verkopen, of overtuigd worden waarom dat ze het in het bedrijf toch anders aanpakken.

Verder is het verstandig om te kijken naar de grootste bottle-necks die je nu in het huidige proces ziet, en daar als eerste maatregelen voor te nemen. Processen werken volgens de theorie van beperkingen (zie voor een goed voorbeeld XP explained 2nd edition, een aanrader), wat inhoudt dat procesverbeteringen niet helpen zolang deze niet direct de grootste problemen oplossen.

Veel bedrijven maken er gewoon een zooitje van. Dat is niet alleen zo in de IT. Ik weet ook niet precies hoe het komt, de theorie die mij het meest aansprak was die van The Dilbert Principle. In dit boek wordt de volgende stelling verdedigd: "all people are idiots". In de uitleg wordt beschreven dat je als een team elkaar moet ondersteunen (om elkaars idiote acties bij te sturen), en wat de risico's van eenrichtings-hiërarchiën zijn. Ook verklaart het waarom grotere bedrijven vaak idioter zijn: de afstand tussen idioten die iets met elkaar te maken hebben neemt toe, en er zijn gewoon meer idioten.

[Verwijderd]

Gomez12 schreef op donderdag 18 augustus 2005 @ 21:04:
Naar mijn idee evolueer je als programmeur door seminars /cursussen etc. niet door een halve middag op internet te gaan dwalen.

Naar mijn mening kun je beter iemand in dienst hebben die zelf de oplossingen op internet kan vinden, dan iemand die overal een cursus voor nodig heeft. Dan zwijg ik nog maar even over het feit dat deze cursussen bijna zonder uitzondering gegeven worden door mensen die zelf niet eens weten hoe het moet. Immers, hadden ze dat wel geweten dan waren ze wel iets anders gaan doen dan cursussen geven. Het daadwerkelijke nut van cursussen wordt schromelijk overschat. De meeste cursussen is niet meer dan een paar dagen er tussenuit op kosten van de baas en goed verzorgde lunches.

Dan ga ik echt niet stomzinnig op inet zitten zoeken of er misschien iemand is die een betere oplossing heeft dan ik.

Stomzinnig is altijd fout. Of je nu stomzinnig een cursus volgt of stomzinnig op internet zoekt. Het verschil is dit: stel morgen kom je een probleem tegen wat je niet kent. Jij kunt het dan niet oplossen, daar jij kennis louter door cursussen wilt vergaren. Die prutser die een middagje op internet surft lost het probleem op door een middagje op internet te surfen. Wie heb je liever in dienst?

Overigens had hij het over een 'middagje MSDN'. Dat kun je imo gewoon vergelijken met iemand die een middag een boek over een bepaald onderwerp leest. MSDN bevat een schat aan informatie, dat afdoen als 'stomzinnig' of zeggen dat iemand beter cursussen kan gaan volgen, is imo meer stomzinnig dan dat surfen.

Alleen een halve middag op msdn zitten zoeken naar 1 api voor 1 functiecall die lelijk is vind ik echt verloren tijd.

Als jij een halve middag op MSDN aan het bladeren bent, leer je iets. Misschien is het vanuit het oogpunt van die 1ne functiecall inderdaad verloren tijd, maar over het geheel genomen betwijfel ik dat ten zeerste.

Als ik een nieuw project begin wil ik me best nog wel even opfrissen in de huidige materie, maar een rewrite doen met "veel" opzoekwerk ( ook al kan het handig zijn voor in de toekomst ) vind ik echt nutteloos,

Refactoring is alles behalve nutteloos. In sommige gevallen is het zelfs noodzakelijk om uberhaupt verder te kunnen werken aan een project.

omdat het in mijn opinie al bij het begin had moeten plaatsvinden of niet, maarja mijn voorbereiding duurt in verhouding ook vrij lang denk ik terwijl mijn coding gewoon in 1 stuk doorgaat. Dit heeft als voordeel dat het bedrijf een redelijke offerte kan neerleggen, want de meeste uitlooptijd zit in mijn geval in de voorbereiding en niet in het coden. Dus als er met de klant een functioneel ontwerp bereikt is dan is de tijd die daarin staat ook echt reeel, omdat ik in mijn hoofd ( /op papier ) alle technieken die ik ga gebruiken heb staan.

Oftewel de meest trage en langzame ontwikkelmethodiek (waterval) die er bestaat en welke in de praktijk ook nog eens het meest software oplevert die de klant helemaal niet wil. Je kent dat plaatje wel 'what the designer drew', 'what the programmer built', 'what the client asked for' enz. Die is op die methodiek gebaseerd.

Ja natuurlijk kan het ook goede resultaten opleveren, als elke fase ook echt daadwerkelijk goed uitgevoerd wordt. Ik zie echter heel vaak dat het FO niet veel meer is dan een paar A4 tjes met wat gedachtes erop die men met een middagje brainstormen in elkaar geflanst heeft - alhoewel dit bij m'n huidige werkgever al beter is.

Ik geloof veel sterker in prototyping. Dus niet dagen of wekenlang voorbereiden en kasten vol met ordners documentatie, nee, gelijk beginnen met interface mockups enz, om op die manier, samen met de klant, helemaal vast te stellen wat de bedoeling is. Is dat helemaal duidelijk dan kun je nog wat prototypes voor onderhuidse functies er tegenaan gooien (bv. kijken op welke manier je een bepaald probleem het efficientst oplost) en dan alle prototypes als het ware 'weggooien' en beginnen aan het 'echte' programmeren. Ik zou wel een FO maken, maar op basis van de prototypes en niet op basis van intake-gesprekken oid. Dit laatste domweg omdat een klant vaak helemaal niet weet wat hij/zij precies wil, of wat er allemaal mogelijk is.

Kenmerk van waterfall is dat je na de release van de eerste versie voor een GAT (gebruikers acceptatie versie) ineens nog allemaal verzoeken tot nieuwe features en veranderingen krijgt. Dit is omdat de klant tijdens het gehele ontwikkeltraject eigenlijk nog helemaal niets gezien heeft, alleen maar documentatie. Pas als er iets is wat op het beoogde product lijkt, gaat een klant zich realiseren wat de mogelijkheden zijn, en zal hij/zij daar ook om gaan vragen.

[Gomez12]

Toch wel grappig iemand die mijn post totaal anders interpreteert dan ik bedoeld had

Verwijderd schreef op donderdag 18 augustus 2005 @ 22:53:
[...]


Naar mijn mening kun je beter iemand in dienst hebben die zelf de oplossingen op internet kan vinden, dan iemand die overal een cursus voor nodig heeft. Dan zwijg ik nog maar even over het feit dat deze cursussen bijna zonder uitzondering gegeven worden door mensen die zelf niet eens weten hoe het moet. Immers, hadden ze dat wel geweten dan waren ze wel iets anders gaan doen dan cursussen geven. Het daadwerkelijke nut van cursussen wordt schromelijk overschat. De meeste cursussen is niet meer dan een paar dagen er tussenuit op kosten van de baas en goed verzorgde lunches.

Je weet dat op internet 75% bullshit/speculatie/rumors/achterhaald is, 25% waarheid is en dat jij dit zelf nog eens mag gaan uitmaken aan de hand van de pagina die je voor je neus hebt??? En dit is mijn eigen persoonlijke voorzichtige schatting. De goede cursussen zijn wel meer dan een paar dagen ertussenuit ( maar wederom hoe weet je welke cursus goed is ??? ). Het enige punt wat ik in jouw stukje lees is dat cursussen niet state of the art zijn, maar dit verwacht ik ook niet, van een cursus verwacht ik dat het over proven technology gaat. (verkeerd vb ok maar is alleen vb ) Zoek eens op een zoekmachine naar microsoft vista en ga dan naar een seminar van ms over ms vista, welke geloof jij meer, ik weet op voorhand dat ik op het seminar niet alle info krijg en dat ik dit op inet wel kan vinden, maar op inet is er misschien 1 waarheid tussen 10 geruchten over vista...

Stomzinnig is altijd fout. Of je nu stomzinnig een cursus volgt of stomzinnig op internet zoekt. Het verschil is dit: stel morgen kom je een probleem tegen wat je niet kent. Jij kunt het dan niet oplossen, daar jij kennis louter door cursussen wilt vergaren. Die prutser die een middagje op internet surft lost het probleem op door een middagje op internet te surfen. Wie heb je liever in dienst?

Overigens had hij het over een 'middagje MSDN'. Dat kun je imo gewoon vergelijken met iemand die een middag een boek over een bepaald onderwerp leest. MSDN bevat een schat aan informatie, dat afdoen als 'stomzinnig' of zeggen dat iemand beter cursussen kan gaan volgen, is imo meer stomzinnig dan dat surfen.

Over info die ik niet ken zei ik al dat ik dit in het voortraject best wil uitzoeken ( en uitzoeken betekent simpelweg alle info die ik op korte termijn kan vinden dus : inet / bladen / boeken / seminars, cursussen kosten hier over het algemeen te veel tijd voor ). Maar ik durf rustig te zeggen dat ik bijna ( 99%) elk probleem kan oplossen in code als iemand bereid is om mij het algoritme uit te leggen ( als ik het switch / select statement niet ken kan ik altijd nog 100 if'jes achter elkaar zetten. Niet efficient, niet netjes, maar de klant merkt er niks van, zie TS, omdat ik stompzinnig 100x hetzelfde zou doen zou ik toch kijken of er niet een andere manier was )
En btw in de TS staat dat hij zichzelf heel intensief heeft verdiept in alle theorie ( van zijn studie ) en toch is hij in zijn voorbeeld nog een halve middag bezig met 1 statement te herschrijven. 1 statement herschrijven kan ik niet vergelijken met een boek lezen. Maarja ik gebruik msdn dan ook voornamelijk als function-name reference, als boeken lees ik meer de theorie boeken waar geen regel code instaat maar die gewoon een goede theorie geeft die in elke hedendaagse programmeertaal te gebruiken is.

Refactoring is alles behalve nutteloos. In sommige gevallen is het zelfs noodzakelijk om uberhaupt verder te kunnen werken aan een project.

[...]

Refactoring kan inderdaad nuttig zijn, maar als jij als enige in een bedrijf netjes werkt is refactoring gewoon nutteloos. Gewoon door het simpele feit dat je eerst de basis aan moet pakken ( dus zorgen dat je mede-programmeurs netjes werken ) anders kan je volgende week opnieuw gaan refactoren. Als TS een voorbeeld geeft waarin hij 1 statement refactored ( wtf is dit voor werkwoord ) dan denk ik toch : je herschrijft een functie, je herschrijft een programma. Maar je geeft toch geen voorbeeld waarbij je 1 regel herschrijft.

Oftewel de meest trage en langzame ontwikkelmethodiek (waterval) die er bestaat en welke in de praktijk ook nog eens het meest software oplevert die de klant helemaal niet wil. Je kent dat plaatje wel 'what the designer drew', 'what the programmer built', 'what the client asked for' enz. Die is op die methodiek gebaseerd.

Niet perse ( alhoewel ik in de praktijk al vaak genoeg jouw redenering waarheid heb zien zijn ). Bij mij is het meer :
1 : klant wil iets.
2 : consultant gaat met klant praten
3 : consultant en designer en programmeur gaan in conclaaf over wat er mogelijk is voor de klant ( hie zit dus het uitzoekwerk )
4 : consultant gaat weer met klant praten. ( indien nodig ondersteunt door designer of programmeur )
5 : if customer not satisfied goto 2
6 : programmeur maakt een 1e basis opzet
7 : designer maakt opzet aan de hand van stap 6
8 : programmeur maakt het werk van de klant af.

Ik geloof veel sterker in prototyping. Dus niet dagen of wekenlang voorbereiden en kasten vol met ordners documentatie, nee, gelijk beginnen met interface mockups enz, om op die manier, samen met de klant, helemaal vast te stellen wat de bedoeling is. Is dat helemaal duidelijk dan kun je nog wat prototypes voor onderhuidse functies er tegenaan gooien (bv. kijken op welke manier je een bepaald probleem het efficientst oplost) en dan alle prototypes als het ware 'weggooien' en beginnen aan het 'echte' programmeren. Ik zou wel een FO maken, maar op basis van de prototypes en niet op basis van intake-gesprekken oid. Dit laatste domweg omdat een klant vaak helemaal niet weet wat hij/zij precies wil, of wat er allemaal mogelijk is.

dus jij gelooft dat je eerst maar moet beginnen met wat klad-programmeren en klad-designen en dat je dit (desnoods) daarna gewoon kan weggooien?

Kenmerk van waterfall is dat je na de release van de eerste versie voor een GAT (gebruikers acceptatie versie) ineens nog allemaal verzoeken tot nieuwe features en veranderingen krijgt. Dit is omdat de klant tijdens het gehele ontwikkeltraject eigenlijk nog helemaal niets gezien heeft, alleen maar documentatie. Pas als er iets is wat op het beoogde product lijkt, gaat een klant zich realiseren wat de mogelijkheden zijn, en zal hij/zij daar ook om gaan vragen.

Bij ons is dit de functie van de consultant. In bovenstaand plaatje moet hij in stap 2 alles noteren wat de klant wil, in stap 3 moet hij alle limitaties noteren, dan mag hij in stap 4 alles eruit gooien wat niet door stap 2 of 3 ( belangrijkste ) gelimiteerd wordt.

[Verwijderd]

Gomez12 schreef op donderdag 18 augustus 2005 @ 21:04:
[...]
Alleen een halve middag op msdn zitten zoeken naar 1 api voor 1 functiecall die lelijk is vind ik echt verloren tijd.

Nee dat was het niet hoor. Het zoeken was een half uurtje, het experimenteren de rest van de middag. Ik loste halverwege al een probleem op dat daarvoor dus 3 keer per dag aandacht vroeg (telkens weer een zelfde fout). Dus i.p.v. verdeelde aandacht over een lange periode die eigenlijk niets 'echt' oploste, heb ik een korte tijd besteed aan een structurele oplossing.

En ik ben verder blijven lezen en zoeken, omdat ik een duidelijk plaatje wilde om hierover uitleg te kunnen geven aan mijn collega's, zodat ook bij nieuwe projecten dit soort 'stomme' fouten voorkomen worden.

In mijn ogen is investeren in kenis altijd goed, maar ik doe dat ook regelmatig in mijn vrije tijd hoor, niet alleen in de tijd van de baas...

[tekno]

Een zeer interessant topic tot nu toe, waar ik, 4e jaars technische informatica aan tu/e, zeker wat van op kan steken.

Er worden hier twee boeken genoemd:
code complete (2nd edition?)
en
refactoring

Welk refactoring boek raden jullie aan?

Verder blijft het vreemd dat de software industrie wel gewoon in elkaar gehackte 'troep' kan afleveren, waar als het niet goed werkt men dat als klant niet echt vreemd vind, maar dit meldt en slechts hoopt op verbetering.

En is het leuke van de theorie die je hebt opgestoken, niet deels het overbrengen daarvan op anderen, zodat je hun leven uiteindelijk makkelijker kunt maken?

Maar wat ook zeker waar is, is dat theorie en realiteit vaak sterk verschillen

[Verwijderd]

tekno schreef op vrijdag 19 augustus 2005 @ 11:05:[...]
Maar wat ook zeker waar is, is dat theorie en realiteit vaak sterk verschillen

Ik kreeg van een collega nog een mooie quote toegestuurd:

Het probleem met het verschil tussen de theorie en de praktijk is dat hier in theorie geen verschil tussen bestaat, maar in de praktijk meestal wel.

Bron: NRC, 13/8

[supakeen]

Ik heb het geluk dat hier op mijn werk een nieuwe senior is aangesteld die volledig in OO denkt Dus het eerste wat ze deden was mij aannemen om de webinterface te herschrijven naar OO. En wat ik in deze code ook tegenkom van de raarste comments tot 20x dezelfde 200 regels code met andere variabele namen.

[whoami]

tekno schreef op vrijdag 19 augustus 2005 @ 11:05:
Een zeer interessant topic tot nu toe, waar ik, 4e jaars technische informatica aan tu/e, zeker wat van op kan steken.

Er worden hier twee boeken genoemd:
code complete (2nd edition?)
en
refactoring

Welk refactoring boek raden jullie aan?

Het refactoring boek waar MSalters het over had is hoogstwaarschijnlijk:
Refactoring - Improving the design of existing code van Martin Fowler/Kent Beck

[Verwijderd]

Verschil tussen theorie en praktijk:

"Jantje vroeg aan zijn vader wat het verschil tussen theorie en praktijk was. Zijn vader riep hierop zijn moeder en zijn zusje erbij, en vroeg hen beide of ze voor 2 miljoen euro met een willekeurige man naar bed zouden gaan. Hierop antwoordden beide bevestigend, voor dat bedrag zouden ze alles ne*ken wat lost en vast zat.

"Welnu Jantje", sprak vader, "nu komt de clou. In theorie zijn wij multimiljonairs, maar in praktijk wonen we samen met twee hoeren".

[Verwijderd]

Alhoewel het hier om software gaat zal de oorzaak van deze problemen vaak liggen in de algehele bedrijfsvoering. Sales verkoopt wat er niet is voor te optimistische bedragen, Project management krijgt halve offertes en de requirements worden ondanks pre sales activiteiten te vaak gewijzigd, development geeft aan 50% test tijd nodig te hebben maar dit is niet meegenomen in de offerte. Etc.

Er zit een hele reeks aan fouten in een bedrijfsvoering aan dit soort problemen vast, en vaak komt het neer op willen luisteren naar elkaar; communicatie.