Er is door de jaren heen een groot aantal software ontwikkelmethodes bedacht. Waren waterval, RUP en DSDM vroeger populair, tegenwoordig is de it-wereld vooral lyrisch over Agile, Scrum en DevOps. Deze nieuwe vormen van samenwerking hoeven echter helemaal niet automatisch een verbetering van het ontwikkelproces te betekenen. Slechte tooling is evenzo vaak een probleem en die tooling is in veel gevallen nog altijd hetzelfde als tien jaar geleden.
Nog niet zo heel lang geleden liep ik een klant tegen het lijf die exact dit probleem had. Het was in veel opzichten een voorbeeldige it-organisatie. De it-afdeling bestond uit mensen die eerder zelf in de business gewerkt hadden en dus ook precies begrepen wat hun wensen waren. Ze gebruikten Agile als ontwikkelmethode voor software-ontwikkeling. En last but not least; ze hanteerden een build-over-buy-principe wanneer het ging om applicatie-ontwikkeling. Ze konden met it dus ook echt het verschil maken met concurrenten.
Praktijk weerbarstig
Deze organisatie had zich ten doel gesteld om meer met klanten te gaan communiceren en ze wilden dit bereiken door meer it-functionaliteit te gaan bieden, zowel via de website als via de mobiele apps. Er moest daarom meer en sneller ontwikkeld worden in kortere release cycli. Voor een goed geoliede it-afdeling als deze zou je verwachten dat dit geen probleem is, maar de . De tooling voor software-ontwikkeling was namelijk niet toereikend. Het bedrijf maakte van oorsprong vooral Uniface-applicaties in een 4GL-omgeving. Door het almaar toenemende belang van internet was de it-afdeling door de jaren heen overgeschakeld naar Java. De complexiteit van het programmeren in Java was vele malen groter dan in de 4GL-omgeving. De productiviteit en het aantal releasecycles ging daardoor omlaag. Bovendien ging er veel tijd op aan het in de lucht houden van applicaties.
Binnen deze context probeerde de ontwikkelaars de iteraties flink in tijd te bekorten. Het zal niet verrassen dat dit telkens niet tot het gewenste resultaat leidde. Applicaties werden wel sneller opgeleverd, maar in de testfase werden zoveel bugs gevonden dat ze eigenlijk alleen maar meer tijd verloren. En slaagde de applicatie eenmaal in de testfase, dan werden er wel kinderziektes aangetroffen wanneer de applicatie eenmaal live stond. Gevolg voor de programmeurs was dat zij regelmatig in de avonduren moesten doorwerken.
Model gedreven
Het management begreep dat de problemen niet in de samenwerking zaten. Er moest iets gedaan worden aan de tooling. Een nieuw Java-framework zou daarbij niet helpen, dat was in het verleden al eens geprobeerd. Weer een nieuw java-framework zou evenzoveel problemen opleveren bij het onderhouden en ontwikkelen van de applicaties als nu het geval was. De oplossing werd gevonden in een model-gedreven ontwikkelplatform. Dergelijk platformen waren er vroeger ook wel, en waren in het verleden ook wel door deze klant onderzocht. Destijds waren dergelijke platformen nog niet dermate volwassen dat ze kwalitatief goede code leverden en goed konden integreren met externe databases. Een aantal van de huidige high productivity ontwikkelplatformen kunnen dat inmiddels wel.
Deze klant heeft na lang wikken en wegen besloten om zo’n nieuw ontwikkelplatform te adopteren. Na anderhalf jaar, met een beperkt deel van het ontwikkelteam, waren ze erin geslaagd om meer dan zeven van de vijftien applicaties te ontwikkelen en in productie te brengen. Iets dat met hun oude Java-framework onmogelijk zou zijn geweest. Dus: it’er, kijk ook eens naar de tooling wanneer je je applicatie-ontwikkeling wilt versnellen. Daar zijn meer slagen in te winnen dan alleen het invoeren van een nieuwe ontwikkelmethode.
Albert Einstein’s quote ” Still repeating the same things over and over again and expecting different results’ vat dit mooi samen.
Is slechte tooling hier het probleem of ligt het probleem meer bij de toepassing van de tooling? Tenslotte is een schroevendraaier helemaal geen slechte tool maar je moet er niet proberen een spijker mee in de muur te slaan.
Aandacht voor het probleem en daar de best passende tool voor te vinden blijft wel de uitdaging om effectief en efficient te blijven opereren.
De grote uitdaging is de juiste tool bij de gekozen werkwijze te selecteren.
Sommige organisaties schaffen een compleet Zwitsers zakmes aan terwijl ze alleen maar een aardappelschilmesje nodig hebben [uitgebreide geïntegreerde software ontwikkelomgevingen met allerlei extra’s die niet gebruikt worden]
Anderen hebben een aardappelschilmesje, en denken daar alles mee te kunnen (ja, je kunt een schroef ergens indraaien met een aardappelschilmesje, maar als je een beetje pech hebt is de schroef kapot, je mesje krom en heb je jezelf ook nog in letterlijk in de vingers gesneden). [veel mensen kunnen “alles” in excel of sharepoint]
Een derde variant hierbinnen is de club die lijdt aan het “not invented here” syndroom. Alleen tools die ze zelf ontwikkeld hebben voldoen volgens hun.
Tot slot is er nog een “best of breeds” benadering. Voor iedere stap in de ontwikkelketen wordt het beste tool gekozen, maar vervolgens is men heel veel tijd en moeite kwijt met het aan elkaar knopen van al deze tools zodat er toch een beetje efficiënt gewerkt kan worden.
Voor iedere richting zijn voors en tegens te bedenken, maar toolkeuze is maatwerk.
Slechte tools bestaan er bijna niet, slechte of verkeerde keuzes wel!
@Mark Leuke artikel, waar ik benieuwd naar ben wat voor tooling dat dan is? Je hebt het over de complexiteit van het Java programmeren, ik kan me voorstellen dat je je aanloop nodig hebt en dat zal tijd kosten maar wat met de tooling kan, kan ook met Java als je de zaken eenmaal op de rit hebt hoeft dat niet ingewikkelder te zijn. Zou ik denken.
Vraag is waar het dan in zit, in Java of in de mensen? Of is dit iets wat bij Java hoort? Nu ben ik zelf een Java scepticus, een zeer complexe omgeving, met een eigen JVM met veel verschillende Libs om van de java-suites van verschillende leveranciers nog maar te zwijgen. Ik denk altijd een computer bovenop een computer. Wat ik zelf ervaren heb en ook om me heen hoor, moeizaam in het beheer en resources vretend. En vraag me ook af of dit geschikt is voor High Performance applicaties. Ik moet altijd denken, een porsche voorttrekken met paard en wagen.
Maar het kan natuurlijk net zo goed aan de mensen die liggen die het moesten maken, of hoe zo een team samengesteld was. Het kan meerdere reden hebben. Of misschien had je wel één eerste heeeeeele lange sprint nodig gehad hebben om de boel op poten te krijgen. Direct leveren met een nieuwe omgeving was misschien wat teveel gevraagd.
Ik ben benieuwd naar de tooling, ook wat Java kenners hier van denken.
@Louis
Als ik je verhaal lees is het volgens mij eerder onbekendheid dan iets anders. En het argument dat JVM een computer in een computer is gaat sinds .Net runtime en virtual machines niet meer op. En die bestaan al een tijdje.
High performance is al heel lang geen probleem (meer). Dat dit spookbeeld nog steeds in de hoofden hangt bij mensen nog wel.
En qua tooling is Java niet verschillend met alle andere platformen. Als je met libs in de knoop ligt dan is een oplossing als Maven een goede toevoeging. De uitdaging is nog steeds om versies van libs niet elkaar te laten bijten. Op dat vlak is innovatie welkom.
De schrijver heeft een terecht punt dat oude java frameworks niet altijd goed aansluiten bij de wensen van klanten. Log, traag en a-produktief. Maar de innovatie heeft niet stil gestaan en er is behoorlijke slag gemaakt.
Door 4GL en 3GL met slim elkaar te combineren kun je veel bereiken in korte tijd. Dan is het inderdaad belangrijk om deze onderdelen goed te integreren. Daar zijn open standaarden uitermate geschikt voor.
Je hebt nog steeds kundige programmeurs nodig want er is geen enkele taal die geschikt is om enterprise applicaties te maken door iemand die nog nooit een regel code geschreven heeft en net 3 weken een ontwikkelaars cursus heeft gedaan. Die zal eerst een tijdje simpel programmeerwerk moeten doen om wat ervaring op te doen. Programmeren is wat dat betreft een ambacht dat je moet leren.
Beste Louis / Johan,
Er bestaan inderdaad toepassingen waarbij Java een uitkomst is, toch is het wel zo dat de manier waarop we in Java programmeren hetzelfde is als 10-15 jaar geleden. Iedere regel code dient handmatig ingeklopt te worden en kan dus fouten bevatten. Nou weet ik dat daar best wel hulpmiddelen in zijn die je daarin helpen. Een veel grotere uitdaging is om bestaande software aan te passen en alle verschillende tools, die ieder op zich een functie hebben in de totale lifecycle, daarbij goed in te zetten.
Volgens mij zijn er veel handiger tools die veel handmatig werk uit handen nemen, veel menselijke fouten voorkomen en als één geintegreerd platform de lifecycle ondersteunen. Wanneer je één geintegreerd platform gebruikt, is het beter op elkaar afgestemd dan allerlei losse tools die een deel van het totale proces ondersteunen.
Dat maakt een deel van het technische werk minder leuk, maar wel een stuk effectiever! 🙂
Groet,
Mark
@Johan Uiteindelijk met de laatste alina heb je het punt, wat doet het in handen van de programmeur en voor mij geldt onbekend maakt onbemind. Er is nooit een reden om zomaar een taal te haten. Ik schreef al, ik ken het van de beheer kant, ik ken de problemen die er waren met Hibernate en ik stond als beheerder tegen logs per gestrekte MB aan te kijken met daar ergens tussen een afgedraaide stack. Plat gooien opnieuw opstarten, DE oplossing voore computerproblemen. Maar te vaak. Misschien zijn het ook de complexe frameworks zoals de Websphere omgeving waar ik mee te maken had. Ik hoorde van een maat van me die ook in het beheer van Java websphere (+ meer) in een IBM omgeving zit te werken bij de overheid waar een capaciteits probleem is. Conclusie, na berekening, gooi er 270 processoren tegenaan. Oei! Is het de omgeving? Is de het de architectuur? Ik dacht alleen maar kassa voor IBM en ook hoe is het mogelijk. Ik houd het kort (…), ik heb net even zitten lezen en kwam op de volgende discussie uit waarin veel zinnigs gezegd wordt, voor en tegen:
http://www.quora.com/Why-do-some-people-hate-Java
Het is allemaal ook een kwestie van smaak, ik vind C erg mooi eh het is hard op het (virtuele) ijzer, maar realiseer me ook dat je daar de enterprise applicatie niet in zal bouwen. Met veel plezier gewerkt met Perl (WORN, write once read never), vind Python een mooie taal, werk met veel plezier met het eigenaardige Javascript en ik zou heel graag Cobol leren. Dat lijkt me nu mooi!
@Marc Natuurlijk, prettig als je in een high level omgeving je applicaties in elkaar draait maar ik denk dat PaVaKe zijn advies wijs is dat toolkeuze maatwerk is. Dus in dit geval, biedt zo een omgeving voldoende functionaliteit zodat je ermee uit de voeten kunt en ook is wat technische opgeleverd krijgt voldoende. In geval van High Level omgeving betaal je daar een prijs voor, gegenereerde code misschien, een matige DB performance. Niet eenvoudig dat kiezen maar het is naar mijn mening niet alleen business aangelegenheid maar zou heel goed navragen bij je technische mensen, hou ze in ere.
Aardig artikel, aardige reacties.
Voor dat ik de tools behorende bij een methode beoordeel, zou ik liever eerst eens afvragen of de gekozen werkmethode wel de juiste is.
Kiezen we een methode omdat iedereen het zo doet aka omdat we niets anders kennen.
Vervolgens is het idd zaak om een geschikte tool voor die werkmethode en omgeving te vinden.
Ik heb maar al te vaak ervaren dat een tool voor een bepaald team prima werkte terwijl deze voor een team met een andere specialisatie niet geschikt werd bevonden.
Computable zou beter zijn best moeten doen dit soort sluik reclame (voor Outsystems) niet toe te laten. Foei!
@Mark
“No problem can be solved from the same level of consciousness that created it.” – Albert Einstein
Want het gereedschap voldoet niet altijd als je een moer onder een moeilijke hoek los moet draaien of als deze knelt. En dus pas je de steeksleutel via doorslijpen en onder een hoek weer aan elkaar te lassen aan of door het moment ervan te verlengen om de kracht op moer te vergroten.
Zeker ligt de tijd van POKE en PEEK achter ons en doen we het nu met API calls maar dat is soms net zo efficiënt als het typen van een boek op het toetsenbord van een telefoon.
Mark, zeg nou gewoon dat ze je Outsystems platform moeten gebruiken, dat dat inmiddels een volwassen ontwikkelplatform is volgens jou want 4GL en time2market en dat 3GL-Java zuigt 😛