De Beste Code is Geen Code (Dutch)

Vandaag gepubliceerd in de Automatisering Gids, de uitgebreide versie van mijn eerdere verhandeling over het vermijden van fouten in programmatuur door minder te programmeren. Hieronder de volledige tekst.

DE BESTE CODE IS GEEN CODE

7 manieren om fouten te voorkomen door minder te programmeren

Onlangs publiceerden het SANS instituut en MITRE een Top 25 van de meest gevaarlijke programmeerfouten. Een belangrijke lijst, vindt Ron Tolido maar volgens hem gaan de makers ervan voorbij aan misschien wel de meest gemaakte fout: er wordt eenvoudigweg teveel geprogrammeerd.

Het is een veilig gevoel dat we in het vakgebied sinds kort over een Top 25 van Meest Gevaarlijke Programmeerfouten kunnen beschikken. De beste beveiligingsexperts van over de hele wereld hebben hun tanden gezet in de uitdaging en het resultaat mag er zijn. De uiteindelijke lijst bevat veel leerzaam materiaal – overigens ook voor hackers die zoeken naar bijscholing – en elke serieuze systeemontwikkelaar zou deze Top 25 eigenlijk spontaan moeten kunnen opdreunen.

Toch ontbreekt notoir de allergrootste oorzaak van kritieke fouten in software: er wordt nog steeds veel teveel software geschreven. Daaruit blijkt dat de IT onverminderd een pijnlijk jong vakgebied is. De beroepsbeoefenaars blijven hardnekkig zelf problemen veroorzaken om ze daarna met veel aplomb – mogelijk vergezeld van lijstjes, artikelen en zelfs complet boeken – op te lossen. Alle kranen in huis worden wagenwijd opengezet, zodat daarna met trots de allernieuwste, vochtabsorberende dweil tevoorschijn kan worden gehaald. Naarmate meer code met de hand wordt geproduceerd, neemt ook de kans op fouten toe. En hoewel programmeurs misschien een nostalgisch sentiment voelen bij het regel voor regel schrijven van hun software, worden zowel efficiëntie als veiligheid er niet door gediend.

De mogelijk allerbeste manier om minder gevaarlijke fouten te maken tijdens het coderen, is daarom minder coderen. Hier zijn 7 voor de hand liggende manieren om dat te bereiken:

1. Hergebruiken. Steeds meer basisfunctionaliteit wordt gedekt in frameworks of andere herbruikbare componenten, services en bibliotheken. Dit materiaal kan zowel binnen de eigen organisatie zijn ontwikkeld of komt van een andere leverancier. Omdat het om voor hergebruik geschikt bevonden code gaat, mag worden aangenomen dat deze software zeer grondig is getest en beproefd, in ieder geval meer dan gemiddeld. De code hoeft alleen maar gebruikt of aangeroepen te worden, waardoor de interne werking niet hoeft te worden doorgrond. Dit vermindert de complexiteit en daarmee de foutgevoeligheid. Intensief hergebruik levert veel voordelen op, en niet alleen op het gebied van het vermijden van programmeerfouten. Toch zijn er veel ontwikkelaars die denken dat zelfs de meest elementaire functies toch maar beter door henzelf kunnen worden ontwikkeld. Dat is schadelijke zelfoverschatting die steeds duurder betaald wordt. Intensief hergebruik leidt overigens tot een verschuiving van de testactiviteiten: de correcte werking en de betrouwbaarheid van de externe software krijgt de hoogste prioriteit.

2. Genereren. Er komen steeds betere hulpmiddelen om code te genereren uit ontwerpmodellen, of zelfs uit specificaties in een al dan niet natuurlijke taal. De meest populaire en gestandaardiseerde aanpak is Model Driven Architecture (MDA) maar ook Microsoft timmert aan de weg met Domain Specific Languages (DSL’s). Pioniers als de voormalige softwaregoeroe en ruimtetoerist Charles Simonyi werken zelfs aan concepten waarin specificaties in natuurlijke ‘business-taal’ (bijvoorbeeld een taal speciaal bedoeld voor het beschrijven van pensioenregelingen) gelijke tred houden met een vastlegging in programmacode. Specificaties van een hoger abstractieniveau zijn makkelijker te begrijpen en bieden een grote expressiekracht. Daaruit kan veel foutloze en efficiënte code worden geproduceerd met behulp van een – uiteraard uitputtend getest en geoptimaliseerde codegenerator. Grootste valkuil: zelf die generator willen ontwikkelen en onderhouden, een nadrukkelijk te mijden hobbygebiedje voor verveelde programmeurs, op zoek naar nieuwe uitdagingen.

3. Standaardpakketten. Steeds meer organisaties merken dat hun bestaande, zelfgebouwde systemen tot een ondoordringbaar moeras zijn geworden. Het onderhoud ervan kost evenredig veel tijd en de kans op fout neemt alleen maar toe naarmate de oorspronkelijke ontwikkelaars gaandeweg verdwijnen, de documentatie minder enthousiast wordt bijgehouden en de programmatuur obese trekjes begint te vertonen. Opnieuw bouwen op een modern platform is een optie maar het gaat vaak om grote systemen, omvangrijke projecten en daarmee een sterk toegenomen kans op fouten. Standaardpakketten en ERP worden in dit licht nu snel tot een niet te negeren constante, zelfs in bastions waar van oudsher veel huisvlijt voorkomt, zoals de overheid en financiële instellingen. Laat ze zich in Waldorf maar druk maken over het vermijden van bugs, dat is zo ongeveer de redenering. Natuurlijk moet standaard software verder minstens zo uitgebreid worden getest als de eigengemaakte brouwsels. En er loert een addertje onder het gras: het uitgebreid ‘customizen’ van een pakket is hetzelfde als nieuw bouwen, maar dan omslachtiger en met grotere risico’s.

4. Eigen middleware de deur uit. Het leek toentertijd zo’n goed idee: je eigen middleware ontwikkelen om in één klap met steeds terugkerend, infrastructurele softwarefuncties af te rekenen. Maar de jaren zijn verstreken en de industrie heeft ondertussen software ontwikkeld die hetzelfde ‘loodgieterwerk’ doet, maar dan op basis van open standaarde en hoogstwaarschijnlijk een stuk effectiever en robuuster uitgevoerd. Daar zit je dan - met de Wet van de Remmende Voorsprong ter hoogte van je maagstreek - opgescheept met complexe en uiterst gevoelige code die allang geen onderscheidende waarde meer levert. Het is een pijnlijk traject, maar de migratie naar industriële software, al dan niet uit de Open Source wereld – levert in dit geval een opgelucht en veilig gevoel op. Er moeten dus alarmbellen rinkelen op de ontwikkelafdeling die er nog een eigen Enterprise Service Bus, transactiemonitor, database, portal, GUI Handler of Object-to-Relational Mapper op nahoudt.

5. Proceslogica en bedrijfsregels isoleren. Met de komst van een nieuwe generatie Business Process Management (BPM) en Business Rule Engine (BRE) systemen moet elke ontwikkelaar zich serieus afvragen waarom er nog allerlei proceslogica en bedrijfsregels ‘hardcoded’worden ingebakken in de software. Ze samen met de gebruikers in een apart systeem vastleggen - in een taal die door de bedrijfsvoering wordt begrepen – scheelt niet alleen een hoop coderen maar slaat ook nog eens een brug tussen technologie en bedrijfsvoering: het gebied waar van oudsher de meeste misverstanden ontstaan. Overigens kan op dezelfde manier met Business Intelligence worden omgegaan: rapportages, scorecards en dashboards klik je met gespecialiseerde hulpmiddelen aan elkaar; daar komt geen programmeren meer bij kijken. Natuurlijk kun je in bedrijfsregels of in procesbeschrijvingen ook fouten maken, maar de gevoeligheid voor echte ‘bugs’ en inbraken van buitenaf neemt overduidelijk af.  

6. Complexe constructies vermijden. Zinloze complexiteit in de IT, vroeg of laat gaan we er de eerste Stille Tocht omheen meemaken. Ontwikkelaars zwermen als vliegen rond complexe constructies als dynamisch polymorfisme, multiple inheritance en xml-to -object-to-relational mapping (en terug). Niet omdat ze die constructies nodig hebben, maar omdat ze worden aangetrokken door lekker foute, analytische uitdagingen. Waarom immers zou je informatie gewoon gestructureerd in een simpele relationele database opslaan – eventueel vergezeld van compacte, doelgerichte triggers en benaderd met SQL – als je er ook een hele objectgeoriënteerde muur omheen kan optrekken? Inclusief alle benodigde transformaties en conversies die daaromheen moeten worden gebouwd, geeft dat een stuk meer beroepsmatige voldoening. En veel programmeertalen evolueren van de weeromstuit mee Java is met al zijn uitbreidingen een kind met een waterhoofd geworden en zelfs het kinderlijk eenvoudige Basic is topzwaar geworden door alle overbodige verbeteringen. Versimpeling is een van de grootste uitdagingen voor de programmeur: met minder constructies om rekening mee te houden, blijft het hoofd koel en leeg, wordt uiteindelijk minder gecodeerd en worden ondoorgrondelijke fouten vermeden.

7. Simpelere programmeertalen. Als de eerstgenoemde 6 verschijnselen serieus zijn genomen, zou het vroeg of laat kunnen gaan opvallen dat er helemaal niet meer zoveel valt te programmeren. Misschien willen we vooral kunnen orkestreren en lijmen en is het goed mogelijk dat onze gebruikers zelf hun applicaties – in ‘mashup’ stijl - bij elkaar klikken. Wie weet passen we samen met die gebruikers de in semi-natuurlijke taal opgestelde bedrijfsregels wel ter plekke aan. Een mooi moment om eens na te gaan of we werkelijk moeilijke, foutgevoelige programmeertalen als Java of C# nog nodig hebben. Met vereenvoudigde, doch krachtige gereedschappen – zonder verleidelijke zijweggetjes en onnodige dikdoenerij – wordt met een minimum aan code het maximale resultaat bereikt.
Als je geen code schrijft, kun je ook geen fouten produceren. Een waarheid als een koe. De Top 25 van meest gevaarlijke programmeerfouten blijft altijd relevant maar de afhankelijkheid ervan kan sterk worden verminderd door uit de buurt van duistere gebieden te blijven. Niets minder dan een cultuuromslag voor een vakgebied dat van oudsher juist de problemen opzoekt.

KATERN

Onlangs werd een lijst gepubliceerd van de 25 programmeerfouten die het vaakst leiden tot ‘cybercrime’ en andere problemen rond websites. De lijst is opgesteld in een samenwerkingsverband tussen het SANS instituut voor online beveiliging en MITRE, een organisatie die werkt aan publieke kennisdeling rond software engineering en IT. Aan het onderzoek werkten experts van meer dan 30 organisaties mee, waaronder softwareproducenten, universiteiten en de Amerikaanse Overheid. Een beperkt aantal fouten uit de lijst blijkt aan de oorsprong te liggen van het overgrote deel van de ellende rond niet minder dan 1,5 miljoen websites. De problemen variëren van het eenvoudigweg ‘down’ gaan van sites tot en met het stelen van persoonlijke en financiële informatie van bezoekers en het op afstand overnemen van computers.

In de bijna humoristisch beschreven lijst van fouten zijn geheide klassiekers opgenomen als ‘de input onjuist valideren’ en ‘niet binnen de grenzen van een geheugenbuffer blijven’ (met speciale dank aan de op dit gebied buitengewoon getalenteerde programmeertalen C en C++). Maar ook moderner spul als ‘onveilige scripts van andere websites gebruiken’ en ‘cruciale informatie in foutmeldingen opnemen’ heeft een prominente plek gekregen. De lijst bevat voor elke fout aanbevelingen voor preventieve maatregelen.

Zie voor meer informatie het artikel in Automatisering Gids nummer 3, 16 januari 2009.

Benjamin Button operating system

Must have been very disappointing. ‘The Curious Case of Benjamin Button’ got a record number of nominations for the Oscars, but only won three minor awards. It won’t provide any solace, but I certainly would have granted the movie my personal award for ‘Best Metaphor for IT-related Subjects’. When I watch Brad Pritt mature from a baby in a old-mans body to a man in the strength of his life, then finally end as an old man in a baby’s body, I can’t help but relating it to – well - operating systems.

A sad example of an occupational disability indeed.

But think about it: most operating systems by now are complete ready for some life cycle reversal. And I am not just talking about Microsoft Windows. I recently bought the 2009 editions of Apple’s iLife and iWork software suites. What a bulky bunch of fat client applications that really is. Spontaneously, it starts to feel like an anachronism. As I wait for the huge software stack to install itself from DVD, I realise that I don’t even know what new features are contained in this edition. What can I say? I am one of these unquestioning Apple junkies. Eventually, I find an interesting functionality in iPhoto: self-calibrating face recognition software scans your photo library, identifies people and tags them in handy categories. With the size of my library, the initial scan takes more than 5 hours. It fully absorbs my poor Dual Core Apple Mini and I think about how an optimised, Googlified server farm probably could have done the job in seconds. No doubt it also would do much better in storing the photo’s. And in processing the movies I am editing. And in managing the music that I buy from iTunes. So what will be the point of the 2010 editions – and beyond – of this type of applications and the operating systems that run them?

If infrastructure, processing and storage moves to the cloud, we need lighter client operating systems. They need to be optimised to communicate with whatever is inside the cloud and deal effectively with user interaction. That’s about it. Quite a different mission statement. Operating systems will grow smaller and as they mature, they will start to look younger.

The signs are everywhere. The new Snow Leopard release of OS X will be lighter and faster, rather than rich on additional features. Linux suppliers are slimming down their distributions, also to make them more suitable to the new generation of cloud-enabled Netbooks. Also, there are some new players knocking on the door. Palm’s much anticipated WebOS is really a denial of an operating system, purely designed to connect to the Internet and then let the exciting things happen elsewhere (which actually is a move back to the no-nonsense roots of the company). And we can only speculate what Google’s Gdrive might supply through its expected support for booting from the network: could it be a small, lean and mean operating system (‘G’ would be a nice name) that only contains the features needed to run the Chrome browser?

Realising this, it seems like a missed opportunity for Microsoft to position Windows 7 as just a new version of Vista with some additional functionality. Especially if we know that it will feature a powerful virtual machine that can run older versions of the operating system. With some reckless courage, Microsoft could have created a small, cloud client OS – just imagine, ostentatiously developed in open source - that would include a virtual window to run any legacy Windows application (in the cloud, obviously). It has been done before: it proved to be the only way for Steve Jobs to migrate from legacy OS 9 to the dramatically different, Unix-based OS X.

Oh well, just another scenario that did not make it into the nominations.

In any case, the client operating systems of the near future will look lighter, younger and in general very different from how they look now. And finally, on one day, they will just seem to have gone, leaving us wondering what we were bothered with in the first place. A curious reverse life cycle, that I will gladly watch.

Just sit back and let the movie play.

First published on Capgemini's CTO blog

The Best Code is No Code: 7 ways to avoid errors by programming less

Just recently the SANS institute and MITRE published a Top 25 list of most dangerous programming errors that lead to cyber crime and other problems with websites. Experts from more than 30 organisations – including software companies, universities and the US government – collaborated in creating the list. One of the findings is that just a small number of errors cause the bulk of problems around nothing less than 1.5 million websites. Problems vary between sites simply ‘going down’ to theft of personal and financial information and complete computers being taken over from remote locations.

The list is well worth to read – it’s written in an unexpected, humorous style – and it is mandatory, educational stuff to software engineers and cyber criminals the like. However, the list notoriously misses the biggest cause for critical errors in software: simply too much software is still being coded. It shows that IT yet is a painfully immature profession. The practitioners stubbornly persist in creating their own problems and then – with great aplomb – come up with lists, articles, methodologies and books to solve them. It’s like turning all the taps on in the house and then proudly pulling out the newest, moist-absorbing mop. With more software being hand-coded, the risk of errors increases. And although many programmers may share a nostalgic sentiment on producing their code line by line, it does not serve efficiency or security.

The best way to avoid dangerous coding errors is to code less. Here are 7 ways to achieve that:

1. Reuse. More and more basis functionality is covered in frameworks and other reusable components, services and libraries. This material may have been developed within the organisation or by an external source. Because we are dealing with code that is approved for reuse, we may assume that the software has been thoroughly tried and tested, in any case well above average. The software only needs to be used, so no need to understand its inner working. This reduces complexity and - with that – the sensitivity to errors. Yet, many developers believe that even the most elementary services should be created by themselves. A harmful case of inflated ego, with a high price to pay for. Incidentally, explicit reuse leads to a shift in testing activities: the correct functioning and the reliability of external software gets the highest priority.

2. Generation. Better tools become available to generate code from design models and specifications, possibly even articulated in a semi-natural language. The most popular and standardised approach seems to be Model Driven Architecture (MDA) but keep an eye on Microsoft’s Domain Specific Languages (DSL’s) as well. Pioneers like software guru and former space tourist Charles Simonyi even work on concepts in which specification in various ‘business languages’ (for example a language to describe life insurance calculation rules) are continuously synchronised with programming code. Specifications on a higher level of abstraction are easier to understand and offer more expressive power. And from them, error-free and efficient code can be generated, obviously with the help of an exhaustively tested and optimised code generator. Biggest pitfall: developing the generator yourself, a dangerous hobby horse for bored programmers, looking for new challenges.

3. Standard packages. More and more organisations find that their existing, bespoke systems have turned into an impenetrable swamp. Maintaining them demands a disproportional amount of time. And the risk of errors only increases further with the original developers gradually disappearing or retiring, the documentation getting less up-to-date and the code starting to show obese features. Rebuilding the entire system on a modern platform is an option, but this will often turn into big, monolithic designs, massive programmes and – you get it by now – a higher risk of errors. In this context, standard packages and ERP now quickly become the unavoidable default, even in do-it-yourself bastions such as government and financial services. Let Waldorf deal with the bugs, that is roughly the way of reasoning. Of course, standard software must be carefully tested – just as bespoke solutions- and there is a catch: extensive customisation of a standard package is really the same as building solutions from scratch. Only more laborious and with bigger risks.

4. Get rid of own middleware. Back then, it seemed to make such good sense. Developing your own middleware and at one go deal with all these recurring, infrastructural software functions. But the years have gone by and the software industry has developed solutions that handle the same plumbing, only based on open standards and probably a lot more robust and effective. Here you are, with the Dialectics of Progress working on your stomach, saddled with complex and hyper-sensitive code that has lost its added value already a long time ago. It might a painful migration toward industry-strength solutions – possibly from Open Source – but eventually it will lead to relief and a more secure feeling. So let the alarm bells ring whenever developers are working on their own Enterprise Service Bus, transaction monitor, application server, database, portal, GUI handler or object-to-relational mapper.

5. Isolate process logic and business rules. With a whole new generation of Business Process Management (BPM) and Business Rule Engine (BRE) platforms emerging, developers must seriously ask themselves why they are still hard-coding process logic and business rules into their software. Defining logic and rules together with the actual business users – applying a language that is easily understood at the business side – not only saves on the volume of code but also bridges the gap between business and technology: an area where most of the misunderstanding still starts. And for that matter, the same principle applies to business intelligence solutions: reports, scorecards and dashboards nowadays are clicked together with specialised tools, without any programming. And of course, externally defined business rules and process logic can also contain errors, but the sensitivity to ‘real’ bugs and threats from outside clearly decreases.

6. Avoid complex constructions. Useless complexity in IT, sooner or later we will have riots in the streets because of it. Developers swarm like flies around complex constructions as dynamic polymorphism, multiple inheritance en xml-to-object-to-relational mapping (and vice versa). It’s not that they actually need these constructions. It’s more about being attracted by the wrong category of heroic, juicy challenges; just because they can. Why would you store your information straightforward in a simple, relational database, maybe accompanied by some SQL triggers, if you can do the same in that shiny new, perfectly incompatible object-oriented system? Including all the monstrueus mappings, morphing, translations and conversions that needs to be built, it provides a much more satisfactory experience. Professionally speaking, that is. And on the rebound, many programming languages evolve in the same direction. Java – with all its additional features has become top-heavy and even the childishly simple Basic language is overfed with confusing capabilities. Achieving simplicity is the single most important challenge to every software engineer. With less distracting constructions to oversee, the mind stays cool and calm. Eventually that leads to less code and less incomprehensible errors.

7. Simple programming tools. Speaking of programming languages: if we take the other 6 measures seriously, sooner or later we might notice that there is not that much programming left to do. Maybe we want to stick to orchestrating services and gluing components. Our users may be clicking their own solutions together, in true mash-up style. Who knows, we might be adjusting process logic ‘on the fly’ by configuring graphical process models or semi-natural language definitions. A good time to reconsider. Do we really need difficult, error-prone programming languages as Java and C# anymore? Honestly? With simplified, yet highly expressive tools – without all the seductive side-roads and unnecessary whistles and bells – we achieve maximised results with a minimum of code.

If you don’t write code, you cannot produce errors. It is as simple as that. The Top 25 list of most dangerous programming errors is and stays relevant. But our dependency on it can be decreased, just by staying out of the wrong neighborhoods. Nothing less than a cultural landslide to a profession that from way back likes to look for trouble.

First published on Capgemini's CTO blog

IT Executive column: Winterkou

De winter heeft hard toegeslagen in Noorwegen. Oslo ligt bedekt onder een dik pak sneeuw. Als ik de avond voor mijn spreekbeurt aankom, wandel ik door de nachtelijke stad naar het hotel. Mijn voetstappen kraken gedempt in dit knusse, doch ijskoude Anton Pieck-tafereel.

Onlangs verhuisde een bevriende Indiase collega met zijn hele gezin naar Oslo ‘omdat onderzoek uitwijst dat de Noren het meest gelukkige volk ter wereld zijn’. Eens kijken hoe hij tegen deze wetenschap aankijkt nu de gevoelstemperatuur in de nacht steeds tegen de -25 aankruipt.

Maar toegegeven, de volgende ochtend is de sfeer onder de verzamelde it-ers in het congrescentrum opperbest. Uiteraard roert de crisis zich ook hier, zelfs met al die enorme olievelden voor de kust. Toch is er een breed beleefd gevoel dat er met informatietechnologie juist in een tijd van economische tegenwind veel bereikt kan worden.

Dat wordt duidelijk in het conferentiespoor waar mijn voordracht deel van uitmaakt. Het onderwerp is ‘Business Intelligence’. En waar we in Nederland er nog wel eens een chagrijnig onderzoeksrapportje willen uitpersen over het gebrek aan opbrengst van BI-projecten, ontbreekt hier elke twijfel: informatie en inzicht zijn broodnodig in alle aspecten van de bedrijfsvoering. En juist in een tijd van crisis moet je daar niet op beknibbelen.

Ga maar na, als je kosten wil besparen in de operationele processen zul je gedetailleerd moeten weten waar de kosten worden gemaakt. Als je een betere greep op je klanten wilt hebben – alleen al om ze te behouden – zul je diep in de client analytics moeten duiken. Wie veel kritischer wil zijn op de producten- en dienstenportfolio zal een helder beeld nodig hebben van de prestaties in de markt, afgezet tegen de gemaakte kosten. Als de doorstroom in de supply chain begint te haperen, heb je steeds geactualiseerde informatie nodig om het uiterste te halen uit voorraden en toeleverlijnen.

En een teruglopend werknemersbestand vereist een scherp inzicht in de capaciteiten en kennis die zich nog wel in de organisatie bevinden. Hebben we het nog niet eens gehad over de weer helemaal hippe tweelingzusjes Vertrouwen en Transparantie, op zich al genoeg aanleiding om nieuw leven te blazen in de activiteiten rond Business Intelligence en Master Data Management.

Ze houden de moed er goed in, die Noren. Je stapt bijna vrolijk ‘s middags de winterkou weer in. Buiten ligt de sneeuw een halve meter hoog, maar de treinen rijden gewoon op tijd. Een schrale troost voor mijn vriend uit India, maar geluk zit nu eenmaal vaak in kleine dingen.

Gepubliceerd in IT Executive magazine, 25 februari 2009

The Continuous Position Tweet - Google Latitude

Well, since I now own a Windows 6.1 smartphone anyway (please. don't even start to make lame jokes, I've heard them all before inside my head), I thought this would be a good time to experiment with Google's Latitude. Latitude is a service that we saw coming for quite some time, now didn't we: using GPS and the cell-network, your current position is constantly monitored and broadcasted. Other people subscribe to it - essentially like they would with Twitter - so that can follow you in realtime on Google Maps. I'ts really like a continuous Tweet about your position ('on the A12, two kilometres further on the A12, in a traffic jam, moving again on the A12')  and we can only imagine what combining a few web services will lead to in the forthcoming weeks and months. Expect wild imagination! For now, only my assistent, my brother and a colleague are connected in realtime. Already quite interesting. My colleague starts early in the morning in the offices and my brother travels around the strangest, remote places in the Netherlands. And my assistent? Well, definitely, finally, nothing to hide for her anymore.

More about my adventures with The Continuous Position Tweet soon on this blog.

Software Release Magazine column: Dweilen (Dutch)

Een veilig gevoel, dat we vanaf nu in ons vakgebied een Top 25 van Meest Gevaarlijke Programmeerfouten hebben (even “Top 25 errors” googlen voor wie dat nog niet wist).

Als we de lijst van fouten doornemen komen we geheide klassiekers tegen als ‘de input onjuist valideren’ en ‘niet binnen de grenzen van een geheugenbuffer blijven’ (met speciale dank aan de op dit gebied buitengewoon getalenteerde talen C en C++). Maar ook moderner spul als ‘onveilige scripts van andere websites gebruiken’ en ‘cruciale informatie in foutmeldingen opnemen’. Heel leerzaam materiaal – ook voor hackers trouwens – en als ontwikkelaar zou je deze Top 25 eigenlijk uit het hoofd moeten leren (of gewoon taggen, onthouden is misschien teveel gevraagd).

Toch ontbreekt de allergrootste oorzaak van kritieke fouten in software: er wordt teveel software geschreven. Dit is een vakgebied waarin we hardnekkig zelf problemen blijven veroorzaken die we daarna met veel aplomb – desnoods begeleid door lijstjes – oplossen. We zetten eerst alle kranen in huis wagenwijd open en komen dan trots aanhuppelen met de allernieuwste vochtabsorberende dweil. Het lijkt me daarom een goed idee om de categorie ‘Onnodig Coderen’ aan de lijst toe te voegen. Ik heb alvast 7 suggesties voor de typerende misdragingen die je in deze categorie tegenkomt:

1. Hergebruik van code vermijden. Veel basisfunctionaliteit wordt gedekt in frameworks of andere – doorgaans grondig geteste – herbruikbare componenten. Toch zijn er veel ontwikkelaars die denken dat zelfs de meest elementaire functies toch maar beter door henzelf kunnen worden ontwikkeld. Schadelijke zelfoverschatting.
2. Generen van code vermijden. Laten we er eens vanuit gaan dat er ontwerpmodellen zijn of specificaties in een al dan niet natuurlijke taal. Daaruit kan veel foutloze code worden gegenereerd; een te mooie kans om te missen. Grootste valkuil: zelf de generator willen ontwikkelen. Zie ook 4.
3. Standaardpakketten niet overwegen. Steeds meer software die we vroeger zelf moesten bouwen komt nu uit de laboratoria van de ERP-leveranciers. Laat ze zich in Waldorf maar druk maken over het vermijden van bugs. Standaard bedrijfsfuncties moeten door standaard software worden ondersteund.
4. Zelf middleware ontwikkelen. In een schimmig verleden heb ik ooit ook een windowing systeem en een transactiemonitor geschreven. Vroeg of laat word je altijd achterhaald door veel betere producten van gespecialiseerde leveranciers. Tijd voor alarmbellen bij de neiging om eigen ESB’s, codegeneratoren, portals en object management systemen te bouwen.
5. Proceslogica en bedrijfsregels hard coderen. Met de komst van een nieuwe generatie Business Process Management (BPM) en Business Rule Engine (BRE) systemen moet elke ontwikkelaar zich serieus afvragen waarom er nog allerlei proceslogica en bedrijfsregels hardcoded worden ingebakken in de software. Ze samen met de gebruikers in een apart systeem vastleggen - in een taal die door de bedrijfsvoering wordt begrepen – scheelt niet alleen een hoop coderen maar slaat ook nog eens een brug tussen technologie en bedrijfsvoering: het gebied waar van oudsher de meeste fouten ontstaan.
6. Complexe constructies opzoeken. Zinloze complexiteit in de IT: vroeg of laat gaan we er de eerste Stille Tocht omheen meemaken. Dynamisch polymorfisme, multiple inheritance, xml-to -object-to-relational mapping (en terug): we zwermen als vliegen rond complexe constructies. Niet omdat we ze nodig hebben, maar omdat we worden aangetrokken door lekker foute, analytische uitdagingen.
7. Verkeerde programmeertalen toepassen. Als we de eerstgenoemde 6 verschijnselen serieus hebben genomen, zouden we wel eens kunnen merken dat er helemaal niet meer zoveel valt te programmeren. Misschien willen we vooral kunnen orchestreren en lijmen. Een mooi moment om eens na te gaan of we werkelijk moeilijk, foutgevoelige programmeertalen als Java of C# nodig hebben.

Als je geen code schrijft, kun je kortom ook geen fouten produceren. Draai de kraan maar dicht. En vergeet die dweil.

Gepubliceerd in Software Release Magazine #1, Februari 2009

Nicholas Carr levert half werk...

... zowaar een quote van uw blogger. Als onderdeel van een artikel in Computable van Teus Molenaar over het boek The Big Switch van IT-journalist Nicholas Carr.

We doen nog even een andere quote: "Als het bloed aan de muren zit", vervolgt Tolido, "breken innovaties vaak sneller door; eenvoudigweg omdat fijngevoeligheid en draaikonterij even niet in het woordenboek staan."

Leest u anders hier even deel 1 van het artikel van Molenaar en hier dan deel 2, met de reacties uit de IT-industrie.

Certification means nothing ...

... and some other interesting topics around the maturing IT profession, interview with Ernst Fuld of the Dutch Network User Group and Ron Tolido. In (Dutch) IT magazine Computable: http://www.computable.nl/artikel/ict_topics/beleid/2858528/2379250/certificaten-zeggen-veel-te-weinig.html

TOGAF 9: A Sunny Day in San Diego

It’s just a standard day in San Diego. That is to say, the friendly people over here are kind of used to blue skies and summer temperatures at the beginning of February. On the other hand, these days are quite special. The Open Group just released version 9 of TOGAF (The Open Group Architectural Framework) at its first 2009 conference, and I am convinced that we are witnessing nothing less than a breakthrough in the world of Enterprise and IT Architecture. Consider it: the role of architecture as a crucial tool to put strategy into practice is becoming more and more prominent. After all, architecture always has been the antidote to complexity, misalignment and lack of direction. And these are exactly the phenomena we have to deal with in the typical business / IT climate of today.

A sign of a maturing craft is standardization: the availability of repeatable processes, clearly defined results, reusable best practices and the tools to support that all. In the world of Enterprise / IT architecture, entire careers have been dedicated to creating methodologies, frameworks and meta-models. Actually, some made a career out of comparing and selecting methodologies and yet others managed to create frameworks to assess frameworks (go ahead, take your time to fully appreciate this). In the end, every architect seemed to own his or her own methodology and more than once, I had the feeling architects were more occupied with discussing methodologies and frameworks than actually using them. Yes, architects were brought together. But only to discuss their differences.

These days might finally be over now. TOGAF 9 will further strengthen its position as the de facto standard for Enterprise and IT Architecture. And not even primarily because of its superior methodological content (although the list of enhancements to the previous version is very elaborate and convincing and we find SOA, iterative principles and even the acknowledgement of standard packages in the new TOGAF), but much more because TOGAF 9 is the result of an open and collaborative industry consensus process.
We are delivering change in a globalised world and we need methodological tools that are recognized and accepted across the globe. Not just by one region. Not just by one company. And certainly not just by one architect. The only way to produce a standard like that is transparent collaboration between many parties that are all ready to bring in their valuable knowledge, experience and assets.

A true meritocracy indeed, and I can only say that I was proud to see my colleagues Mike Turner, Mick Adams and Den Donovan play such a visible role in the conference program. They have been instrumental in creating some of the crucial new elements of TOGAF 9 and they were not afraid to bring in years of knowledge and experience with our own, internal framework (IAF, Integrated Architecture Framework).

A lot has already been said and twittered about TOGAF 9, so let me just point you to a few useful blogs and articles. Nick Malik of Microsoft sees “substantial and deep improvements in TOGAF 9, and so does his colleague – and Architecture Strategist – Mike Walker: “Whether you are using TOGAF in your organization or not TOGAF 9 is definitely a framework you want to evaluate. I didn’t find anything that was negative about TOGAF 9. Even though there are some gaps and some areas that could be more developed the bits that are refined were really good.” Then you should have a look at the blog of Dana Gardner on ZDNet that offers several briefings of the launch. Elemental Links also provide useful first impressions, and you also will find some really nice live-blogs of some of the conference presentations. David Linthicum on Infoworld claims “TOGAF means better architecture” and Beth Gold-Bernstein on ebizQ argues that the “death” of SOA is due in a large part to the fact that organizations are not adept at enterprise architecture discipline. Finally, Wayne Horkan of SUN sees TOGAF as the key to establish a common language for architects - “I see TOGAFs main value in bringing a common and standardised language, set of semantics and terminology to Enterprise Architecture.”

And that is exactly the point: having such a contemporary standard marks an important maturity step within the profession. And even better, architects don’t need to spend time on discussing and comparing methodologies and frameworks anymore. Imagine, they could all go to their clients instead and actually create marvellous Enterprise and IT architectures.

Oh well, just another working day in sunny San Diego.

First published on Capgemini's CTO blog