[alg] Techniek overkill.

[Alarmnummer]

In mijn omgeving, op fora en op mensen van mijn msn lijst (de mensen die geinteresseerd zijn in techniek) zie ik de laatste tijd een bepaald probleem terug. Het probleem is: techniek overkill. Mensen die hebben dan bepaalde technieken geleerd (vooral patterns), en passen het toe zonder aan de gevolgen te denken. Ze proberen ook alles in een ontwerp te plaatsen wat ze ook kennen. Aan 1 kant is dit wel goed aangezien het beter is dan iemand die echt niets kan en ik weet hun motivatie ook te waarderen (liever iemand die te veel zijn best doet dan te weinig). Maar in de praktijk is een technisch overontwikkelde oplossing denk ik bijna net zo erg als een technisch onder ontwikkelde oplossing.

Een aantal problemen van technisch onder ontwikkelde oplossingen:
-onduidelijk (wie begrijpt puinzooi)
-niet/slecht uitbreidbaar (als je geen duidelijk beeld krijgt van software kan je het ook niet aanpassen)
-aan allerlei kwaliteits attributen zoals performance, veiligheid etc kan niet worden voldaan
(als er geen structuur aanwezig is kun je niet over een systeem redeneren)

Technische overontwikkelde oplossingen:
-onduidelijk (complexe oplossingen kosten per definitie meer tijd om te begrijpen dan eenvoudige)
-niet/slecht uitbreidbaar (onnodige complexiteit zal in veel gevallen niet in de juiste richting ontwikkeld zijn mbt wijzigingen.. Je zit dus nu met een bepaald blok aan je been waardoor je niet even iets eenvoudig kunt aanpassen)
-als de omgeving goed is ontwikkeld maar te complex is voor zijn doel, dan is het nog steeds lastiger om over de kwaliteits attributen te redeneren dan in een omgeving die minimaal is voor dat doel).

Dit zijn nog maar een aantal punten...

Wie deelt deze indrukken met mij? Wie heeft het gevoel dat veel beginnende programmeurs volledig aan het cowboyen zijn....

ps:
ik moet ook eerlijk toegeven dat ik er vroeger ook wel eens een handje van heb gehad En ik heb nu ook nog steeds de voet op de rem.. ho... wat gaan hiervan de consequenties worden? Past dit nog in het geheel en blijft de algehele structuur gehandhaafd? En het belangrijkste: blijven simpele dingen nog simpel?

[ Voor 11% gewijzigd door Alarmnummer op 28-03-2005 17:21 ]

[Verwijderd]

Ja hoor. Helemaal mee eens. Sowieso erger ik me er wel aan dat er te pas en te onpas buzzwords zoals bijvoorbeeld "patterns" worden rondgestrooid.

Ik heb niet veel ervaring met beginnende programmeurs (ik ben nog niet aan het werk), dus uit de praktijk kan ik er niet zoveel nuttigs over zeggen, maar ik krijg die indruk in elk geval zeker wel.

Hoewel ik er mezelf ook regelmatig op betrap dat ik overdesign. Gooi overal nog maar een paar laagjes abstractie bovenop, dan is het in de toekomst "makkelijk uit te breiden". Totale onzin natuurlijk; het staat gelijk met voorbarig optimaliseren: dikke kans dat het nooit gebruikt gaat worden, en dan is je werk voor niks. En vaak maakt het de code ook niet leesbaarder.

Dus sja, kunstjes gebruiken òm het gebruiken... het is wel degelijk een reëel gevaar.

[MacWebber]

Mee eens. Mooi voorbeeld; een vriend van me maakt websites (wie niet). Sommige briljant, sommige wat experimenteler. Laatst had 'ie een voor een vrij simpel doel (ik geloof voor een motorclub) een erg mooie site gemaakt. Als navigatie een smooth-scrollend menu waar echt iedere javascript ontwikkelaar het warm van in het kruis krijgt (man of vrouw). Navigatie scrolde prachtig een plek op het scherm in waar ruimte was, en waar het toch vooral geen andere schermonderdelen in de weg stond. En scrolde weer weg als je met je muis te ver weg ging.

Toen ik hem vroeg waarom die navigatie niet gewoon altijd op het scherm stond, als er toch ruimte voor was, had 'ie geen antwoord. Techniek-blindheid, denk ik.

Soms moet je als ontwikkelaar even een stapje achteruit doen en kijken of je nog bezig bent om je originele probleem op te lossen, of dat je nieuwe oplossingen aan het verzinnen bent voor problemen die er niet zijn. Maar da's best moeilijk. Tenslotte is programmeren zo leuk

[Alarmnummer]

Verwijderd schreef op maandag 28 maart 2005 @ 17:20:
Ja hoor. Helemaal mee eens. Sowieso erger ik me er wel aan dat er te pas en te onpas buzzwords zoals bijvoorbeeld "patterns" worden rondgestrooid.

Precies.. verder moet iedere developer intussen SAO (Sexueel overdaagbare aandoening of Service Oriented Architecture, take your pik) kennen.. En geen applicatie is goed zonder echte stukjes XML. Dat zijn idd van die mode hypes... de vraag is: geef je de klant zijn zin? Of ga je hem duidelijk makendat hij zich niet met de it moet bemoeien Ik ga mezelf echter niet in mijn vingers snijden.. dus als iemand iets wil dan kan hij dat krijgen.

Ik heb niet veel ervaring met beginnende programmeurs (ik ben nog niet aan het werk), dus uit de praktijk kan ik er niet zoveel nuttigs over zeggen, maar ik krijg die indruk in elk geval zeker wel.

Ik kijk al aan aantal jaren tegen de groei van mensen uit mijn msn lijst aan Dus ik zie dit vaak voorbij komen... Het verschil is alleen dat patterns voor mij intussen niet meer nieuw zijn... En ik ook wel eens te complexe software heb geschreven...

Hoewel ik er mezelf ook regelmatig op betrap dat ik overdesign. Gooi overal nog maar een paar laagjes abstractie bovenop, dan is het in de toekomst "makkelijk uit te breiden".

Ik probeer voor mezelf deze keuzes wel wat te nuanceren. Bv: hoe meer ik richting core zaken ga hoe onverplichter het moet gaan worden. Dus geen interfaces met te veel functionaliteit.. maar hele lichte interfaces. Het geeft dan wel iets meer complexiteit, maar je kunt makkelijk componenten wisselen. Vooral als ik richting util/framework/platform achtige zaken ga vind ik deze rekening niet zo`n probleem. Hoe concreter de componenten worden, hoe minder ik behoefte heb aan uitbreidbaarheid ed. Ze moeten precies doen wat ze moeten doen.. niet meer.. niet minder.. Naarmate je meer naar buiten gaat in de (afhankelijkheids)ringen van je systeem des te minder invloed een 'slecht' ontwerp heeft.

[ Voor 17% gewijzigd door Alarmnummer op 28-03-2005 17:38 ]

[Zoijar]

C++ templates (meta programming). Daar wordt maar mee in het rond gegooid... Je hoeft niet alles compiletime te doen Bovendien snapt niemand de code meer. Het is vaak lastig te gebruiken, omdat je overal lange regels met template specificaties neer moet zetten. Als je toch later ineens iets de gebruiker wilt laten kiezen, in een menu bv, dan kan dat niet. Je moet dan recompilen voor elke andere optie...templates worden veel misbruikt. Vaak wil je ook helemaal geen template oplossing, omdat er toch geen user type in gebruikt kan worden. Dan ga je over op policies, waarvan niet duidelijk is wat daar precies van verwacht wordt. Er is nl. geen formele interface; als je iets fout doet krijg je een ongelooflijk onduidelijke compiler error, die vaak ergens diep in de code ligt.

[ACM]

Alarmnummer schreef op maandag 28 maart 2005 @ 17:14:
Mensen die hebben dan bepaalde technieken geleerd (vooral patterns), en passen het toe zonder aan de gevolgen te denken. Ze proberen ook alles in een ontwerp te plaatsen wat ze ook kennen.

Daar zit hem nou juist de kneep. Je kan, imho, niet verwachten dat iemand 'alle mogelijke oplossingen' kent, zelfs niet alle populaire. Niet iedereen zal Spring kennen, laat staan weten dat het een redelijk goed alternatief is voor EJB en andere J2EE standaarden. Niet iedereen kent Struts en zelfs Struts kent al beperkingen die weer door andere frameworks beter gedaan worden.
Je kan dan wel roepen dat het niet goed is dat ze "wat ze kennen" toepassen, maar verwacht je dan niet eigenlijk veel te veel van de mensen?

Zelf ben ik een tijd terug met een (voor mij) vrij grote webapplicatie begonnen die door allerlei opdrachtjes met hogere prioriteiten verre van af is. Die is gebaseerd op Struts als MVC, eigen bussiness en DAO code en Hibernate voor de daadwerkelijke OR/Mapping. Maar ondertussen is Spring weer een heel stuk populairder geworden, zijn er allerlei "betere" (andere iig) MVC-frameworks ontstaan of bekender geworden, etc, etc.
Moet ik dan nu de boel weer compleet omschrijven naar Spring? Is er wellicht iets "nog beters" ? Is Struts nog wel een geschikte oplossing?
Een deel van de tijd heb ik besteed aan het generiek maken van een groot deel van de code waardoor ik feitelijk maar één complete DAO heb en één complete Action voor de CRUD-handelingen, ondanks dat ik aardig wat verschillende type objecten heb die in de database opgeslagen moeten worden. Toch zie ik dat dat wellicht door Spring nu ook voor me gedaan kan worden en ik dus weer een zwik eigen code overboord zou kunnen zetten. Moet ik dat dan doen?

Allemaal vragen waar ik al mee zit voor de boel af is, maar toch kost het enorm veel tijd om daar antwoorden op te vinden.
En ik vermoed dat ik niet de enige ben die zich dat soort dingen afvraagt: "Kan het beter? En hoe dan?". Het vinden van een antwoord op die vraag kost behoorlijk wat tijd, zeker als je een nieuw framework moet leren kennen. Het uitvoeren van een antwoord kan nog meer tijd kosten, want dan moet je het betreffende framework nog beter leren kennen en integreren in je applicatie. Dan kan ik me goed voorstellen dat je de ingslagen weg blijft volgen zolang iets aan de eisen voldoet, ondanks dat het wel "beter" kan.
En ja, dan kan het best zijn dat het achteraf allemaal veel beter had gekund. Maar vraag je dan wel af: was het dan voor de klant beter geweest? Was het dan sneller af geweest uiteindelijk? Heeft de onderhoudbaarheid er echt zo veel onder geleden dat het de waarschijnlijke vertraging waard was?

[Alarmnummer]

ACM schreef op maandag 28 maart 2005 @ 19:28:
[...]

Daar zit hem nou juist de kneep. Je kan, imho, niet verwachten dat iemand 'alle mogelijke oplossingen' kent, zelfs niet alle populaire.

... nog heel verhaal over betere technieken kiezen

Mijn verhaal gaat niet zozeer over andere technieken kiezen. Maar binnen die technieken voor lichtere oplossingen gaan, en dan doel ik voornamelijk op oo oplossingen. Dus niet meteen een hele zwik met patterns toepassen, maar eerst kijken wat het probleem nu is. En op basis hiervan de juiste dingen te kiezen. Vaak is een licht ontwerp dan al voldoende...

dat het wel "beter" kan.
En ja, dan kan het best zijn dat het achteraf allemaal veel beter had gekund. Maar vraag je dan wel af: was het dan voor de klant beter geweest? Was het dan sneller af geweest uiteindelijk? Heeft de onderhoudbaarheid er echt zo veel onder geleden dat het de waarschijnlijke vertraging waard was?

Het gaat niet zozeer om tijdens een project van techniek te wisselen. Ik heb ook wel eens: dat had mooier gekund. In sommige gevallen denk ik er dan wel eens aan terug en kan ik deze nieuwe kennis weer gebruiken voor een volgend project.

Maar het gaat over je algehele manier van werken.. Niet meteen iedere mogelijke pattern toepassen die je kent (of net hebt geleerd). Maar dat je ook kijkt naar de consequenties van die aanpak (en dan doel ik voornamelijk op complexiteit).

[ Voor 12% gewijzigd door Alarmnummer op 28-03-2005 20:07 ]

[Verwijderd]

offtopic:
Er staat me nog een verhaal bij van een Java enthousiast die hele frameworks had geschreven met weak references voor listeners and god knows what else...

Maar ik ben het er helemaal mee eens. Elegant coden is mooi, als het nuttig is. Geen fratsen, dat scheelt. Zoals Alarmnummer al aangeeft zijn er een aantal Buzzwords waar tegenwoordig iedereen een graantje van mee wil pikken, XML, webservices, .NET etc. etc.

Het mooiste is proberen iemand er tegenwoordig ervan te overtuigen dat jou programma zonder allerlei toeters en bellen dat doet wat het moet doen... neemt natuurlijk niet weg dat ook ik af en toe wel eens iets inbouw wat mooi op de 'feature lijst' staat en wat totaal geen meerwaarde biedt Verkopen is helaas nog altijd voor 90% marketing (en ga me niet vertellen dat het niet zo is, want dat bleek wel weer duidelijk op CeBit...)

Ik betrap me er zelf ook nog vaak genoeg op dat ik iets programmeer met het idee van 'dan kan ik het later mooi uitbreiden' en dat ik me de volgende dag bedenk dat ik totaal geen reden weet waarom ik de specifieke functionaliteit uit zou willen breiden (bijgaand concreet voorbeeld is te beschamend )

[misfire]

Twee woorden: KISS en YAGNI. Het is niet voor niets dat methodes als XP zo veel aandacht krijgen. Ook in andere disciplines, zoals ontwerpen of wetgeving, is er aandacht voor dit gevoel. Ook daar geldt dat de meest succesvolle oplossingen een goede balans zijn tussen de complexiteit van het probleem en de complexiteit van de oplossing. En ook daar geldt dat slechts een klein deel van de professionals voldoende talent en inzicht hebben om dergelijke oplossingen te kunnen maken.

Er wordt hier overigens gesuggereerd dat alleen "beginnende" programmeurs dit soort fouten maken. Dat is natuurlijk ook maar net hoe je beginnend definieert, maar aantal jaren ervaring is in mijn ervaring geen garantie voor overcomplexe of oversimpele oplossingen. Wat imho het onderscheid maakt is een stuk zelflerend vermogen. Dat je zelf ziet wat je fout doet, daar van leert, en het beter doet, liefst voor het project is afgerond. Daarvoor moet je kritisch zijn op jezelf en anderen, en continu open blijven staan voor nieuwe technieken en oplossingen. Het andere onderscheid is talent. Het eerste kun je aan werken, het tweede niet.

Het is in feite een kwestie van alert blijven en goed letten op de feedback die je krijgt in je werkzaamheden. Denk bijvoorbeeld aan:

* Ik vind het moeilijk om goed te beschrijven wat dit onderdeel in het ontwerp doet en waarom het nodig is.

* Ik vind het moeilijk om een test voor dit onderdeel op te stellen.

* Ik vind het moeilijk om de oorzaak van deze fout op te sporen.

* Ik zit allemaal code te copy-pasten uit andere onderdelen van het project.

* Ik vind het moeilijk om te beoordelen of deze code nog wel gebruikt wordt, of dat het dode code is.

Dit zijn allemaal vormen van feedback waaraan je kunt afleiden dat er ergens in het project waarschijnlijk een design probleem aanwezig is.

Ook in programmeren geldt dat je pas een goede oplossing kunt opstellen als je een goed beeld hebt van het probleem. Ga dus nooit wisselen van framework of code herschrijven als je niet concreet weet wat de verbetering zou zijn van die activiteit. Hier heb je geen lange onderzoeken voor nodig, in de meeste gevallen is de bovengenoemde feedback al voldoende. Mijn ervaring is dat het nog erg leerzaam is ook.

[PhoneTech]

Alle begin is moeilijk. Ik ben zelf een behoorlijk grote enterprise applicatie aan het programmeren in samewerking met andere bedrijven. Het is als mijn afstudeeropdracht begonnen, en ben nu er full time mee aan de slag. Toen wij (afstudeerder en ik) aan het ontwerp begonnen (losjes gebaseerd op het oude systeem) hebben we veel aan patterns gehad omdat deze gewoon oplossingen bieden voor de problemen waar we tegen aan lopen. Maar nu ik meer in de J2EE wereld zit, en er meer over lees, begin in het systeem simpeler te zien, en ga steeds meer terug naar het KISS princiepe. Voor de afstudeer opdracht hadden we complete client side proxies zitten maken met lazy loading enzo...Uiteindelijk alleen maar getest in jUnit test cases. Nu ik meer over swing en MVC weet, is dat hele proxy verhaal en lazy loading eigenlijk helemaal niet nodig. Zwaar overkill in het begin dus.

Momenteel ben ik bezig de huidige codebase aan het consolideren om een sluitend geheel neer te zetten en daaruit verder te ontwikkelen (vooral logic en geen architectonisch veranderingen meer).

Ben er pijnlijk achter gekomen dat een hoop mooie technieken eigenlijk overkill zijn en deze makkelijker (ouderwetser) op te lossen zijn.

[Alarmnummer]

PhoneTech schreef op dinsdag 29 maart 2005 @ 16:12:
Ben er pijnlijk achter gekomen dat een hoop mooie technieken eigenlijk overkill zijn en deze makkelijker (ouderwetser) op te lossen zijn.

Ouderwets klinkt zo slecht. Wat ik nu eigelijk meer zie (of meer op begin te letten) is dat zwaardere oplossingen de deur uit gaan en vaak voor lichtere en beter werkbare alternatieven wordt gekozen. Dus zo ouderwets is eenvoud niet

[PhoneTech]

bedoel ik...

[djc]

En is Spring dan zo licht? Is Java de ideale taal om lichte elegante applicaties in te bouwen?

* djc schopt maar wat tegen (heilige?) huisjes. Python!

[Alarmnummer]

Python is niks.. taaltje zonder groot platform, zonder applicatie server, zonder integraal lijm zoals Spring. Python is een leuke hobbybob taal, maar hoort niet thuis in serieuze omgevingen.

En ja.. ik heb ook paar regeltjes python geprogrammeerd (ook Jython). Leuk taaltje op hetzelfde nivo als java met paar leuke goodies wat je wel typwerk zal schelen. Maar icm een goeie ide met code completion, syntax checking en refactoring en een compiler.. tja.. dan hoort Python er imho echt niet bij.

Verder wil ik van dit topic geen Java vs Python of Spring vs EJB maken. Het gaat me puur om zware oo oplossingen terwijl lichte vaak net zo goed voldoen (of beter).

[edit]
Ik neem aan dat ik met deze uitspraken genoeg mensen tegen de haren in zal strijken. Maar ik heb het een en ander gedaan met scripttalen, en de 1e snelheids winst die je hebt gaat meestal verloren naar verloop van tijd. Enigste plek waar ik voor mezelf een scripttaal zou willen gebruiken is wat eenvoudige scriptjes op mijn os, of het configureren en lijmen van componenten. Voor Spring is er een Groovy uitbreiding waar je in Groovy de app context in ekaar kan lijmen. Hier zit ik ook wel eens.. wil geen zware classes en alle bijbehorende verplichtingen... ik wil dat met dat verbonden met dat en daarna dat... Dan kan een scripttaal nog wel eens handig zijn. Maar mensen die volledige systemen opzetten in Python verklaar ik terplekke voor gek.

[ Voor 99% gewijzigd door Alarmnummer op 29-03-2005 22:09 ]

[Verwijderd]

Alarmnummer schreef op dinsdag 29 maart 2005 @ 16:23:
Dus zo ouderwets is eenvoud niet

M'n opa wist door jarenlange ervaring al dat simpel meestal het beste is. Hij was bouwvakker/timmerman, en kwam vaak met simpele oplossingen die gewoon goed werkten (waarom een lastige zwaluwstaart verbinding als een simpel extra deuveltje hetzelfde oplevert?).

Eenvoud is niet ouderwets, maar echte eenvoud leer je pas na een hoop ervaring en vallen en opstaan.

Als ik naar code van een paar jaar terug kijk, zie ik ook dat ik gewoon aan het doorslaan was (base classes, en daar pas 4 afgeleiden boven de echte class, helpers en interfaces om bij de DB en de UI te komen, etc.). Sindsdien heb ik wel geleerd dat dat "extra deuveltje" vaak een stuk handiger is.

[MSalters]

Zoijar schreef op maandag 28 maart 2005 @ 17:34:
C++ templates (meta programming). Daar wordt maar mee in het rond gegooid... Je hoeft niet alles compiletime te doen Bovendien snapt niemand de code meer. Het is vaak lastig te gebruiken, omdat je overal lange regels met template specificaties neer moet zetten. Als je toch later ineens iets de gebruiker wilt laten kiezen, in een menu bv, dan kan dat niet. Je moet dan recompilen voor elke andere optie...templates worden veel misbruikt. Vaak wil je ook helemaal geen template oplossing, omdat er toch geen user type in gebruikt kan worden. Dan ga je over op policies, waarvan niet duidelijk is wat daar precies van verwacht wordt. Er is nl. geen formele interface; als je iets fout doet krijg je een ongelooflijk onduidelijke compiler error, die vaak ergens diep in de code ligt.

Is het zo erg? Eerlijk gezegd heb ik dat nooit zo gezien. De ergste dingen die mijn collega's doen is boost pointers in containers stampen. Dat is iets van 3-4 lagen templates, maar nog steeds allemaal erg duidelijk.
Ikzelf heb me weleens bezondigd aan de implementatie van een ABC als template, maar dat was wel in performance-kritische code (ja, dat was een versie 2 nadat v1 te langzaam was gebleken )

Overigens, ik ben benieuwd (theoretisch en praktisch) hoe je dit zou moeten oplossen. Hoe implementeer je generics in een taal zodat je met een paar keywords een compile-time implemnetatie verandert in een run-time? P.S. ik bedoel echte generics, dus niet een compile-time sausje over een run-time Object gebaseerd iets.

[djc]

Alarmnummer schreef op dinsdag 29 maart 2005 @ 21:59:
Python is niks.. taaltje zonder groot platform, zonder applicatie server, zonder integraal lijm zoals Spring. Python is een leuke hobbybob taal, maar hoort niet thuis in serieuze omgevingen.

Ja, want Google is niet serieus...

Alarmnummer schreef op dinsdag 29 maart 2005 @ 21:59:
En ja.. ik heb ook paar regeltjes python geprogrammeerd (ook Jython). Leuk taaltje op hetzelfde nivo als java met paar leuke goodies wat je wel typwerk zal schelen. Maar icm een goeie ide met code completion, syntax checking en refactoring en een compiler.. tja.. dan hoort Python er imho echt niet bij.

Verder wil ik van dit topic geen Java vs Python of Spring vs EJB maken. Het gaat me puur om zware oo oplossingen terwijl lichte vaak net zo goed voldoen (of beter).

Daarom juist! Java, de JVM, J2EE is een zware OO oplossing, terwijl een lichte vaak goed (of beter) voldoet -> Python.

En je hebt het voortdurend over Spring, maar applicaties zonder Spring zijn toch ook lichter dan met Spring? Ik vind het allemaal een tikkeltje krom, maar dat zal wel aan mij liggen.

[jvdmeer]

Een van die buzzwoorden waarin momenteel veel mensen doorschieten is XML. Zelfs data die past in recht-toe-recht-aan CSV of tab-delimited wordt nog geëxporteerd in XML.

[Verwijderd]

Ik houd het even op de technische overkill. Hier zijn een aantal goeie bodems voor:
- eenkennigheid over de beschikbare methodes
- iemand is bezig zich onmisbaar te maken
- stokpaardjes: iemands favoriete oplossing
Deze zaken sluiten elkaar ook nog eens niet uit. Stereotyp is dat iemand met moeite 1 methode geleerd heeft en probeert het hoofd daarmee boven water te houden. De ene methode wordt overal voor ingezet. Omdat de methode op dat gebied betrekkelijk onconventioneel is volgt vaak onmisbaarheid.
Dit soort situaties kunnen tegen gegaan worden met ontwerp. Dan is het zaak "ontwerpen" als favoriete oplossing te bestempelen en achter de schermen de eigen oplossing op te voeren .

Ook kan bij een gedegen aanpak de indruk ontstaan, dat een gedegen aanpak "technologie gedreven" is. Een aantal mogelijke oorzaken zijn:
- complexiteit: het was erg moeilijk om tot een goede methode te komen. Nu deze methode er echter is, begrijpt niemand waarom het zo lang moest duren.
- aggregatieniveau: De oorspronkelijke doelstelling is heel veel korter dan de uitwerking daarvan. Of, het verband tussen probleem en oplossing wordt niet begrepen.
- tijdverschil. Ontwerp vond in het verleden plaats buiten het zicht van de huidige actoren
- tijdsverschil: Het probleem is van zelf verdwenen en kan nu zelfs ontkend worden.
Deze redenen kunnen er toe leiden dat een (ok) project naderhand nog om zeep geholpen wordt. De vervangende methode komt vaak tot stand zonder nieuwe inventarisatie. De personen die om een andere aanpak stonden te schreeuwen vertrekken na een tijdje (bv 4-jarige beleidscyclus). De ontwerpers/bouwers krijgen de shit van beide aanpakken over zich heen. De eindsituatie kan heel veel slechter zijn dan wanneer er helemaal niets gedaan was.

[Verwijderd]

Ik denk dat een groot deel ook afhangt welk soort applicatie je aan het schrijven bent. Ben je een framework aan het schrijven voor het publiek (intern personeel ofwel opensource gemeendschap bijvoorbeeld), of ben je een concrete business applicatie aan het maken.

In het eerste geval durf ik al eens een interface maken met daarvan een implementerende klasse "defaultInterfaceNaam" die eigenlijk altijd wordt gebruikt. Wat is het nut hiervan? Ik vermoed dat collega's of andere programmeurs nog een andere implmentatie kunnen geven aan deze inteface. Moet ik deze interface al beschikbaar maken? Ik denk het wel.

Voor business applicaties zoek je uiteraard naar abstractie (wie wil er nu 100 keer opnieuw zelfde saai data access code schrijven). Maar ik merk op dat ik hier nog wel durf copy-pasten. Dit omdat er geen tijd is om bepaalde code abstract te maken. Voordeel is wel dat het zeer simpel blijft.

[Alarmnummer]

Verwijderd schreef op woensdag 30 maart 2005 @ 11:44:
Ik denk dat een groot deel ook afhangt welk soort applicatie je aan het schrijven bent. Ben je een framework aan het schrijven voor het publiek (intern personeel ofwel opensource gemeendschap bijvoorbeeld), of ben je een concrete business applicatie aan het maken.

Naarmate het een meer herbruikbaar component gaat worden, durf ik wel meer dingen erin te plaatsen die niet direct nodig zijn. Voor een zoekengine platform heb ik bv security policies toegevoegd aan het zoek gedeelte en aan het download gedeelte terwijl daar op dit moment nog geen behoefte aan is. Naarmate ik minder herbruikbare software ga schrijven (de toepassing) ben ik veel strenger en ga geen dingen toevoegen die wel eens handig kunnen zijn. Klant heeft het niet gespecifieerd... ok.. basta..

[ Voor 3% gewijzigd door Alarmnummer op 30-03-2005 11:48 ]

[misfire]

Maar ik merk op dat ik hier nog wel durf copy-pasten. Dit omdat er geen tijd is om bepaalde code abstract te maken. Voordeel is wel dat het zeer simpel blijft.

Als je code gaat copy-pasten kun je deze code niet meer geïsoleerd behandelen. Dus niet meer geïsoleerd testen, documenteren, bugfixen. Ook is het voor andere ontwikkelaars waarschijnlijk handiger om een API te gebruiken dan om te weten welk stuk code er moet worden ge-copy-paste. Om Albert Einstein te quoten: "Keep it simple, but not too simple.". Code copy-pasten heb ik in bovenstaande reactie al onderkend als vorm van feedback.

Spring 1.2 RC1 is overigens beschikbaar!

[Zoijar]

MSalters schreef op dinsdag 29 maart 2005 @ 23:57:
Is het zo erg? Eerlijk gezegd heb ik dat nooit zo gezien. De ergste dingen die mijn collega's doen is boost pointers in containers stampen. Dat is iets van 3-4 lagen templates, maar nog steeds allemaal erg duidelijk.
Ikzelf heb me weleens bezondigd aan de implementatie van een ABC als template, maar dat was wel in performance-kritische code (ja, dat was een versie 2 nadat v1 te langzaam was gebleken )

Overigens, ik ben benieuwd (theoretisch en praktisch) hoe je dit zou moeten oplossen. Hoe implementeer je generics in een taal zodat je met een paar keywords een compile-time implemnetatie verandert in een run-time? P.S. ik bedoel echte generics, dus niet een compile-time sausje over een run-time Object gebaseerd iets.

Laatst had ik dus zoiets:

C++:

template <
    class FormatPolicy = Raw16Format,
    class SourcePolicy = StreamSource,
    template <class Format, class Source>
        class CachingPolicy = NoCache,
    class MappingPolicy = RowMajorMapPolicy,
    class OffsetPolicy = NoOffsetPolicy
>
class Grid :
    public CachingPolicy<FormatPolicy, SourcePolicy>,
    public MappingPolicy,
    public OffsetPolicy
{
// ...

#define TEMPLATE_GRID template <class FormatPolicy, class SourcePolicy, template <class Format, class Source> class CachingPolicy, class MappingPolicy, class OffsetPolicy>
#define CLASS_GRID Grid<FormatPolicy, SourcePolicy, CachingPolicy, MappingPolicy, OffsetPolicy>
#define GRID_MEMBER(r,x) TEMPLATE_GRID r CLASS_GRID::x

GRID_MEMBER(inline void*, itemPointer(const Index& i)) {
    return Cache::requestItem(MappingPolicy::toLinear(OffsetPolicy::map(i)));
}

GRID_MEMBER(inline float, getElevation(const Index& i)) {
    if (isValid(i)) {
        return scale_y_ * FormatPolicy::getElevation(itemPointer(i));
    } else {
        return 0.0f;
    }
}

Het moest per se allemaal inlined en zo snel mogelijk (30% van de tijd oid zat in die kleine functies, ij realtime decompressie nog meer) Maar het moest ook uitbreidbaar etc zijn, om verschillende oplossingen en combinaties te kunnen testen; waarvan er waarschijnlijk maar eentje per systeem werd gekozen. Policies leken me dus wel verantwoord...aan het begin...totdat het langzaam uitgebreid werd, en tevens langzaam een nachmerrie werd. Bv. omdat het toch wel handig was om de gebruiker het formaat te kunnen laten kiezen, en het al dan niet compressed sources te gebruiken. Misschien had ik toch beter gewoon een ABC structuur op kunnen zetten. Of gewoon verschillende source files maken, en dan om beurten die erin linken. Op zich was het een mooie oplossing; maar helaas werd het zo complex dat het, zeker voor een buitenstaander, niet meer handelbaar was.

[EfBe]

Ik vind dat er voornamelijk teveel ge-ouwehoerd wordt. Zodra een marketing-<lame term here> een nieuwe term de wereld in slingert, kakelt de hele goegemeente erover. Dit is beter, dat is onzin...

Allemaal zo betrekkelijk. Net alsof men vroeger geen software kon maken want toen kende men nog niet <insert buzzword here> en <insert other random buzzword here>. De handen uit de mouwen en typen in die editor, kloppen todat je handen blauw zien, dat zouden meer mensen moeten doen.

[H!GHGuY]

ik was onlangs voor die GoT contest wat voorbereidende code aan het kloppen, en ik had een hele klasse geimplementeerd, die ik in een andere ging gebruiken, en toen ik de code schreef om die handel te gebruiken had ik: oei, dit heb ik eigenlijk niet nodig.
code aan de kant, maar bijhouden. later kan ze van pas komen.

reden? geen duidelijke planning gemaakt.
dus:
- maak een goeie planning
- stel je bij alles de vraag: heb ik dit zo nodig?
- deel alles op in zo klein mogelijke elementaire problemen
dat 1 functie de raarste dingen doet die denkbaar zijn, dat maakt geen reet uit als ie maar goed geimplementeerd, getest en beschreven is.

C++:

// geeft een tabel met aantal + 1 voorspellingswaardes voor een gehalveerde intervalgrootte
// return[5] = voorspelling (waarden[4], waarden[5]
int* geefVoorspellingsWaarde(int* waarden, int aantal){  // plaats hier je random obscure code }

is perfect ok, als ze is getest, goed geimplementeerd en goed beschreven
- elk probleem is een nieuw probleem. het kleinste detail kan een methode elimineren
-...

[Verwijderd]

En ik vermoed dat ik niet de enige ben die zich dat soort dingen afvraagt: "Kan het beter? En hoe dan?".

En dat is juist weer goed, zo leer je jezelf verbeteren (althans lijkt mij)

[pjonk]

XML wordt door sommigen ook gezien als een buzz Word, maar waarom zou bijv. Microsoft er dan zoveel energie om deze techniek zo intensief in .NET te ondersteunen? Ik ben zelf wel een voorstander van het gebruik van uniforme standaarden. Een goed opgezette XML structuur kan bijna iedereen wel lezen en dat kan je niet altijd zeggen van andere inconsistente bestandsformaten. Bijv een CSV file heeft vaak een komma als delimiter, maar soms ook weer een puntkomma.

[raptorix]

Ik erger me dood aan mensen die nog eens een extra template systeem bovenop een CMS gaan bouwen wat al een template systeem heeft en vervolgens als excuus geven dat het template systeem van CMS X te traag dan wel te lomp is.

[misfire]

EfBe schreef op woensdag 30 maart 2005 @ 21:11:
Ik vind dat er voornamelijk teveel ge-ouwehoerd wordt. Zodra een marketing-<lame term here> een nieuwe term de wereld in slingert, kakelt de hele goegemeente erover. Dit is beter, dat is onzin...

Allemaal zo betrekkelijk. Net alsof men vroeger geen software kon maken want toen kende men nog niet <insert buzzword here> en <insert other random buzzword here>. De handen uit de mouwen en typen in die editor, kloppen todat je handen blauw zien, dat zouden meer mensen moeten doen.

Het is inderdaad zo dat er veel geouwehoerd wordt, voornamelijk door mensen die graag interessant willen doen om zo een hoop geld te kunnen verdienen. Dat is niet alleen in de ict zo, maar zo gaat het overal. Men trapt er nog steeds in, anders zou er heel wat minder oh aanwezig zijn. Maar mensen vinden het nu eenmaal prettig om voor de gek gehouden te worden (kijk naar politiek, geloof, reclame, enz). En als andere mensen onzin verkopen is het ook een stuk makkelijker om zelf niet altijd hoeven na te denken.

Een verschil met "vroeger" is denk ik wel dat de nieuwere ontwikkelingen steeds meer eisen van de organisatie en bedrijfsprocessen. XML als technische standaard om gegevens uit te wisselen is leuk, maar heeft een organisatie nodig waarin ook een standaard wordt geaccepteerd, onderhouden en uitgedragen. SOA als architectuur uitgangspunt is aardig, maar vereist een bepaalde modulariteit in bedrijfsprocessen, formele definities van stappen en verregaande onderlinge afspraken tussen afdelingen en bedrijven. Als je echt met XML/SOA aan de gang gaat denk ik dat je meer kans op succes hebt met een blauwe overlegtong en/of een blauwe vergaderbips. Op eigen houtje iets moois in elkaar draaien is dan niet meer voldoende.

"Vroeger" stond alles in een serverhok en werd er net zo lang geklooid totdat mensen niet meer belden dat het anders moest. Om de nieuwe technieken tot een succes te maken zal de organisatie zelf ook aan moeten passen. Voor veel organisaties is SOA/XML imho daarom zowieso al een vorm van technische overkill. De kosten om de organisatie voldoende te formaliseren en aan te passen voor deze technieken wegen lang niet altijd op tegen de beloofde besparingen in onderhoud, verkorte doorlooptijd en beter inzicht.

[farlane]

misfire schreef op donderdag 31 maart 2005 @ 11:03:
De kosten om de organisatie voldoende te formaliseren en aan te passen voor deze technieken wegen lang niet altijd op tegen de beloofde besparingen in onderhoud, verkorte doorlooptijd en beter inzicht.

Vind ik een raar uitgangspunt. Naar mijn idee moet de techniek zich aanpassen aan het bedrijfsproces ( als dat proces correct is ), niet andersom.

[EfBe]

misfire schreef op donderdag 31 maart 2005 @ 11:03:
"Vroeger" stond alles in een serverhok en werd er net zo lang geklooid totdat mensen niet meer belden dat het anders moest. Om de nieuwe technieken tot een succes te maken zal de organisatie zelf ook aan moeten passen.

Is dat niet automatisering als doel zien ipv als middel? De organisatie efficienter laten werken en zo kosten besparen, DAT is het doel, hoe daar te komen moet worden onderzocht en EEN van de resultaten KAN zijn, het gebruik van IT en indien dat wordt gekozen als oplossing kan dan pas worden gekozen uit een scala aan technieken.

Er is in de loop der tijd een compleet fout beeld ontstaan van wat IT is en waar het eigenlijk voor dient. Een kantoor hebben zonder computers is ondenkbaar, maar het plaatsen van computers en software is niet synoniem voor het verbeteren van efficiency.

Zo is het ook met IT technieken: elke toegepast moet worden hangt helemaal af of het het doel dient, nl. het efficienter maken van de organisatie. Discussie welke techniek gebruikt dient te worden dient dan ook in DIE context gedaan te worden, echter de werkelijke context is vaak 'dient het het doel van de uitvoerende IT-organisatie', en daar wringt nu juist de schoen.

[misfire]

farlane schreef op donderdag 31 maart 2005 @ 11:24:Vind ik een raar uitgangspunt. Naar mijn idee moet de techniek zich aanpassen aan het bedrijfsproces ( als dat proces correct is ), niet andersom.

Een ICT oplossing is meestal een combinatie van techniek en aanpassingen in het bedrijfsproces. Techniek is ondersteunend voor een bedrijfsproces, en is/wordt een onderdeel van het bedrijfsproces. Dat betekent in de meeste gevallen dat je het bedrijfsproces wel degelijk aan moet passen zodra je een nieuwe ict oplossing voor dit proces introduceert. Dat is ook goed, want als er helemaal niets aan het proces zou hoeven te worden veranderen zou het ook niet beter worden ondersteund door de techniek.

De verandering zou echter zo veel mogelijk ter ondersteuning van het proces moeten zijn, en niet ter ondersteuning van de techniek. Ik stelde daarom ook dat SOA en XML voor veel bedrijven nog niet interessant zijn, omdat ze de onderliggende principes van flexibiliteit en uitwisselbaarheid niet in hun organisatie hebben geregeld, en het is dus technische overkill voor ze is (het topic waar het over ging).:)

[misfire]

EfBe: XML en SOA zijn technieken bedacht om bepaalde doelstellingen voor organisaties te kunnen verwezenlijken. Deze doelstellingen zullen in de organisatie zelf ook moeten worden ingebed om succesvol te kunnen zijn. Dit is op zich zo voor iedere techniek. Een database werkt ook niet als je alles op papier blijft schrijven bijvoorbeeld. Wil je SOA/XML een uitwisselbare en flexibele ondersteuning van je bedrijfsprocessen hebben, dan zullen je processen zelf ook uitwisselbaar en flexibel moeten zijn, anders wordt dit doel nooit bereikt.

De vraag is dus niet: waarom dwingt SOA/XML mijn organisatie tot bepaalde aanpassingen? maar eerder: waarom kies ik als organisatie voor SOA/XML? Helaas kom je op het antwoord op de twede vraag vaak die ouwehoeren die jij noemde weer tegen.

[farlane]

misfire schreef op donderdag 31 maart 2005 @ 13:47:
[...]
Een ICT oplossing is meestal een combinatie van techniek en aanpassingen in het bedrijfsproces. Techniek is ondersteunend voor een bedrijfsproces, en is/wordt een onderdeel van het bedrijfsproces. Dat betekent in de meeste gevallen dat je het bedrijfsproces wel degelijk aan moet passen zodra je een nieuwe ict oplossing voor dit proces introduceert.

Komt dat niet doordat men tijdens zo'n 'automatiserings project' eens de tijd neemt om goed naar het proces te kijken, en men aan het denken gezet wordt over 'waarom doen we het eigenlijk op die manier? Kan dat niet handiger?'

Zoals Efbe al aangaf ( en jijzelf ook min of meer ), het toepassen van een techniek moet niet het doel hebben de ICT firma's kas te spekken maar de klant zo goed mogelijk te helpen.

( Overigens denk ik dat van juist die technieken die jij noemt vrij moelijk uit te leggen is waarom ze toegepast zouden moeten worden, maar dat is ook min of meer wat jij zegt )

[Verwijderd]

farlane schreef op vrijdag 01 april 2005 @ 10:08:

[...]

( Overigens denk ik dat van juist die technieken die jij noemt vrij moelijk uit te leggen is waarom ze toegepast zouden moeten worden, maar dat is ook min of meer wat jij zegt )

Zoals eerder al terecht opgemerkt hebben ICT'ers snel de neiging om technology-driven ipv business-driven te redeneren. Als het moeilijk uit te leggen is waarom XML of SOA of <<zoals EfBe al aangeeft, insert random technology here >> een onderdeel van de oplossing voor deze business-case is, dan geef je daarmee zelf al aan dat je vanuit de technologie redeneert en niet vanuit het functionele probleemgebied.

Het is juist de kunst om bij een functioneel probleemgebied de best passende oplossing te vinden. Deze oplossing kan deels liggen in het aanpassen van het bedrijfsproces en deels in het aanpassen van de ondersteuning van dat bedrijfsproces. Deze ondersteuning zal (gedeeltelijk) bestaan uit ICT. ICT is hier dus volledig ondergeschikt aan het bedrijfsproces.

Hoe het probleem opgelost wordt is dan ook niet bijster interessant. De gekozen implementatie zal alleen wel logisch dienen te volgen uit het geïdentificeerde probleem en de gekozen oplossingsrichting.
Voorgaande houdt automatisch in dat een gekozen techniek niet hoeft te worden uitgelegd, omdat deze het probleem op overtuigende wijze oplost.

_{En ja, ik ben me ervan bewust dat het in de praktijk niet altijd zo eenvoudig is, maar dat betekent niet dat je niet naar bovenstaand scenario moet streven...}