Sinds er software ontwikkeld wordt is één van de grootste uitdagingen daarbij hoe je ervoor zorgt dat je precies bouwt wat nodig is. Hoe houd je de afstand tussen klant en ontwikkelaar klein, terwijl er allerlei krachten werkzaam zijn die die afstand juist vergroten? Bijna iedere methode of programmeertaal belooft een oplossing voor dit probleem.

Neem COBOL, één van de oudste programmeertalen: de naam COBOL betekent COmmon Business Oriented Language.  Het idee was dat met COBOL business mensen zelf konden programmeren. Dat is nooit gelukt natuurlijk. COBOL wordt algemeen beschouwd als een moeilijke programmeertaal, en COBOL programmeurs, hoewel een uitstervend ras, blijven nodig om de enorme hoeveelheid COBOL programmatuur die nog altijd in gebruik is te onderhouden.

SQL, zelfde verhaal. In SQL vertel je de computer, of de database eigenlijk, wat je met de gegevens wilt, maar niet hoe. Inmiddels wordt SQL zelfs voor gemiddelde programmeurs als te moeilijk beschouwd, en zijn er Object-Relational Mappers om ze tegen de “complexiteit” van SQL te beschermen.

Volgende kandidaat: UML.  We maken diagrammen, plaatjes die gebruikers kunnen begrijpen of zelf maken, en een code-generator die de plaatjes vertaald naar programma’s, en de gebruiker is weer “in control”. Ook deze aanpak, hoewel vrij recent, is inmiddels weer uit de gratie. Zie mijn eerdere post “Wat is er nieuw aan Model-Driven Development?“. Het gebruik van DSL’s in plaats van UML helpt wel een beetje, omdat een DSL nu eenmaal eenvoudiger is. Maar de verwachting van sommigen, dat het domein specifieke karakter van een DSL betekent dat een domein expert ermee kan programmeren kunnen we op basis van de eerdere voorbeelden gerust als naïef beschouwen. Al is het maar omdat het domein van een DSL vrijwel nooit het domein van de gebruiker is, maar dat van de programmeur.

Goed, nieuwe programmeertalen of in het algemeen technische hulpmiddelen helpen dus blijkbaar niet om de kloof tussen gebruiker en programmeur te verkleinen. Laten we het helemaal anders aanpakken. We hebben architecten nodig die de gebruiker helpen om de processen van zijn organisatie in kaart te brengen, en de automatisering daar precies op te laten aansluiten. En we introduceren een Service Oriented Architecture (SOA), zodat alle applicaties makkelijk met elkaar kunnen communiceren via services, en een process engine waarmee we de processen heel direct kunnen ondersteunen door de services in de juiste volgorde aan te roepen. Alleen, SOA experts worden niet moe om te benadrukken dat een SOA niet makkelijk in te voeren is in een organisatie, dat de beoogde voordelen – snelle aanpasbaarheid van de automatisering aan de veranderende eisen van de business – pas na jaren behaald zullen worden. Tenminste, als de invoering op de juiste manier wordt gedaan, en er gezorgd is voor een goede inbedding in de organisatie.  Governance is hier het toverwoord.

Klinkt allemaal prachtig, maar ik geloof er geen woord van. Ten eerste, hoezo snelle aanpassing aan veranderende eisen, als je eerst jaren moet investeren?  Ten tweede, governance wekt bij mij de associatie van “programming by commitee”. Moet dat sneller gaan dan programmeren door één of twee programmeurs? Ten derde, nu zitten de architecten tussen de gebruiker en de ontwikkelaars, zodat de afstand juist groter geworden is. De goede niet te na gesproken natuurlijk, maar veel van deze architecten hebben weinig affiniteit met de praktische problemen waar programmeurs mee te maken hebben bij het implementeren van een SOA. Ik hoor architecten vrijwel altijd klagen dat de programmeurs zich niet aan hun richtinggevende kaders houden. Hoe zou dat toch komen? Even opvallend is dat die organisaties de er een aparte afdeling architecten op na houden meestal ook degene zijn waar het hele software ontwikkelproces vrijwel tot stilstand is gekomen.

Is er dan helemaal geen hoop? Jawel, die is er. Die projecten die radicaal agile werken, volgens eXtreme Programming, Scrum, Evo of hoe ze ook heten, met een on-site customer, behalen ook een radicaal hogere productiviteit, en bouwen wat de klant wil. Behalve dat de verhalen overtuigend klinken heb ik het ook zelf ervaren. Dat beviel zo goed, dat ik eigenlijk niet meer anders wil en misschien ook niet meer kan.

Ondanks de goede resultaten is er toch veel weerstand tegen agile methoden.  Eén veelgehoord bezwaar is, dat grote systemen niet zonder architectuur kunnen, en dat een agile werkwijze tot chaotische onbeheersbare systemen leidt. Het eerste is waar: architectuur is nodig. Het tweede is niet waar: agile leidt niet noodzakelijk tot onbeheersbare chaos. Maar agile is geen vervanging voor vakmanschap. Alleen de manier waarop de architectuur tot stand komt is helemaal anders. Architectuur is een bijprodukt van software ontwikkeling. Het ontstaat tegelijk met de software zelf, en niet vooraf.  Alleen dan is er hoop dat de architectuur als een maatpak bij de applicatie past.

Systemen zijn tegenwoordig zo ingewikkeld, dat ze niet zonder architectuur kunnen. Diezelfde complexiteit is er ook de oorzaak van, dat die architectuur niet meer helemaal vooraf bedacht kan worden. Wordt dat wel geprobeerd, dan leidt dat tot starre systemen die moeilijk veranderd kunnen worden, precies wat diezelfde architectuur probeert te vermijden. Immers, het hoeft niet meer veranderd te worden, er is toch van tevoren over nagedacht? Kortom architectuur moet, maar wel via een agile proces.

Het is nog geen 1 april, maar toen ik vanmorgen het onderstaande bericht las moest ik toch echt even denken aan een 1 april grap. In hoeverre dit waar is?

IBM onderhandelt met Sun Microsystems over een overname. Big Blue zou 6,5 miljard dollar voor Sun op tafel willen leggen en met de overname zijn positie op de internet-, software- en telecommunicatiemarkt willen versterken.

De twee Amerikaanse bedrijven zouden deze week al tot een overeenkomst kunnen komen, meldt The Wall Street Journal. De krant weet echter ook te melden dat er nog niets is beslist en dat de onderhandelingen ook zonder succes afgebroken kunnen worden. Sun heeft moeite om winst te maken en zou al meerdere bedrijven over een acquisitie gepolst hebben, maar tot nu toe zonder succes: onder andere HP zou Sun al de deur hebben gewezen. Voor IBM zou het de grootste overname in zijn geschiedenis zijn. Vorig jaar betaalde het computerbedrijf 5 miljard dollar om het in business intelligence gespecialiseerde Cognos in te lijven.

Met Sun in de gelederen zou IBM zijn omzet voor bijna een derde uit hardware halen, waar het zich de afgelopen jaren juist meer op software en diensten richtte. Verder hebben de multinationals een nogal verschillende bedrijfscultuur: het in 1982 opgerichte Sun richt zich vooral op innovatie, terwijl het uit 1911 stammende International Business Machines zich met name op de vraag in de markt oriënteert. Aan de andere kant zijn er de nodige overeenkomsten: de band met Microsoft en Intel is bij beide bedrijven niet sterk en zowel IBM als Sun leunen zwaar op Linux en Java.

Bron: http://tweakers.net/nieuws/59083/ibm-wil-sun-microsystems-overnemen.html

Afgelopen DeVoxx is een stemming geweest waar de bezoekers konden stemmen op hun favoriete nieuwe JDK 7 features.
De grote wijzigingen zijn natuurlijk allang bepaald, zoals !closures (niet dus), JVM optimalisaties voor scripttalen (JSR 292) en Java Module System (JSR 294), maar voor JDK 7 willen ze ook een aantal kleinere wijzigingen faciliteren.
Stephen Colebourne heeft op zijn blog een mooie samenvatting van de poll geplaatst.
Zoals je kunt zien, zitten er 3 populaire tussen:

1. Null handling
2. Infer generics
3. Multi catch

Properties is ook populair, maar deze komt sowieso niet in JDK 7.
Deze 3 populaire features zal ik even kort laten zien:

Null handling
Iedereen heeft weleens dergelijke code gezien:

if (myObject != null) {
    if (myObject.getProp() != null) {
        if (myObject.getProp().getProp() != null) {
            return myObject.getProp().getProp().getString();
        }
    }
}

Zou het niet relaxed zijn als je het zo kunt schrijven?

return myObject()?.getProp()?.getProp()?.getString();

Er zitten nog wat vergelijkbare constructies aan vast, zoals een aanpassing aan de ternary operator, zie Alex Millers blog.

Infer generics
Waarschijnlijk hebben jullie deze constructie ook weleens gezien? Zo nee, dan heb je waarschijnlijk nog geen JDK 5+ collections gebruikt.

List<String> list = new ArrayList<String>();

Dit is nog niet zo vervelend, maar wat dacht je van deze variant?

Map<String, AtomicReference<SoftReference<SomeObject>>> list = new ConcurrentHashMap<String, AtomicReference<SoftReference<SomeObject>>>();

Vrij lelijk als je het aan mij vraagt. En in de meeste gevallen is het niet eens nuttig, aangezien links en rechts van de assignment hetzelfde staat.
Wat dacht je hiervan?

Map<AtomicReference<SoftReference<SomeObject>>> list = new ConcurrentHashMap<>();

De haken aan de rechterkant geven aan dat de compiler de typespecificatie links van de assignment naar de rechterkant gekopieerd moet worden.
Zie wederom Alex Millers blog voor de details.

Ten slotte de Multi catch
Jullie hebben ook vast weleens dergelijke catch clausules gehad neem ik aan.

try {
    // Do something
} catch (Exception1 e) {
    LOG.error("Something horrible happened", e);
} catch (Exception2 e) {
    LOG.error("Something horrible happened", e);
} catch (Exception3 e) {
    LOG.error("Something horrible happened", e);
} catch (Exception4 e) {
    LOG.error("Something horrible happened", e);
}

“catch (Exception)” is niet netjes, hebben we allemaal geleerd. Voor je het weet, vang je onterecht een fout af. Maar al die code duplicatie zit je toch niet lekker. Vandaar een nieuw alternatief:

try {
    // Do something
} catch (Exception1 | Exception2 | Exception3 | Exception4 e) {
    LOG.error("Something horrible happened", e);
}

Dat is een stuk beter he? Vooral in combinatie met Safe Rethrow kan dit erg krachtig zijn.
Ik ben nog wel benieuwd naar de details, want wat is het type van “e”? Gaan ze op zoek naar een common supertype, of wordt het duck typing?
En weer een linkje naar Alex Miller.

Dusss…
Dit zijn maar een paar van de toevoegingen waar momenteel aan gewerkt wordt. Meer info over “Project Coin” op Joe Darcy’s blog.
En natuurlijk weer Alex Miller.