Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Slechte tooling is een groot probleem

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5214401). © Jaarbeurs IT Media.
6,8

 

Reacties

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 :-P

Mischien kijk ik er overheen maar ik zie hier niet echt een expliciet promotie verhaal voor Outsystems in, dit in tegenstelling tot het vorige artikel uit die hoek waarvan ik de waarde nogal twijfelachtig vond.

Waar de auteur wellicht nat op gaat is hierboven al door diverse mensen gemeld.
Automatisering gaat niet enkel om klik-klak-klaar producten.
Als het werkelijk zo is dat eenieder zonder verdere kennis van zaken fatsoenlijke software kan ontwikkelen dan zie ik ook weinig ruimte voor consultans die ondersteuning voor dergelijke platformen aanbieden.
De praktijk is echter weerbarstiger gebleken.
Ooit bedacht men SQL zo dat een manager zelf zijn data bijeen kon sprokkelen. te moelijk, had je een expert voor nodig om iets mee te kunnen, toen kregen we cristal reports, ook te lastig, rapporten moesten weer door experts inelkaar geleuteld worden,
visual basic net zo'n verhaal, het feit dat je buurjongen een programmaatje voor de voetbalclub heeft gemaakt wil nog niet zeggen dat die jongen je bedrijfsvoering kan overzien.

Zelfde geld voor de keuze van ontwikkel talen en platformen.
De wereldproblematiek wordt niet loutermbv dotNet opgelost, ik denk dat elke ervaren techneut wel voorbeelden daarvan weet.
Helaas is het zo dat de 'specialisten' van vandaag de dag niet meer in staat zijn zelf kennis eigen te maken of buiten de doos te denken.

@Louis
Websphere is inderdaad een draak van een applicatieserver. Maar de populariteit van gigantische applicatieservers is op zijn retour. Mede dankzij de innovatie golf die cloud applicaties hebben veroorzaakt overigens.

Maar hybernate is voor een framework relatief oud maar nog uitermate bruikzaam. Dat er problemen mee zijn associeer ik met een ongelukkige implementatie.

Voor grote logfiles heb je graylog2. Open source dus makkelijk.
En als je iets specifiek zoekt is het een kwestie van een slimme query uitvoeren en je kan heel snel uit terabytes data relevante informatie halen.

Wat dat betreft denk ik dat velen hier nog een inhaalslag kunnen maken op wat er qua innovatie de laatste jaren is gebeurd. Het leven voor een software ontwikkelaar is er stukken makkelijker op geworden.

pascal, omdat je er overheen kijk zal ik het even samenvatten

java :
- complexiceit vele malen groter dan 4GL
- lange ontwikkeltijd
- meer bugs
- kinderziektes
- avonduren doorwerken

modelgedreven 4GL zoals outsystems als tooling:
- met kleiner team veeeeel beter resultaat

Nog maar een keer. Er was eens een CIO die baalde dat zijn developers zo'n bagger leverden en daar ook nog eens zo lang over deden. Toen ging die over op een nieuw 4GL platform en ze leefden nog lang en gelukkig.

je hoeft toch geen Einstein te heten om te raden wat Mark ons aan het verkopen is.

Bij het verbeteren van een (werk)proces kijk je o.a. naar:
- de opbouw van proces en aansluiting op de rest in de keten,
- de kennis van de uitvoerders,
- de gereedschap,
....en nog wat andere zaken.

Deze zaken zie je terug in het antwoord van Kurt, PaVaKe en met duidelijke managementsamenvatting in de (1e) reactie van Flex.

Wat is dan interessant aan dit artikel? Hebben die mensen van die ict afdeling wat Covey-achtige gewetensvolle zelfanalyse nodig?

Beste Mark,
Aan dit soort verhaaltjes hebben we dus niets. Vertel ons eens welke tools dat dan wel niet waren en waarom ze daarmee z'n productiviteit haalden. En waren dat dan b.v. dezelfde personen die met hun Java tooling niet die productiviteit haalden?

@Johan Wat de laatste alinea betreft waarbij je zegt dat velen hier nog wel een inhaalslag kunnen maken: er is veel en als ICT-er is er meer dat je niet weet dan dat je wel weet. Het gaat om gevoel voor de bal en dat je een nieuwe situatie weer kan eigen maken. Dus ja, je leest in de rondte, over diverse onderwerpen van de computer die je interesseren maar dat is een fractie van wat er beschikbaar is. Er is ook zoveel! Dus bijvoorbeeld van de Java wereld, daar weet ik bijna helemaal niets van.

Wel een dag terug me nog eens verdiept in de Websphere wereld, nou het is me duidelijk, ik heb alleen te maken gehad met de Webspere Application Server, dus dat is minimaal als ik de WebsphereMQ Suite bekijk. Misschien stak de software niet goed in elkaar maar ook misschien waren er te vaak wijzigingen aan de software. Dat is ook vragen om ellende. Vond het moeizaam.

En ook gesproken met vriend die midden in de WebSphereMQ en IBM producten zit en dan gaat het over heel veel meer dan alleen een WAS (wel de bottleneck!) maar over complexe transactieverwerkende systemen. Die zet je niet zo even in de cloud, wat je daar ook bij mag voorstellen. Gevirtualiseerd wordt er uiteraard volop in dit soort systemen.

Channelweb Expert
Mark  Slooff

Mark Slooff
Regional Sales Director, OutSystems voor Agile Webapplications. Expert van Channelweb voor de topics Business Analytics, Cloud Computing en Infrastructuur.
Hele profiel

Vacatures Infrastructuur

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×