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.
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.