Kan Java uberhaupt productief zijn?

[OMX2000]

Als eerste wil ik ff kwijt dat ik deze topic niet open als flamebait. Ik wil gewoon serieus weten of Java tegenwoordig echt wel productief kan zijn.

In een ander topic stelde ik dat Java een stuk minder productief is dan .NET. Dit baseerde ik vooral uit mijn eigen ervaringen tijdens het bouwen van een grote SOA oplossing. De .NET en Java ontwikkelaars moesten soortgelijke services bouwen. Hierbij ging het in .NET opvallend vaak sneller.

Nu ben ik rond gaan vragen bij collega architecten/consultants/senior developers wat hun ervaring was. En om te vergelijken werd er natuurlijk weer gewezen op FPA (functie punten analyse... damn I hate those). En over het algemeen werd gesteld dat je met Java ca. 12 uur per Functie Punt doet, .NET 6-7 per Functie Punt, en Oracle 4-5 per Functie Punt. Opvallend is dat er nog weinig bekend was, op het gebied van FPA, over bijv. Ruby on Rails.

Iets wat gesteld werd was dat Java programmeurs het heeerlijk vinden om te programmeren, en er niet per se veel aan doen om productief te zijn. Nu vroeg ik mezelf af of het uberhaupt niet geld voor alle 3GL (Java, C#, Smalltalk etc) talen. Wil je een substantiële hogere productiviteit zul je denk ik meer richting model gedreven omgevingen moeten, of DSL's die toegespitst zijn op een bepaald domein. Talen waar je veel plumbing moet doen, verliezen productiviteit doordat een programmeur veel code schrijft die direct gerelateerd is aan de gevraagde functionaliteit (laten we het non functional code noemen.). Daarom zie je ook dat static typed talen zo enorm veel patterns (GoF factory pattern, strategy pattern, etc) hebben die er puur voor zijn om je code overzichtelijk flexibel, en gestructureerd te houden. Er zijn tig frameworks om delen van applicaties te genereren/configureren/declareren.

Maar wat in deze tijd van crisis sowieso een goede vraag is om te stellen is : "Zijn we met de huidige talen/platforms wel op het juiste pad? Moet er niet compleet out of the box gedacht worden?"

Ik begin bewust met Java aangezien het in de praktijk blijkt het minst productieve platform te zijn. Dus hoe kan de industrie nu al jaren accepteren dat er zo langzaam gewerkt wordt? Ik heb me echt dood lopen ergeren aan het feit dat wanneer er nieuwe dingen gevraagd worden van Java ontwikkelaars, dat opeens alle wielen opnieuw uitgevonden moeten worden.

Voorbeeld van een discussie tussen een architect en een Java ontwikkelaar

Architect: Ik zou graag 3 services willen die ik via een centrale broker wil ontsluiten
Java Dev: Zou je niet willen kijken naar de open-source broker X in Java
Architect: Nou we hebben al een broker
Java Dev: Ja maar deze kunnen we helemaal zelf aanpassen, en toespitsen op on gebruik
Architect: Da's leuk, maar we hebben hier een dikke dure broker staan, dus we gebruiken die
Java Dev: Ik moet nog wel even 2 weken hebben voor spike's (proof of conceptjes) om te kijken welke framework ik ga gebruiken voor xml parsing, webservice stack.
Architect: Maar er is toch al een standaard
Java Dev: Ja, maar het is gebleken dat dat niet erg lekker werkt. En we willen nu wat anders proberen.
Java Dev: En daarbij hebben de huidige ontwikkelaars geen ervaring met Hibernate, dus die moeten nog een paar dagen inwerken.
Architect: Maar is het niet beter om aan standaarden te vast houden zodat we niet steeds tijd kwijt zijn aan onderzoek
Java Dev: Ja maar we moeten toch echt kijken hoe we dit specifieke probleem technisch oplossen.

Nu zullen een aantal mensen zeggen dat als je een fabriek/ontwikkelstraat hebt, dat de keuzen voor je gemaakt zijn. En dat is deels waar, maar in de praktijk zijn die straten technologie georienteerd. Wat dus betekend dat ze zich vooral focussen op het technische probleem domein. Wanneer ze geconfronteerd worden met een nieuwe toepassing die functioneel lijkt op een andere, maar technisch anders is. Moet het wiel opnieuw uitgevonden worden. De programmeur ziet niet direct wat de beide toepassingen gemeen hebben.

Nu ben ik zelf van mening dat programmeerwerk maar 30% van de kosten van een gemiddeld project behelzen. De rest gaat in het uithoren van de klant, functioneel testen, project management, deployen, requirements/specificaties opstellen, en communicatie.

Dus ik zie vooral heil in methoden en platforms die zowel het programmeerwerk als beheer, requirements management, test en deployment omvatten. En dit alles in een vaste set aan tools aanbiedt. Waarbij liefst op een hoger abstractie niveau dan de gangbare talen zoals C# en Java geprogrammeerd wordt. Er wordt gefocussed op het probleem domein van de business. Vanuit dat domein worden er vertalingen gemaakt naar pattern en practices. Deze patterns zijn van een hoger niveau dan de GoF patterns, en zullen zich dus niet uitlaten over techniek. De patterns worden immers al onderkend door het ontwikkelplatform, en daar worden ze, met de kennis uit de context, vertaald naar de best passende technische oplossing.

Zo'n platform, is niet iets wat je even erbij ontwikkeld. Daar kun je een aardig bedrijf rondom bouwen. Dus al die kleine initiatieven overal en nergens lijden meestal tot miniscule verbeteringen in productiviteit. Maar een goede set aan tools en processen, die volgens een bewezen standaard werken. Die dus ook ontwikkeld worden met als doel om de productiviteit binnen een project te verhogen, heeft denk ik de toekomst.

[Mr_Light]

in bijna alles wat je aanhaalt komt niet overeen met mijn ervaring en je bent nogal aan het cherry picken. volgens mij. En voor de rest ga ik lekker de kat uit de boom kijken want ik vermoed dat dit toch wel heel snel een flame feest word.

[Gomez12]

Tsja, simpel gesteld een vaste set aan tools biedt meer productiviteit zolang je binnen de toolset blijft.
Zolang je binnen de toolset blijft kan je idd er een perfect platform/bedrijf omheen bouwen.

Maar een probleem is dat een toolset mensen afstompt ( als we nou even deze tool achter die tool knopen, daarachter weer een ander tool, dan blijven we binnen de toolset het performt voor geen meter meer, maarja het is makkelijker dan een nieuwe tool bouwen en het doet toch wat de klant vraagt )

Hoe meer je de toolset gaat abstraheren, hoe meer de performance van iets net buiten de toolset eronder leidt. En hier blijft het altijd een discussie over ( de hardware wordt steeds sneller, maar gaat dit wel snel genoeg )

Op dit moment ben ik er nog steeds van overtuigd dat iemand die perfect in assembly is iets beter performant kan maken ( voor mijn systeem ) dan een .Net of een java oplossing, moet het op meerdere pc's draaien dan krijg je de discussie hoeveel kost het om de optimalisaties van alle processoren in assembly te programmeren versus de hardware kosten om het ook op .Net / Java even snel te laten draaien. En dat valt weer goedkoper uit voor .Net / Java

[OMX2000]

Mr_Light schreef op donderdag 04 juni 2009 @ 00:29:
in bijna alles wat je aanhaalt komt niet overeen met mijn ervaring en je bent nogal aan het cherry picken. volgens mij. En voor de rest ga ik lekker de kat uit de boom kijken want ik vermoed dat dit toch wel heel snel een flame feest word.

Dat kan ook, ik zeg niet dat Java niet productief kan zijn. Ik zeg alleen dat uit ervaringcijfers blijkt dat Java gemiddeld minder productief is. Da's geen rocket science, en daar is niks subjectiefs aan. Je meet het, en hoe meer metingen je hebt hoe betrouwbaarder het is.

[BCC]

OMX2000 schreef op donderdag 04 juni 2009 @ 00:46:
[...]
Dat kan ook, ik zeg niet dat Java niet productief kan zijn. Ik zeg alleen dat uit ervaringcijfers blijkt dat Java gemiddeld minder productief is. Da's geen rocket science, en daar is niks subjectiefs aan. Je meet het, en hoe meer metingen je hebt hoe betrouwbaarder het is.

Sorry, maar als er iets niet te meten is dan is het de productieviteit van een programmeur. Bij programmeren kan het wijzigen van 1 teken kan soms meer toevoegen dan het toevoegen van 1000. Een programmeur is geen typiste die zo snel mogelijk de invulling van functies moet intikken.

[ Voor 6% gewijzigd door BCC op 04-06-2009 00:53 ]

[OMX2000]

Gomez12 schreef op donderdag 04 juni 2009 @ 00:42:
Tsja, simpel gesteld een vaste set aan tools biedt meer productiviteit zolang je binnen de toolset blijft.
Zolang je binnen de toolset blijft kan je idd er een perfect platform/bedrijf omheen bouwen.

Maar een probleem is dat een toolset mensen afstompt ( als we nou even deze tool achter die tool knopen, daarachter weer een ander tool, dan blijven we binnen de toolset het performt voor geen meter meer, maarja het is makkelijker dan een nieuwe tool bouwen en het doet toch wat de klant vraagt )

Hoe meer je de toolset gaat abstraheren, hoe meer de performance van iets net buiten de toolset eronder leidt. En hier blijft het altijd een discussie over ( de hardware wordt steeds sneller, maar gaat dit wel snel genoeg )

Op dit moment ben ik er nog steeds van overtuigd dat iemand die perfect in assembly is iets beter performant kan maken ( voor mijn systeem ) dan een .Net of een java oplossing, moet het op meerdere pc's draaien dan krijg je de discussie hoeveel kost het om de optimalisaties van alle processoren in assembly te programmeren versus de hardware kosten om het ook op .Net / Java even snel te laten draaien. En dat valt weer goedkoper uit voor .Net / Java

Je zegt het zelf al... Je programmeert tegenwoordig niet meer in assembly omdat je productiever wilt zijn, en niet vast wilt zitten aan een platform. Ik vind persoonlijk assembly ook leuk, en stoer. Maar het kost bakken met tijd. .Net/Java net zo, het is leuk, maar ik denk dat er op een hogere abtractie niveau sneller ontwikkeld wordt en je niet meer vast hoeft te zitten aan een platform (.net/java).

Er zijn in de praktijk al voorbeelden van producten die dit bieden. Alleen zijn deze nog lang niet zo bekend. Deels omdat programmeurs echt helemaal gek zijn van Java en .NET, en zolang IBM, Oracle/Sun, Microsoft er niet achter gaan staan gaan de grote bedrijven ook niet zomaar overstag.

En uit eigen ervaring met zo'n platform, je simpelweg bijna 2 keer sneller ontwikkeld dan in .NET. En dan heb ik het nog niet eens over een beheersituatie. Wat altijd een drama is, en bakken vol met geld kost omdat mensen altijd moeite hebben om elkaar code goed te begrijpen.

[OMX2000]

BCC schreef op donderdag 04 juni 2009 @ 00:51:
[...]


Sorry, maar als er iets niet te meten is dan is het de productieviteit van een programmeur. Bij programmeren kan het wijzigen van 1 teken kan soms meer toevoegen dan het toevoegen van 1000. Een programmeur is geen typiste die zo snel mogelijk de invulling van functies moet intikken.

Een programmeur realiseert functionaliteit. Tenzij je meedoet aan een een of andere haiku wedstrijd, is dat het belangrijkste wat een programmeur doet.

Je meet dus hoeveel functionaliteit een programmeur kan realiseren in een bepaald tijdsbestek. Ik bedoel dus niet hoeveel regels code een programmeur kan uitspugen. Dat wordt soms ook meegenomen, maar zonder daar ook nog 1001 metrics bij te gebruiken zegt dat natuurlijk niks. Iemand kan zich helemaal dol copy-and-paste, en absoluut niks toevoegen qua functionaliteit.

[Leftblank]

OMX2000 schreef op donderdag 04 juni 2009 @ 00:46:
[...]


Dat kan ook, ik zeg niet dat Java niet productief kan zijn. Ik zeg alleen dat uit ervaringcijfers blijkt dat Java gemiddeld minder productief is. Da's geen rocket science, en daar is niks subjectiefs aan. Je meet het, en hoe meer metingen je hebt hoe betrouwbaarder het is.

Niet het laatste bericht, maar wel een punt om in te haken in de discussie. Je spreekt hier over 'ervaringscijfers' en presenteert dit idee vervolgens als pure metingen; hebben we 't hier nu over ervaring of kun je ons een bron geven van de cijfers? (Het neigt nu wat naar "Uit mijn ervaring blijkt dat code in Java 12.13% eenvoudiger te debggen is dan C#", wat lastig discussieren is.)

[OMX2000]

Leftblank schreef op donderdag 04 juni 2009 @ 01:24:
[...]

Niet het laatste bericht, maar wel een punt om in te haken in de discussie. Je spreekt hier over 'ervaringscijfers' en presenteert dit idee vervolgens als pure metingen; hebben we 't hier nu over ervaring of kun je ons een bron geven van de cijfers? (Het neigt nu wat naar "Uit mijn ervaring blijkt dat code in Java 12.13% eenvoudiger te debggen is dan C#", wat lastig discussieren is.)

Het zijn ervaringcijfers die komen uit projecten die gedaan zijn door het bedrijf waarvoor ik werk. Dus niet mijn eigen ervaringen, maar wel gebaseerd op heel veel projecten de afgelopen decennia (dus niet alleen Java en .NET, maar ook Cobol, Coolgen etc). Ik heb nooit een FPA gedaan. Ik kan dit zelf dus niet onderschrijven met cijfers.

Dus de productiviteit gebaseerd op FPA is dus niet zomaar uit de lucht gegrepen. Mijn eigen ervaring mag iedereen met een korreltje zout nemen. En mag je als "mening" classificeren, niet zozeer een feit dus.

Ik probeer hier ook niet een bepaald platform zwart te maken. Ik ben zelf vooral .NET-er, maar ik geloof echt wel dat je in Ruby sneller kunt ontwikkelen dan in .NET. Ik was weer wel verbaasd over het feit dat er in met Oracle tools/platform zo'n hoge productiviteit behaald kon worden. Dus veel is gebaseerd op onderbuik gevoel, maar ik denk niet dat ik er echt heel erg naast zit.

En zoals ik al zei .NET/Java zal binnen een aantal jaar minder gangbaar zijn, zodra er nieuwe talen komen die veel productiever zijn, maar toch flexibel en krachtig genoeg om zonder een regel Java of C# een complexe toepassing te kunnen bouwen.

[Sebazzz]

Is het niet meer cultuur? Dat Java programmeurs bepaalde technieken niet of wel toepassen tegenover C# programmeurs die misschien door o.a. MSDN wel of niet gestimuleerd worden om dit te doen? En hoe zit het met de IDE's bijvoorbeeld, daar zit ook een stuk in lijkt me.

[BCC]

Het zou maar zo kunnen zijn dat jullie Java programmeurs veel meer nadruk leggen op performance, defensief programmeren of dingen future proof maken. Zeker omdat zij blijkbaar wel nadenken over de tools die ze willen gebruiken of de inrichting van zaken.

[ Voor 26% gewijzigd door BCC op 04-06-2009 08:23 ]

[Remus]

OMX2000 schreef op donderdag 04 juni 2009 @ 00:46:
[...]


Dat kan ook, ik zeg niet dat Java niet productief kan zijn. Ik zeg alleen dat uit ervaringcijfers blijkt dat Java gemiddeld minder productief is. Da's geen rocket science, en daar is niks subjectiefs aan. Je meet het, en hoe meer metingen je hebt hoe betrouwbaarder het is.

Kan je dat onderbouwen met een verwijzing naar een onderzoek. Want op dit moment lijkt het er meer op dat je het wel eens meegemaakt hebt dat .NET sneller ontwikkelde dan Java. Ik denk dat dat voornamelijk ligt aan de ontwikkelaars zelf (en hun managers) dan aan het platform.

[roy-t]

BCC schreef op donderdag 04 juni 2009 @ 08:22:
Het zou maar zo kunnen zijn dat jullie Java programmeurs veel meer nadruk leggen op performance, defensief programmeren of dingen future proof maken. Zeker omdat zij blijkbaar wel nadenken over de tools die ze willen gebruiken of de inrichting van zaken.

Nu gebruik ik zelf voor werk/hobby .Net en voor studie Java en juist dingen zoals defensie programmeren zitten erg goed in het standaard framework van .Net dat gaat super makkelijk ook zit er gewoon vreselijk veel functionaliteit gemaakt door 1 fabrikant (dus ongeveer zelfde regels, zelfde commentaar, zelfde plek om meer informatie te vinden (MSDN) en zelfde plek om naar functionaliteit te zoeken) wat .Net op de start een groot voorbeeld geeft.

Voor Java moet je dat toch vaak zoeken bij een speciaal framework, een framework voor XML parsing bijvoorbeeld en dan weer een framework voor x en dan voor y. Dan zul je voor elk frameworkje dat je gebruikt net even wat langer kwijt zijn omdat je telkens aan net iets andere regels en patronen gebonden bent ook is er niet 1 MSDN en zal een developer die de tool niet kent eerst even moeten googlen ofzo om te zoeken waa de 'msdn' voor dat framework is.

Natuurlijk zijn dit kleine dingetjes en ik denk dat als je een software engineer of iemand anders een flinke tijd de opdracht geeft om 1 grote toolset samen te stellen voor dit soort zaakjes en je daarna hier aan vasthoud, eigen documentatie maakt (met minstens een link naar de documentatie van elk framework) en er voor zort dat nieuw personeel hier meteen op ingewerkt wordt je net zo snel kan zijn als .Net. Maar zoals te zien is in TS opening gebeurt dit niet altijd.

Mr_Light schreef op donderdag 04 juni 2009 @ 00:29:
in bijna alles wat je aanhaalt komt niet overeen met mijn ervaring en je bent nogal aan het cherry picken. volgens mij. En voor de rest ga ik lekker de kat uit de boom kijken want ik vermoed dat dit toch wel heel snel een flame feest word.

Leuk dat je dit constateert maar misschien zou je iets kunnen toevoegen aan dit topic ipv op het flame feest afwachten door die ervaringen dan te posten want nu klink je imho als "waaaaa iemand zegt iets kuts over java/iets goeds over .net... boehoe niet waar PUNT. Ik ga ergens anders heen"

[Alarmnummer]

Voor mijn werk kom ik bij verschillende type organisaties die oa Java gebruiken. Ze lopen uiteen van de wat meer stoffige organisaties zoals banken tot kleine high tech organisaties die in een bepaalde niche zitten. Wat me opvalt is dat ik een erg groot verschil in productiviteit zie, ook al gebruiken ze Java. Wat mij verder opvalt is dat de grotere organisaties vaak gaan voor bloated Java paketten van de grote jongens (IBM en Oracle) en dat de algehele productiviteit vaak bedroevend laag is. Kleinere organisties, die vaak verschillende open source producten gebruiken (seam, spring, hibernate etc). komen er veel beter vanaf.

Dus om alle Java teams over 1 kam te scheren gaat wellicht iets te ver.

Er zijn wel een paar dingen die me opvallen tov .NET:
- de Java community is veel actiever en innoverender is. Dat is deels de kracht van Java, maar ook een valkuil voor veel organisaties want er zijn veel keuzes om te maken (er zijn bv meer dan 100 webframeworks voor Java).
- de Java taal staat al een lange tijd stil staat en gezien de overname van Sun door Oracle, zal dit ook zeker niet gaan verbeteren. Het zijn atm vooral kleine tweaks in de taal, of het makkelijker maken voor andere talen om op de JVM te draaien. Maar wereldschokkend is het niet. c# is Java als taal al lang geleden gepaseerd.

Ik denk dat de Java taal zijn beste tijd heeft gehad.

[ Voor 11% gewijzigd door Alarmnummer op 04-06-2009 10:58 ]

[Zoijar]

Eerlijk gezegd snap ik je punt niet helemaal. Probeer je nou te zeggen dat het beter zou zijn om een compleet bestaand framework te gebruiken, dat alles doet van requirements tot deployment, in plaats van zelf iets te schrijven in Java, dan wel C#? Natuurlijk is dat zo, maar helaas bestaat dat meestal niet voor je specifieke probleem. Laatst sprak ik ook met iemand over nieuwe functionaliteit in onze bedrijfssoftware, en volgens hem was alles een paar extra regeltjes code. Echter, hij had het vaak over compleet verschillende technische problemen, die echt compleet nieuwe oplossingen vereisten, zonder dat blijkbaar door te hebben. Ik zou met liefde zo'n framework dat jij beschrijft gebruiken, maar dat bestaat vrijwel nooit voor een praktisch, niet trivaal probleem. Frameworks zoals .NET gaan juist de goede kant op volgens mij. Het moet algemeen genoeg bliiven zodat het voor iedereen nuttig blijft, en krachtig genoeg zodat je er makkelijk veel uiteenlopende problemen in kan oplossen. Je kan juist tegenwoordig al zo makkelijk alles aan elkaar knopen met een minimale hoeveelheid code.

Het hele idee van visual studio, sql server en .NET en al die andere (java) initiatieven is toch juist om zo'n framework te creeeren? Dat is alleen erg moeilijk. Een aardig voorbeeld is ASP.NET. Op het eerste gezicht lijkt dat geweldig: je kan een hele website in elkaar zetten door wat standaard componenten aan elkaar te verbinden in een GUI. Mij leek het ideaal, niet meer steeds hetzelfde opnieuw hoeven te doen. Maar het bleek voor mij al snel dat als je iets meer wilt dan een standaard website, dat je dan toch alles zelf moet schrijven. Het doet namelijk meestal net niet wat je wilt, en bestaande code in zo'n framework aanpassen is een drama. Dat duurt vaak langer en kost meer dan het zelf opnieuw maken.

[Hydra]

OMX2000 schreef op donderdag 04 juni 2009 @ 00:46:
Dat kan ook, ik zeg niet dat Java niet productief kan zijn. Ik zeg alleen dat uit ervaringcijfers blijkt dat Java gemiddeld minder productief is. Da's geen rocket science, en daar is niks subjectiefs aan. Je meet het, en hoe meer metingen je hebt hoe betrouwbaarder het is.

"Ervaringscijfers" van wie? Kun je ook even met bronnen komen? Ben erg benieuwd naar het onderzoek en hoe en door wie dit uitgevoerd is namelijk.

[Creepy]

Architect: Maar er is toch al een standaard
Java Dev: Ja, maar het is gebleken dat dat niet erg lekker werkt. En we willen nu wat anders proberen.

Even heel erg kort door de bocht:

Je java devvers zijn te eigenwijs en weigeren standaard zaken te gebruiken terwijl jullie .NET devers dat waarschijnlijk wel doen. Is dat een probleem van Java of van de devvers?

Dus kan Java productief zijn? Ja, net zo productief als .NET. Het hangt natuurlijk wel af van de devvers. Blijkbaar werken jullie .NET devvers sneller dan de Java devvers. Probeer eens te achterhalen waar dat aan ligt i.p.v. het direct te wijten aan Java.

[ Voor 25% gewijzigd door Creepy op 04-06-2009 11:00 ]

[OMX2000]

Hydra schreef op donderdag 04 juni 2009 @ 10:36:
[...]


"Ervaringscijfers" van wie? Kun je ook even met bronnen komen? Ben erg benieuwd naar het onderzoek en hoe en door wie dit uitgevoerd is namelijk.

Ik werk voor Atos Origin, daar wordt constant gekeken naar hoe productief een bepaald platform nu echt is. Bijv. om te zien hoe effectief het is om een project naar India te sturen. Of om te weten of het zin is om te investeren in een nieuw platform of taal.

Ik zal ook even rondvragen of er onafhankelijke onderzoeken zijn gedaan.

[Zoijar]

Creepy schreef op donderdag 04 juni 2009 @ 10:58:
Even heel erg kort door de bocht:

Je java devvers zijn te eigenwijs en weigeren standaard zaken te gebruiken terwijl jullie .NET devers dat waarschijnlijk wel doen. Is dat een probleem van Java of van de devvers?

Of het zijn devvers met ruime ervaring, die weten dat de standaard oplossing niet lekker werkt en waarschijnlijk meer werk gaat kosten in productie en onderhoud dan een andere, niet standaard oplossing. Maar zoals gewoonlijk wil het management weer eens gebruiken "wat er al is", want dat gebruiken we toch altijd, en het kost niets extra? Zo klinkt die hele discussie mij in de oren

[Creepy]

In mijn oren klinkt het iets anders. Maar ik heb zelf dan ook te vaak gezien dat er iemand roept "ja maar het werkt niet helemaal lekker, ik pak iets totaal anders" of ""ja maar het werkt niet helemaal lekker, ik herschrijf het wel vanaf scratch" terwijl de bestaande zaken eigenlijk prima werken.

[ Voor 9% gewijzigd door Creepy op 04-06-2009 11:09 ]

[Remus]

Creepy schreef op donderdag 04 juni 2009 @ 10:58:
[...]

Even heel erg kort door de bocht:

Je java devvers zijn te eigenwijs en weigeren standaard zaken te gebruiken terwijl jullie .NET devers dat waarschijnlijk wel doen. Is dat een probleem van Java of van de devvers?

Dus kan Java productief zijn? Ja, net zo productief als .NET. Het hangt natuurlijk wel af van de devvers. Blijkbaar werken jullie .NET devvers sneller dan de Java devvers. Probeer eens te achterhalen waar dat aan ligt i.p.v. het direct te wijten aan Java.

Inderdaad. Bij .NET heb je minder keuze en dus hoef je minder uit te zoeken. Bij Java zijn er meerdere frameworks en meerdere implementaties van een standaard waardoor je dus meer en vaker een keuze kan maken. Zo'n keuze moet je natuurlijk niet bij iedere implementatiemoment opnieuw maken, wat de ontwikkelorganisatie van de OP wel lijkt te doen, dat is een vorm van 'analysis-paralysis'

Maak een keer een keuze en heroverweeg die keuze alleen als uit ervaring gebleken is dat het misschien toch niet zo'n goede keuze was, als er nieuwe ontwikkeling zijn in het landschap waardoor een nieuwe keuze grote voordelen kan opleveren of als er een nieuw product ontwikkeld moet worden waarbij de oude keuze niet goed werkt.

Het probleem bij de OP is dus dat de developers te graag iedere keer een nieuwe keuze maken en dat het management dat niet stuurt of gewoonweg afkapt.

Overigens, de OP heeft het over FPA (Functie Punt Analyse). Ik heb zelf nog nooit een organisatie gezien die dat echt goed toepast (als ze het al toepassen). De getallen die de OP heeft gehoord of gezien kan ook nog eens erg afhangen van de manier (en diepte) van het toepassen van FPA.

[OMX2000]

Creepy schreef op donderdag 04 juni 2009 @ 10:58:
[...]

Even heel erg kort door de bocht:

Je java devvers zijn te eigenwijs en weigeren standaard zaken te gebruiken terwijl jullie .NET devers dat waarschijnlijk wel doen. Is dat een probleem van Java of van de devvers?

Dus kan Java productief zijn? Ja, net zo productief als .NET. Het hangt natuurlijk wel af van de devvers. Blijkbaar werken jullie .NET devvers sneller dan de Java devvers. Probeer eens te achterhalen waar dat aan ligt i.p.v. het direct te wijten aan Java.

Ik wijt niks aan Java dev's. Ik zeg ook niet dat .NET dev's slimmer of dommer zijn. Wat ik wel zeg is dat blijkt uit metingen (functie punten analyses) dat Java niet zo productief is. Natuurlijk zijn er projecten dat Java sneller is dan .NET. Dit is dus niet een discussie om Java te diskwalificeren, maar om te begrijpen waar het hem nou in zit. Maar ik zou ook wel willen weten wat er dan anders is aan de snelle Java projecten?

Sebazzz schreef op donderdag 04 juni 2009 @ 01:58:
Is het niet meer cultuur? Dat Java programmeurs bepaalde technieken niet of wel toepassen tegenover C# programmeurs die misschien door o.a. MSDN wel of niet gestimuleerd worden om dit te doen? En hoe zit het met de IDE's bijvoorbeeld, daar zit ook een stuk in lijkt me.

Ik denk dat het dus zeker wel met cultuur heeft te maken. Over het algemeen zijn .NET-ers pragmatischer, en gaan niet altijd voor de technisch mooiste oplossing. Java ontwikkelaars zijn echt programmeurs die zich kunnen verliezen in code.


En ik denk dat daar wel een kern van waarheid in zit. Ik denk dat over het algemeen .NET-ers pragmatischer zijn, en niet altijd

[OMX2000]

Remus schreef op donderdag 04 juni 2009 @ 11:09:
[...]
Het probleem bij de OP is dus dat de developers te graag iedere keer een nieuwe keuze maken en dat het management dat niet stuurt of gewoonweg afkapt.

Deels waar. De developers worden steeds geconfronteerd met wat nieuws, en wat nieuws betekend vaak opnieuw het wiel uitvinden.

Overigens, de OP heeft het over FPA (Functie Punt Analyse). Ik heb zelf nog nooit een organisatie gezien die dat echt goed toepast (als ze het al toepassen). De getallen die de OP heeft gehoord of gezien kan ook nog eens erg afhangen van de manier (en diepte) van het toepassen van FPA.

Zoals ik al zei bij Atos wordt het toegepast. Atos heeft er geen belang bij om een bepaald platform voor te trekken. Ze hebben er wel belang bij om te weten wat de productiviteit van een bepaald platform is.

[Bart Brinkman]

Ik denk dat productiviteit een redelijk slechte metriek is om de keuze van het te gebruiken platform op te baseren. Bovendien is het moeilijk te meten. Ik zou het breder bekijken.

Redelijk overzicht:

http://scholar.google.nl/...uster=4162548241644594596

En als je toegang hebt:

http://ieeexplore.ieee.or..._all.jsp?arnumber=1408754

[Hydra]

Interesante blog over een verschil in 'mindset' tussen .net en Java:
http://weblogs.java.net/b...4/09/conflicting_min.html

[OMX2000]

Hydra schreef op donderdag 04 juni 2009 @ 11:43:
Interesante blog over een verschil in 'mindset' tussen .net en Java:
http://weblogs.java.net/b...4/09/conflicting_min.html

Achterhaalde statements. Microsoft is niet meer zo fel tegen open-source. En gebruikt en levert zelf open-source componenten.

Voorbeeld van Visual Studio Team System is achterhaald. Je kunt bijv met ASP.NET MVC kiezen voor je test framework (nUnit, mbUnit, etc).

Sterker nog de succesvolle frameworks op het Java platform zijn vaak ge-port naar .net (.NHibernate, Spring.Net, log4net, nAnt). Maar de belangrijke basis componenten, zoals de XML stack, webservice stack, web stack worden vrijwel altijd van Microsoft zelf gebruikt. Dus er is keus, maar wel in mindere mate dan op het Java platform.

En als ik dat dus vergelijk met een tool/platform waarin nog minder architectonische/technische keuzes gemaakt kunnen worden, dan zie ik dat de productiviteit weer verder omhoog gaat.

Dus mijn voorlopige conclusie, keuzevrijheid kost productiviteit. En ik denk dat Java devs en .NET-ers in mindere mate, het niet leuk vinden om in een fabriek te werken, waar alles routine wordt.

[Mr_Light]

roy-t schreef op donderdag 04 juni 2009 @ 09:26:
[...]

Leuk dat je dit constateert maar misschien zou je iets kunnen toevoegen aan dit topic ipv op het flame feest afwachten door die ervaringen dan te posten want nu klink je imho als "waaaaa iemand zegt iets kuts over java/iets goeds over .net... boehoe niet waar PUNT. Ik ga ergens anders heen"

Leuk dat je het zo defensief interpreteert maar misschien zou je wel kunnen oppikken wat ik zeg ipv mijn reply tot een flame te minimaliseren.

Als al je gegevens van een bedrijf af komen met de zelfde cultuur, zelfde inrichting en mogelijk zelfs de zelfde mensen, daar een conclusie aanhangt dan ben je aan het cherry picken.

Het is mijn ervaring niet en dan komt inderdaad een punt ja, als ik er een conclusie aan zou verbinden zou ik precies het zelfde doen als waar ik de topic starter op aanspreek. Namelijk het beeld wat ik heb van het kleine gebiedje waarin ik leef binnen het IT landschap pak en dat projecteer op de rest van wereld. "boehoe niet waar" is net zo'n voorbarige conclusie als het stellen dat java niet productief is op basis van deze gegevens.

Niet dat cherry picken hier helemaal slecht is want het provoceert en dus motiveert het wel tot antwoorden.

Voor de rest wat DSL betreft volgens mij hadden mensen decenia geleden ook het 'licht' gezien net zo als de ts. Echter vandaag de dag..

en daarover is menig paper volgeschreven ik heb niet veel zin om die gaan op te zoeken als het na 4 replies al mis was gegaan.

[MBV]

Ik lees in de OP dat het over de ontwikkeling van software gaat. Denken de Java-programmeurs wellicht verder vooruit, zodat onderhoud minder werk kost?

[GrooV]

Zou het ook komen omdat Visual Studio gewoon de beste IDE is? Voor .net heb je gewoon 1 IDE waar je bij java weer meerdere hebt, dingen zoals bijvoorbeeld RMI werken dan alleen weer in Eclipse en niet in NetBeans terwijl in Visual studio gewoon alles ondersteund wordt wat er is voor .NET

[Verwijderd]

Misschien zijn de Java-programmeurs niet competent. Of de .NET-programmeurs zijn een uitzonderlijk goed team. Of jullie hebben projecten die beter werken met .NET. Of de FPA wordt niet goed toegepast. Of jullie hebben een niet-productieve workflow bij Java. Of de Java-versie is oud. Of er is meer aandacht besteed aan .NET-ontwikkeling. Of...

Je bent nu eigenlijk een stroman aan het bevechten. Je neemt een claim aan voor waar, die niet algemeen geaccepteerd is: ".NET is productiever dan Java", en gaat vervolgens vragen waar dat aan ligt.

Een interessanter topic zou zijn: is het mogelijk om productiever te zijn dan .NET en Java? .NET en Java zijn nu eenmaal talen van dezelfde categorie.

[momania]

GrooV schreef op donderdag 04 juni 2009 @ 13:05:
Zou het ook komen omdat Visual Studio gewoon de beste IDE is? Voor .net heb je gewoon 1 IDE waar je bij java weer meerdere hebt, dingen zoals bijvoorbeeld RMI werken dan alleen weer in Eclipse en niet in NetBeans terwijl in Visual studio gewoon alles ondersteund wordt wat er is voor .NET

Je moet de visual studio gebuikers hier eens oh en ah zien roepen als ze ons in IntelliJ bezig zien

[Hydra]

OMX2000 schreef op donderdag 04 juni 2009 @ 11:54:
Achterhaalde statements. Microsoft is niet meer zo fel tegen open-source.

Het ging me meer om de mindset van de programmeurs zelf van dan microsoft. Ik heb ook geen zin in MS-bashing. Wij gebruiken zowel .Net als Java dus ik heb geen ernstige voorkeur.

[Remus]

OMX2000 schreef op donderdag 04 juni 2009 @ 11:28:
[...]

Deels waar. De developers worden steeds geconfronteerd met wat nieuws, en wat nieuws betekend vaak opnieuw het wiel uitvinden.

Dat lijkt mij een groot deel een managementfout. Management moet voorkomen dat de ontwikkelaars bij de minste of geringste verandering het wiel opnieuw gaan uitvinden (en ja: in mijn ervaring houden veel Java ontwikkelaars van het wiel opnieuw uitvinden, aangezien ze daar veel plezier aan beleven; .NET ontwikkelaars heb ik eerlijkgezegd nog niet veel mee te maken gehad). Gebeurt dat toch, dan moet je idd niet verbaasd zijn als de productiviteit naar beneden gaat.

Zoals ik al zei bij Atos wordt het toegepast. Atos heeft er geen belang bij om een bepaald platform voor te trekken. Ze hebben er wel belang bij om te weten wat de productiviteit van een bepaald platform is.

Maar is in beide gevallen 1) exact dezelfde analyse toegepast en 2) zijn de onderscheiden FP ook van een vergelijkbare ontwikkelimpact. Als 1 FP in een product x gewoonweg 2x zoveel ontwikkeltijd vergt dan 1 FP in product y (onafhankelijk van de taal), dan had de uitkomst natuurlijk ook andersom kunnen zijn.

[ Voor 3% gewijzigd door Remus op 04-06-2009 14:58 ]

[MBV]

Maar FunctiePunten Analyse is heilig!

[Hydra]

Remus schreef op donderdag 04 juni 2009 @ 14:57:
Dat lijkt mij een groot deel een managementfout. Management moet voorkomen dat de ontwikkelaars bij de minste of geringste verandering het wiel opnieuw gaan uitvinden (en ja: in mijn ervaring houden veel Java ontwikkelaars van het wiel opnieuw uitvinden, aangezien ze daar veel plezier aan beleven; .NET ontwikkelaars heb ik eerlijkgezegd nog niet veel mee te maken gehad). Gebeurt dat toch, dan moet je idd niet verbaasd zijn als de productiviteit naar beneden gaat.

Volgens mij vind elke goeie ontwikkelaar het sowieso leuk om het wiel opnieuw uit te vinden. Een eigen XML parser maken is leuker dan een standaard gebruiken. Ik doe het niet omdat ik m'n deadline niet ga halen natuurlijk, maar met onbeperkte tijd zou ik het zeker doen.

Dus inderdaad is het gewoon een managementfout. Kennelijk heeft de laag boven de developers al geen flauw idee van hoe lang iets ongeveer zou mogen duren.

[Remus]

Hydra schreef op donderdag 04 juni 2009 @ 15:28:
[...]


Volgens mij vind elke goeie ontwikkelaar het sowieso leuk om het wiel opnieuw uit te vinden. Een eigen XML parser maken is leuker dan een standaard gebruiken. Ik doe het niet omdat ik m'n deadline niet ga halen natuurlijk, maar met onbeperkte tijd zou ik het zeker doen.

Hoewel er een aantal dingen zijn die ik leuk vind bij programmeren, is het zelf schrijven van een XML parser nou niet echt een activiteit die ik onder leuk zou scharen (zeker niet gezien de reeds bestaande parsers).

Dus inderdaad is het gewoon een managementfout. Kennelijk heeft de laag boven de developers al geen flauw idee van hoe lang iets ongeveer zou mogen duren.

Inderdaad, in de praktijk zal het dus waarschijnlijk eerder zo zijn dat het .NET-team van de OP gewoon beter gestuurd wordt.

[OMX2000]

Verwijderd schreef op donderdag 04 juni 2009 @ 13:15:
Misschien zijn de Java-programmeurs niet competent. Of de .NET-programmeurs zijn een uitzonderlijk goed team. Of jullie hebben projecten die beter werken met .NET. Of de FPA wordt niet goed toegepast. Of jullie hebben een niet-productieve workflow bij Java. Of de Java-versie is oud. Of er is meer aandacht besteed aan .NET-ontwikkeling. Of...

Je bent nu eigenlijk een stroman aan het bevechten. Je neemt een claim aan voor waar, die niet algemeen geaccepteerd is: ".NET is productiever dan Java", en gaat vervolgens vragen waar dat aan ligt.

Een interessanter topic zou zijn: is het mogelijk om productiever te zijn dan .NET en Java? .NET en Java zijn nu eenmaal talen van dezelfde categorie.

Met dat laatste ben ik het wel eens. Ik voer eigenlijk 2 discussies tegelijk. En de vraag moeten zijn: "Wat zijn vandaag de dag aantoonbaar productievere platform en/of methodieken?"

De vraag komt natuurlijk niet helemaal uit de lucht vallen. Ik denk dat wij in Nederland serieus moeten nadenken hoe wij een toegevoegde waarde kunnen blijven creëren t.o.v. bijvoorbeeld de Indiërs. De tarieven in Nederland zullen de komende tijd onder druk blijven staan, en over een tijdje wordt het simpelweg niet rendabel om Java of .Net ontwikkelaars in Nederland te hebben.

[OMX2000]

Remus schreef op donderdag 04 juni 2009 @ 14:57:
[...]

Dat lijkt mij een groot deel een managementfout. Management moet voorkomen dat de ontwikkelaars bij de minste of geringste verandering het wiel opnieuw gaan uitvinden (en ja: in mijn ervaring houden veel Java ontwikkelaars van het wiel opnieuw uitvinden, aangezien ze daar veel plezier aan beleven; .NET ontwikkelaars heb ik eerlijkgezegd nog niet veel mee te maken gehad). Gebeurt dat toch, dan moet je idd niet verbaasd zijn als de productiviteit naar beneden gaat.


[...]

Maar is in beide gevallen 1) exact dezelfde analyse toegepast en 2) zijn de onderscheiden FP ook van een vergelijkbare ontwikkelimpact. Als 1 FP in een product x gewoonweg 2x zoveel ontwikkeltijd vergt dan 1 FP in product y (onafhankelijk van de taal), dan had de uitkomst natuurlijk ook andersom kunnen zijn.

Dat is het juist. Een FP is een FP. De analyze wordt niet gedaan op basis van de een technologie of platform, maar op functionaliteit. En 1 FP zegt niks over de hoeveelheid tijd dat het gaat kosten. Pas als je het gaat vermenigvuldigen met X h/FP weet je hoeveel tijd het kost om iets te realiseren. Dus 100 FP realiseren met Oracle (5 h/FP) zou je dust 500 uur kosten.

Waar het dus mis kan gaan is bij het vaststellen van de FP. Daarom zul je je schattingen niet zomaar door 1 persoon laten doen. En je gebruikt vergelijkbare schattingen uit het verleden. Daarom wordt het pas betrouwbaarder als je veel projecten in je FP kennisbank hebt zitten.

[Gomez12]

OMX2000 schreef op donderdag 04 juni 2009 @ 16:58:
[...]


Met dat laatste ben ik het wel eens. Ik voer eigenlijk 2 discussies tegelijk. En de vraag moeten zijn: "Wat zijn vandaag de dag aantoonbaar productievere platform en/of methodieken?"

En dat is compleet afhankelijk van de gevraagde software, voor software die 10 jaar mee moet gaan gelden er iets andere eisen dan voor software die 2 jaar mee moet gaan en tussendoor allerlei updates mag krijgen.

Voor de 1e soort wil je proven technology, voor de 2e soort kan je de nieuwste frizzle sizzle software gebruiken...

De vraag komt natuurlijk niet helemaal uit de lucht vallen. Ik denk dat wij in Nederland serieus moeten nadenken hoe wij een toegevoegde waarde kunnen blijven creëren t.o.v. bijvoorbeeld de Indiërs. De tarieven in Nederland zullen de komende tijd onder druk blijven staan, en over een tijdje wordt het simpelweg niet rendabel om Java of .Net ontwikkelaars in Nederland te hebben.

Tja, ik denk dat je hier een verkeerde insteek hebt. Qua echt programmeren / code kloppen ga je het nooit winnen van de lage lonen landen. Alles wat jij kan leren, kunnen zij ook leren. Elke tool die jij kan gebruiken kunnen zij ook gebruiken.

Het gaat er meer om, wat kan jij wel doen wat hun niet kunnen ( en dat is niet programmeren ).
Ik ken ondertussen al genoeg bedrijfjes die de projectleiders in NL hebben zitten voor de communicatie en alle programmeurs zitten in lage lonen landen, de klant merkt er niets van ( want die heeft enkel contact met de projectleider ).
Daar kan gewoon geen enkele tool tegenop, enkel moet er een goede projectleider zijn ( het punt waarop veel van deze trajecten stuklopen )

Heel simpel gesteld, een nederlandse programmeur is zeg maar 10x duurder dan een indier, dan kan jij een tool hebben die 6x productiever is dan alles wat er nu is, nog steeds ben jij duurder dan die indier.
Over 6 maanden heeft die indier ook die tool geleerd en is hij weer 10x goedkoper dan jij.

[GrooV]

Gomez12 schreef op donderdag 04 juni 2009 @ 21:38:
[...]

Heel simpel gesteld, een nederlandse programmeur is zeg maar 10x duurder dan een indier, dan kan jij een tool hebben die 6x productiever is dan alles wat er nu is, nog steeds ben jij duurder dan die indier.
Over 6 maanden heeft die indier ook die tool geleerd en is hij weer 10x goedkoper dan jij.

Is het nog steeds goedkoper als er een grotere kans is dat projecten stuk lopen, en deze dus over nieuw gedaan moeten worden of dat de klant naar een ander gaat?

[Gomez12]

GrooV schreef op donderdag 04 juni 2009 @ 21:48:
[...]


Is het nog steeds goedkoper als er een grotere kans is dat projecten stuk lopen, en deze dus over nieuw gedaan moeten worden of dat de klant naar een ander gaat?

Waarom is er een grotere kans dat projecten stuk lopen?
Bij een gemiddelde programmeerfabriek is er ook geen rechtstreeks contact met de programmeurs.

Op het moment dat je op het niveau zit dat er alleen consultants / projectleiders etc langskomen dan boeit het niet meer waar de programmeurs zitten.

Vziw lopen de meeste projecten stuk op communicatie problemen tussen klant en programmeur, daarvoor is juist de projectleider / consultant en die is gewoon NL.

[Verwijderd]

OMX2000 schreef op donderdag 04 juni 2009 @ 16:58:
[...]
Met dat laatste ben ik het wel eens. Ik voer eigenlijk 2 discussies tegelijk. En de vraag moeten zijn: "Wat zijn vandaag de dag aantoonbaar productievere platform en/of methodieken?"

En misschien moet je daar nog even aan toevoegen; "Daarnaast was ik zwaar gefrustreed met mijn eigen Java team wat ik niet onder controle heb en dat reageerde ik af op de taal en andere Java programmeurs". Hierbij refereer ik naar deze passage:

Ik begin bewust met Java aangezien het in de praktijk blijkt het minst productieve platform te zijn. Dus hoe kan de industrie nu al jaren accepteren dat er zo langzaam gewerkt wordt? Ik heb me echt dood lopen ergeren aan het feit dat wanneer er nieuwe dingen gevraagd worden van Java ontwikkelaars, dat opeens alle wielen opnieuw uitgevonden moeten worden.

Je extrapoleert hier jouw ervaringen voor het gemak even op het gehele platform. Het lijkt me duidelijk dat het hier gaat om een people probleem en niet om een probleem met een platform.

[Nick_S]

Gomez12 schreef op donderdag 04 juni 2009 @ 22:37:
[...]
Vziw lopen de meeste projecten stuk op communicatie problemen tussen klant en programmeur, daarvoor is juist de projectleider / consultant en die is gewoon NL.

De projectleider zit over het algemeen niet tussen de klant en de programmeur. Dat zal eerder een business analist of requirements analist zijn. Verder is er op het moment (eigenlijk al een hele tijd) een flinke verschuiving aan het plaatsvinden tussen traditionele waterval en agile programming (XP, Scrum e.a.) waarbij er vaak overlap is van functies binnen een team en waarbij de klant veel meer verantwoordelijk wordt over zijn eigen product. Ik denk, dat dat een stuk effectiever werkt als waterval, waarbij er eerst alle requirements duidelijk op papier gezet worden en daarna pas begonnen wordt met programmeren. Ik denk dat je met waterval nog wel met Indiers weg kan komen, maar met AP zal er tijdens het hele proces toch meer klant contact moeten zijn.

[BCC]

Inderdaad, dit hangt ook samen met het feit dat meer mensen belang hebben bij een IT oplossing, maar dat ze erg slecht zijn in het exact specificeren van het probleem. Dit soort zaken kun je perfect oppakken met Agile methodes en zijn niet uit te besteden naar het buitenland. Wij hebben als bedrijf daar dus ook de focus op liggen. Laat de programmeur maar eens een week bij de klant zitten, zodat hij het probleem van de klant leert!

De gebruikte programmeer taal is dan ook slechts een middel om zo snel mogelijk samen met de klant het doel te bereiken. Of je daar het beste Java, .Net of Ruby on Rails voor kan gebruiken is IMHO afhankelijk van de situatie en eigenlijk ondergeschikt aan je doel. Ook of je nu 5 of 6 uur doet over de implementatie van een item wordt dan onbelangrijk.

[ Voor 12% gewijzigd door BCC op 05-06-2009 00:21 ]

[Verwijderd]

Nouja, de jonge dynamische talen (Ruby, Python) worden toch altijd genoemd als goed geschikt voor agile programmeren? Worden die talen ook daadwerkelijk gebruikt in software development, of is het vooral nog speculatie?

[BCC]

Wij gebruiken Ruby on Rails op grote schaal hiervoor, dus in Nederland is er iig 1 partij die het doet En ik ken zeker 10 bedrijven die dit op kleinere schaal ook doen. Internationaal doen jongens als Sun en IBM ook veel met Ror.

[ Voor 47% gewijzigd door BCC op 05-06-2009 00:45 ]

[momania]

Gomez12 schreef op donderdag 04 juni 2009 @ 21:38:
[...]

En dat is compleet afhankelijk van de gevraagde software, voor software die 10 jaar mee moet gaan gelden er iets andere eisen dan voor software die 2 jaar mee moet gaan en tussendoor allerlei updates mag krijgen.

Voor de 1e soort wil je proven technology, voor de 2e soort kan je de nieuwste frizzle sizzle software gebruiken...

Onzin, je pakt de juiste tools voor de taak.
Als men software gaat afraffelen, met de gedachte dat het toch maar 2 jaar mee moet gaan, mogen ze bij sowieso direct vertrekken....

[Confusion]

OMX2000 schreef op donderdag 04 juni 2009 @ 00:06:
Daarom zie je ook dat static typed talen zo enorm veel patterns (GoF factory pattern, strategy pattern, etc) hebben die er puur voor zijn om je code overzichtelijk flexibel, en gestructureerd te houden.

Al die patterns zijn net zo goed nodig in dynamisch getypeerde talen, om de code overzichtelijk te houden. Alleen zijn ze vaak minder zichtbaar, omdat er geen objecten genaamd ...Command/Strategy/Factory zijn.

Voorbeeld van een discussie tussen een architect en een Java ontwikkelaar

Dat is geen voorbeeld van 'het wiel opnieuw uitvinden'. Dat is een voorbeeld van: de keuze van de achitect niet accepteren. Er zijn wielen genoeg. Wie zelf een lusje schrijft om een file in te lezen en niet org.apache.commons.io.IOUtils gebruikt is gewoon niet goed bezig.

Nu zullen een aantal mensen zeggen dat als je een fabriek/ontwikkelstraat hebt, dat de keuzen voor je gemaakt zijn. En dat is deels waar, maar in de praktijk zijn die straten technologie georienteerd. Wat dus betekend dat ze zich vooral focussen op het technische probleem domein. Wanneer ze geconfronteerd worden met een nieuwe toepassing die functioneel lijkt op een andere, maar technisch anders is. Moet het wiel opnieuw uitgevonden worden. De programmeur ziet niet direct wat de beide toepassingen gemeen hebben.

Als ze zich realiseren dat ze misschien een andere techniek nodig hebben, zoals in je 'gesprekje', dan lijkt het me dat ze dat juist wel zien? Anders zouden ze toch blindweg de vertrouwde technologie toepassen?

Dus ik zie vooral heil in methoden en platforms die zowel het programmeerwerk als beheer, requirements management, test en deployment omvatten. En dit alles in een vaste set aan tools aanbiedt.

Iedere tool heeft sterke en zwakke kanten. Geen enkele tool is universeel toepasbaar. Je probeert een silver bullet uit te vinden. Bovendien moet je juist niet alle tools willen integreren, omdat dat tools nog minder flexibel maakt. Je hebt op een linux systeem vaak genoeg 'find' en 'grep' gecombineerd nodig: dat betekent niet dat het een goed idee is daar 1 tool van te maken.

[ Voor 5% gewijzigd door Confusion op 05-06-2009 08:28 ]

[Confusion]

Gomez12 schreef op donderdag 04 juni 2009 @ 21:38:
Tja, ik denk dat je hier een verkeerde insteek hebt. Qua echt programmeren / code kloppen ga je het nooit winnen van de lage lonen landen. Alles wat jij kan leren, kunnen zij ook leren. Elke tool die jij kan gebruiken kunnen zij ook gebruiken.

Voorlopig is mijn conclusie dat Russen en Indiers incompetent zijn en dat outsourcing een bijzonder slecht idee is. De incompetentie van Indiers is bovendien cultureel verklaarbaar en daarvan is het einde voorlopig niet in zicht. Tijdens het codekloppen moet je creatief zijn, inventief zijn, overzicht houden. Wie blind een opdracht volgt levert iets af dat vervolgens met kunstgrepen aan de rest gebreid moet worden.

[JKVA]

Waar ik me vaak aan stoor in Java land (ik ben zelf Java devver) is dat er voor Java veel gratis tooling beschikbaar is. Dat is op zich natuurlijk goed, maar leg je manager maar eens uit dat graag met IntelliJ IDEA werkt (kost 500 euro) terwijl Eclipse gratis is.

Bedrijven met een .NET straat kopen gewoon een corporate Visual Studio licentie en zijn blij met de tooling, maar bedrijven met een Java ontwikkelstraat vertikken het om de een of andere reden om geld uit te geven voor goede tooling.

Ik zie zoveel mensen stoeien met Eclipse en Maven, maar met IntelliJ werkt alles gewoon vanzelf. En zo zijn er nog veel van die kleine irritaties die bij elkaar opgeteld voor veel vertraging zorgen.

Of architecten die je verplichten om met frameworks te werken die niet geschikt zijn voor het type project dat je aan het doen bent waardoor je er alleen maar omheen werkt in plaats van dat je er voordeel van hebt.

[Confusion]

JKVA schreef op vrijdag 05 juni 2009 @ 09:03:
Ik zie zoveel mensen stoeien met Eclipse en Maven, maar met IntelliJ werkt alles gewoon vanzelf. En zo zijn er nog veel van die kleine irritaties die bij elkaar opgeteld voor veel vertraging zorgen.

offtopic:
Een van mijn collega's werkt met IntelliJ, maar die heeft meer Maven problemen dan ik met Eclipse. Misschien omdat ik de pom geschreven heb en IntelliJ alleen met eigen gegenereerde POM's om kan gaan? Hoe dan ook, hij is er later op het project bijgezet en Maven moet ook zonder IDE werken. Sowieso lanceer ik eigenlijk nooit projecten vanuit Eclipse; doe mij de console maar.

[ Voor 6% gewijzigd door Confusion op 05-06-2009 09:08 ]

[roy-t]

Hydra schreef op donderdag 04 juni 2009 @ 11:43:
Interesante blog over een verschil in 'mindset' tussen .net en Java:
http://weblogs.java.net/b...4/09/conflicting_min.html

Ik ben het heel erg eens met dat .net vs java erg veel met mindset heeft te maken en dat dat de productiviteit zowel ten goede kan komen voor beide partijen als nadelen heeft. Maar dit blog entry ( lekker neutraal vanaf java.net) mist wel echt een paar steken in de argumentatie en probeert er in mijn ogen iets negatiefs van te maken (sowieso wtf @ de uitspraak dat MS met zijn technologien 5jr achterloopt op java, de laatste keer dat ik die 2 vergeleek (en dan vooral C#+.Net vs Java) liep MS toch net iets voor op Java).

Maar ja misschien dat je het wel moet zien als mindet:

Java; de onderzoeker, constant zoekend naar iets beters
+komt veel meer interessante projecten tegen die de productiviteit kunnen verhogen
-projecten hebben niet altijd even hoge kwaliteit en worden niet 'voor eeuwig' ondersteund
-soms verliezen ze zichzelf zo in het zoeken dat het juist productiveit kost

C#: zeer bekend met zijn tools en daar tevregen over
+1 right tool for the job, hoeft niets te zoeken maar gaat meteen aan de slag.
+Consistente hoge kwaliteit tools die lang ondersteund worden en goed getest.
-Mist interessante projecten die veel tijd zouden kunnen schelen.

Natuurlijk zijn dit 2 extremen, ook betekend 2x een plusje niet dat ik C# nu objectief beter vind.

(Zelf blijf ik toch echt C# fan juist door dat mooie totaal pakket en door VS )

[Standeman]

roy-t schreef op vrijdag 05 juni 2009 @ 12:44:
[...]


Ik ben het heel erg eens met dat .net vs java erg veel met mindset heeft te maken en dat dat de productiviteit zowel ten goede kan komen voor beide partijen als nadelen heeft. Maar dit blog entry ( lekker neutraal vanaf java.net) mist wel echt een paar steken in de argumentatie en probeert er in mijn ogen iets negatiefs van te maken (sowieso wtf @ de uitspraak dat MS met zijn technologien 5jr achterloopt op java, de laatste keer dat ik die 2 vergeleek (en dan vooral C#+.Net vs Java) liep MS toch net iets voor op Java).

Het artikel is dan ook uit 2004. Die 5 jaar is duidelijk overdreven, maar begin 2000 liet .Net nog behoorlijk achter idd. Inmiddels is die achterstand ruimschoots ingehaald!

[ Voor 33% gewijzigd door Standeman op 05-06-2009 13:04 ]

[roy-t]

Standeman schreef op vrijdag 05 juni 2009 @ 13:04:
[...]

Het artikel is dan ook uit 2004. Die 5 jaar is duidelijk overdreven, maar begin 2000 liet .Net nog behoorlijk achter idd. Inmiddels is die achterstand ruimschoots ingehaald!

Oeh klopt, ik had niet gezien dat het uit 2004 was

* roy-t loopt rustig door *nothing to see here!*

[pedorus]

Ik denk dat het interessantste aan dit draadje toch deze data in de startpost is:

Programmeertaal	Project Delivery Rate (uur/fp)
Java	12
.NET	6-7
Oracle	4-5

Enkel waar komt die data nu precies vandaan? Alleen van Atos? Alleen in-house projecten? Zijn de ervaringen van de teams hetzelfde? Welke uren worden er precies bedoeld (tijdens welke fases)? Wat voor soort functiepunten (alleen NESMA?)? Zijn de projecten van gelijke omvang, en is het niet toevallig zo dat de Java-projecten simpelweg groter zijn? Om hoeveel projecten ging het eigenlijk? Was het verschil significant?

Als je me de data kan geven, graag, maar vooralsnog neem ik deze cijfers en de dis-productiviteit van Java maar even met een korreltje zout

OMX2000 schreef op donderdag 04 juni 2009 @ 17:08:
[...]En 1 FP zegt niks over de hoeveelheid tijd dat het gaat kosten. Pas als je het gaat vermenigvuldigen met X h/FP weet je hoeveel tijd het kost om iets te realiseren. Dus 100 FP realiseren met Oracle (5 h/FP) zou je dust 500 uur kosten.
[...]

Dat is niet aan te raden, behalve bij projecten van vergelijkbare omvang. Het is verband tussen FP en tijd is volgens mij exponentieel, niet lineair...