# Luminis Brain Upgrade: Quantum Computing

May 2nd, my colleague Piet van Dongen and I presented a Luminis Brain Upgrade on Quantum Computing.

Below, you'll find a set of references we used during this Brain Upgrade, making you ready for the upcoming quantum storm!

### Theory

A large part is based on IBM’s Quantum Experience Beginner’s Guide and their Tutorial. Most of the practical examples of the basic gates were created using the online Editor, where you can build your own experiments, which can run on IBM’s real quantum computer!

Main subjects we explored are,

• Encoding, Spin, Superposition, Entanglement and Measurement (see overview picture),
• the notion of Bounded-Error Quantum Polynomial: problems that can be efficiently solved by a Quantum Computer, and checked very quickly. This notion comes from this paper.

### Practice

The algorithms we explored were programmed in Q# and C# using Microsoft's Quantum Development Kit (Preview): https://docs.microsoft.com/en-us/quantum/?view=qsharp-preview.

The Bell State was based on the Q# quickstart example, see: https://docs.microsoft.com/en-us/quantum/quantum-writeaquantumprogram?view=qsharp-preview&tabs=tabid-vs2017. Quantiki has a nice explanation of the algorithm: https://www.quantiki.org/wiki/bell-state.

Grover's algorithm came directly from Microsoft's Q# sample library: https://github.com/Microsoft/Quantum/tree/master/Samples/DatabaseSearch. IBM has a nice explanation of the algorithm here: https://quantumexperience.ng.bluemix.net/proxy/tutorial/full-user-guide/004-Quantum_Algorithms/070-Grover's_Algorithm.html. For the more visually inclined, I showed this: http://davidbkemp.github.io/animated-qubits/grover.html.

### Luminis Quantum Nonsense Survival Guide™

• Will I use quantum computing? Very likely. IBM, Microsoft and Intel are all working on different areas of the same problem (technology and research, programming model, and hardware, respectively), and since there are valuable speedups to be gained, it will touch your desk within the next decade.

• Will I need to herd thousands of qubits? No. You don’t wrangle billions of transistors now, we have better abstractions for that.

• Will I (or my company) own a quantum computer? Very unlikely. The workloads are very specialized, and the machinery requires expert maintenance. You will most likely rent capacity from some cloud provider.

• Are we there yet? Well, no. Current best efforts are at a few dozen qubits in a single system, whereas interesting applications require at least hundreds or thousands of qubits.

Comment

# "What you didn’t know you wanted to know about the JVM"

At Luminis DevCon 2018, I presented my favourite talk to date, "What you didn’t know you wanted to know about the JVM". Video is up now. All materials can be found on Github.

Comment

# Surfaces & Essences

For Luminis' magazine Conversing Worlds, I wrote a review of Douglas Hofstadter's Surfaces & Essences.

Hofstadter is one of those authors with an ever-clearer arc of thought over his many books. Trained as a cognitive scientist, he has been dealing the concept of "I" and "meaning" for the better part of his career. In GEB, he built up definitions of meaning from first principles and recursion.
In Surfaces and Essences, he goes deeper into what is means to "mean" something. What does "the same" mean? How fluid can analogies be? Is there something like pure meaning? Does language even get close?

The best example in the books works with the notion of being "the same." Consider the situation in the beginning of the year, when every time you write a date you accidentally write the previous year. Now consider the situation of changing your name (because of marriage). For the first few months, you'll likely introduce yourself with your "old" name. Why do we say these things are "similar"? When zooming in on every part of this example, there is no basis for calling them "the same," but deep within, we feel there is some "sameness" about them.

In this way, everyone has his own reality, his "essences." These essences "surface" in the use of words, phrases, figures of speech. Even though the essences are different, these are calibrated through repeated use and interaction with other people, until they are similar enough to enable useful communication.
This also means there is no such thing as the so-called Platonic ideal: Plato claimed that for every human concept--he uses the concept of a horse--there is an ideal, eternal notion of a horse, far more perfect than any horse that can be observed by humans. Because everyone's essences are different, these ideals cannot exist.

In programming, we are constantly building worlds in this exact same way. Very few of the things we talk about (objects, records, events) actually exist in the real world, and when we do talk about real things, we often have a different idea of what is meant by a given term. The essences of all the worlds we build overlap, but are still distinct. The surfaces we use for describing this world (terminology, names of variables, classes, methods) have to be chosen carefully to convey the correct meaning. And that, kids, is why naming is so important!

This is a hefty book, coming in at over 500 pages. It takes a long time and setup to get to the point of showing you what it actually means, but it's also one of those books that you'll really need to chew on. If you're even slightly interested in the concept of meaning, and don't back out of challenging yourself, pick up a copy, and at least show it off to your friends by leaving it on your desk!

Comment

### Angelo van der Sijpt

Following a talk I did at iSense, Computable has now published an interview with me on the same subject.

# ‘Digitale dreigingen zijn feit van onze tijd’

Angelo van der Sijpt (Luminis) ziet kansen en geeft tips

Angelo van der Sijpt is fellow security & connected devices bij Luminis. Als engineer en architect heeft hij een neus voor het herkennen van patronen en vormen van succesvolle applicatietechnologieën. Hij ziet security en privacy als de grootste bedreiging - en daarmee als kans.

Van der Sijpt verdiept zich dagelijks in uitdagende onderwerpen die op hun kop zijn gezet door het internet, goedkopere maar capabele hardware, mobiele telefoons en last but not least het internet of things (IoT). Recent gaf hij bij iSense ICT Professionals een presentatie over hoe bedrijven en it’ers verschillend naar security kijken. ‘Security is ieders verantwoordelijkheid.’

## Verantwoordelijkheden in het midden

‘Wat je in de praktijk ziet, is dat het management van een organisatie denkt: we moeten iets met security', aldus Van der Sijpt. ‘Tegenover het management staat de it-afdeling, zij lopen tegen problemen aan waarvan zij niet weten wat zij ermee moeten. Daarom blijven de verantwoordelijkheden vaak in het midden liggen. Een engineer kan een mooi systeem bouwen, maar als hij dat niet op een veilige manier uitrolt, niet juist installeert of als het niet juist gebruikt wordt, levert dit beveiligingsrisico’s op.’

Van der Sijpt maakte recentelijk bij een webstore een account aan en kreeg daarna een accountbevestiging met daarin zijn wachtwoord. ‘Dit vertelt mij dat die organisatie niet zorgvuldig met mijn wachtwoord (en mogelijk andere gegevens) omgaat. Ik vermoed dat een projectmanager ooit dacht: dat is handig! Vervolgens heeft de engineer zijn schouders opgehaald en gebouwd wat de projectmanager heeft gevraagd. Als laatste heeft de system administrator een systeem opgezet waar de database op draait. De verantwoordelijkheid voor de data blijft hiermee in het midden liggen, terwijl het ieders verantwoordelijkheid is: signalerend, aansturend of oplossend.’

## Digital security ondergesneeuwd

Blijkbaar is het slecht gesteld met de digital security van Nederlandse bedrijven. Waarom denkt Van der Sijpt dat Nederlandse bedrijven achterlopen op dit gebied? ‘De gevolgen voor bedrijven door het onzorgvuldig omgaan met persoonsgegevens waren tot voor kort niet gekwantificeerd. Hierdoor is het onderdeel digital security bij bedrijven redelijk ondergesneeuwd.’

De conclusie dat het slecht gesteld is met de digital security van Nederlandse bedrijven heeft volgens Van der Sijpt te maken met onbekendheid. ‘In de praktijk willen bedrijven vaak dat het wel veilig is. Wat betekent veilig? Security is een veelomvattend probleem. Je kunt dit vergelijken met het beveiligen van jouw huis, dat je beveiligt door op elk raam een zwaar slot te zetten. Maar als jij één raam vergeet, dan maakt het niet uit hoe goed de beveiliging op al die andere ramen is, want een inbreker zal altijd het raam kiezen dat niet beveiligd is. Hetzelfde geldt voor security-incidenten, het is altijd de zwakste schakel die geraakt wordt. Staat er een firewall open? Is een productiewachtwoord gelijk aan een testwachtwoord en staat dit wachtwoord in een database? Zo zijn er ontzettend veel risico’s en het is moeilijk om deze allemaal in kaart te brengen.’

## GDPR

Tegenwoordig wordt in Nederland de wet- en regelgeving rondom digital security duidelijk. Dankzij de General Data Protection Regulation (GDPR) kunnen bedrijven tegenwoordig verantwoordelijk gehouden worden voor het onzorgvuldig omgaan met persoonsgegevens. Doen zij dit? Dan kunnen zij een boete krijgen die kan oplopen tot vijf procent van de wereldwijde jaaromzet.

‘Dit valt voor mij als persoon wel mee’, meent Van der Sijpt, ‘maar voor een bedrijf hakt dit behoorlijk in de marge. Mede om die reden verwacht ik dat we verbeteringen zullen gaan zien bij Nederlandse bedrijven als we het hebben over security.’

## Ransomware als WannaCry

In deze tijd hebben we echter met meer typen cyberaanvallen te maken. Neem ransomware. Hoe kunnen bedrijven zichzelf zo goed mogelijk beschermen tegen attacks zoals WannaCry? Van der Sijpt: ‘Naar mijn idee zit de beste beveiliging aan twee kanten: de voorkomende kant en de oplossende kant. Het leuke is: beide zijn niet technisch! Aan de voorkomende kant heb je eenvoudige zaken zoals het gebruik van e-mailfilters, maar denk vooral ook aan een security awareness training. Wat sommige grote bedrijven regelmatig doen is intern een phishing mail uitsturen en kijken wie er op klikt. Op het moment dat jij klikt kom je terecht in een zes uur durende security awareness training Geloof mij, er is altijd wel iemand die er in trapt. Eén persoon die op een verkeerde link klikt is genoeg om een compleet bedrijf over te nemen. Ditzelfde gebeurde met WannaCry.’

Aan de oplossende kant heeft Van der Sijpt ook nog wel wat aanbevelingen. ‘Zorg ervoor dat jij als bedrijf een recovery-plan hebt, bijvoorbeeld met goede backups die zijn getest. Het hoeft niet complexer te zijn dan dat. Welke maatregelen je ook treft, het kan alsnog misgaan! Het kan namelijk ook opzet zijn, zoals bij Yahoo waar een system administrator was omgekocht door hackers.’

## Tijdperk vol cyberattacks

Als het zo eenvoudig is om een gerichte aanval op een organisatie uit te voeren, is WannaCry dan nog maar slechts het begin van een tijdperk vol cyberattacks? ‘Sterker nog, we leven al in een tijdperk vol cyberattacks’, laat Van der Sijpt weten. ‘Als jij een apparaat onbeveiligd aan het internet hangt, dan is dat apparaat, afhankelijk van het type, binnen negentig seconden overgenomen. Zo werkt het Mirai-botnet bijvoorbeeld.’

Van der Sijpt verwacht daarom dat aanvallen agressiever zullen worden. ‘WannaCry was wat mij betreft een buitencategorie-aanval. Het maakte gebruik van een aantal geavanceerde kwetsbaarheden die een tijd daarvoor van de NSA gestolen waren. Deze kwetsbaarheden zaten al lang in Windows, ik vermoed dat de NSA hier nuttig gebruik van heeft gemaakt.’

## Tips voor it’ers

In antwoord op de vraag of hij tips heeft voor it’ers om de digital security te verbeteren, reageert Van der Sijpt met de opmerking dat je als it’er een voorbeeldfunctie hebt. 'Daarom is het belangrijk dat je verantwoordelijk met tools omgaat en niet hetzelfde wachtwoord gebruikt voor verschillende systemen.'

Daarnaast zijn er nog drie manieren waarop de it'er de digital security kan waarborgen bij het bedrijf waarvoor hij werkt:

• Zorg als it’er dat de systemen die jij gebruikt up-to-date zijn, of gebruik ze niet meer. De meest praktische aanvallen op bedrijven vinden niet plaats door een directe aanval op een firewall, maar door een Wordpress-servertje dat vier jaar geleden is opgezet en daarna is vergeten.
• Wees je ervan bewust dat het óók jouw verantwoordelijkheid is. Het is jouw taak om naar je manager te stappen en zaken te melden die jou opvallen in de digital security. Tegelijkertijd mag jij pleiten voor een security awareness-training voor de rest van het bedrijf.
• Ben je een engineer? Doe dan mee aan een hacking-event. Zo kom je erachter hoe eenvoudig het is beveiligingen te omzeilen.

## Tips voor bedrijven

We vroegen Van der Sijpt ook om tips voor bedrijven voor het verbeteren van hun digital security.

Zoals hij al eerder aangaf, heeft het verbeteren van de digital security niet alleen met technologie te maken. Bedrijven kunnen verschillende dingen doen om de digital security te verbeteren:

• Verdeel de taken duidelijk. Maak iemand (binnen het managementteam) verantwoordelijk voor de veiligheid van het systeem en de data. Vaak is dit de infrastructuurmanager of chief information security officer.
• Zet security op de managementagenda. Maak security bespreekbaar. Verlaag de drempel voor engineers om naar het management toe te stappen over security-issues.
• Ga ervan uit dat het misgaat en bereid je passend voor. Zorg voor een escalatieplan met duidelijke uitwijk- en herstelplannen. Maak het communicatieplan onderdeel van het escalatieplan, zodat stakeholders binnen een redelijk tijdsbestek op de hoogte worden gebracht van de situatie en de oplossingen.
Comment

# How To Talk So Kids Will Listen and Listen So Kids Will Talk

For the Luminis internal magazine, Conversing Worlds, I wrote a review of Adele Faber's How To Talk So Kids Will Listen and Listen So Kids Will Talk in June 2015.

As a newly minted dad, I have an uncommon interest in all books on kids. I liked both Kluun's Help, ik heb mijn vrouw zwanger gemaakt and Borgenicht's The Baby Owner's Manual in this regard, but I read How to talk... without any kids being in the picture.
I was first put on track by Jeff Attwood, who blogged How to Talk to Human Beings in June of 2012. There, he heralds the book as a manual for communicating with all kinds of humans, not just children. And he's so right.

The book is all about communication: sending and receiving.  That’s why it's a shame that the Dutch translation (How2Talk2Kids, effectief communiceren met kinderen) dropped the listening part. It has six central themes, ranging from helping children deal with their own feelings, to encouraging autonomy and getting children out of their predetermined roles. In the end, all themes have a common thread: "it's more important to be understood than to be helped."
Each chapter contains techniques that are set up like a design pattern: examples of applicability, theory, counterexamples in the shape of comic strips, practical exercises, and pitfalls. You can pick each pattern and practice it for a while, as they are independent.
Techniques include empathic listening, encouraging elaboration without guiding, and labeling. If you have ever heard yourself say nothing at all and just nod, or say "oh, really, tell me about that," or "that must be really frustrating," you have practiced these techniques. Some techniques are geared toward children and their developing skills: for instance, one involves writing simple handwritten notes, which works well for children that just learned to read--or even for those who can't read yet, but are still more susceptible to a note than to spoken word.

These simple techniques can help you resolve tension in conversations. This tension can be between people, or just within your communication partner. For example, consider trying to ask for a bargain in a shop ("I understand you don't make the rules, but can you tell me about what you can do?" - empathic listening), bumping into a rowdy stranger at a bar ("Hey, I'm sorry, I feel like such an idiot now" - labeling feelings, even your own) and even with my newborn son ("I understand your belly hurts, and I wish I could make it all go away" - granting wishes in fantasy). The latter doesn't understand the words yet, but he understands the tone of voice.

You may have witnessed me using some of these techniques with customers and colleagues. ("Tell me about that. Uhuh. I understand why you're stuck with this design: it has more layers than you're comfortable with, and that makes you feel like you're just not good enough to pull this off. How about I help you pull those layers apart?”) Note that this isn't cheating or manipulating: or merely a technique to clear the air, and get back to the subject matter. Feelings can get in the way, and unacknowledged feelings will block communication.

All in all, I would highly recommend this book to anyone who has any interaction with other human beings in the course of their private life or career. Pick one or two techniques at a time, and just practice them whenever you feel the least tension arising in conversation. Hey, you might even impress your significant other with your kid management skills.

Comment

# PCI DSS for the IoT

IoT security is a sticky subject, with weird incentives. How about reusing PCI DSS rules to raise the bar?

# What every developer needs to know about cryptography

At JFall 2016, I gave a talk "what every java developer needs to know about cryptography." The material, including a cheat sheet to impress your colleagues and boss, is available on Github!

Comment

# Just enough crypto for the web

During my CodeMotion Berlin 2016 talk, I promised some references. Here they are!

# Making Evernote sync more often

File this one under first world problems: I use a headless Mac Mini for scanning documents, using my trusty ScanSnap, to Evernote, but every once in a while Evernote takes its dear time to synchronize.

To remedy this, I whipped up a piece of AppleScript that syncs Evernote when there are unsynced notes in the notebook called "inbox".

The script can be found on https://github.com/angelos/EvernoteSync.

Comment

# What caught my eye - 2016w08

Trying out something new here: an overview of the news that caught my eye this week. Not a high-rolling week to start out with.

## Moving clouds

### Netflix moves to Amazon's AWS (Ars Technica)

For the last seven years, it has been known that Netflix, one of the biggest movers of data on the internet, has been slowly phasing out their own data centers in favor of relying on Amazon's AWS offering. Having now closed their last own data center, they completed this move, showing that even massive scale isn't necessarily a reason for you own datacenters. Unless you're, like, Facebook.

### Spotify moves (a little) to Google (Stratechery \$, WSJ \$)

In a non-related move, Spotify, another mover of data and poster child for AWS, is moving a minor part of its hosting to Google. However, this probably won't keep Jeff Bezos up at night: the infrastructure being moved comes from Spotify's own data center, and Spotify got a pretty good deal. Sounds to me like Google drumming up fanfare for its own offerings, and Spotify taking the bait.

## Apple and the FBI (Ars Technica)

With the FBI requesting the unlocking of a locked iPhone in a pretty much indisputable case, and Apple's Tim Cook publishing an open letter about why he won't do so, the internet has clearly bifurcated in two camps.

On the one hand, we have the American people supporting the FBI, and we have the international Geek Community coming up with either good reasons why they shouldn't, and clever ways in which it can be done safely.

All things considered, this is a typical hard problem: damned if we do, damned if we don't. I feel Apple is rolling pre-canned privacy PR, to support their "we don't need your data"-case--but notice that this is not out of good will, but because Apple makes their money on hardware, in stead of advertising. As much as I would like to take the "either everybody gets privacy, or no one does," I feel that Apple is fighting the wrong fight here. Apple can't state that it's impossible to support the FBI in what they requested, and denying it will erode a lot of good will the company, and the tech industry in general. I fear ham fisted legislation coming up, putting us back to the crypto-as-ammunition days.

## Sometimes it wise to pay the ransom (Forbes)

A Hollywood hospital has decided to pay up a 40 bitcoin (\$17k) ransom to unlock their own files. Sounds like a good decision, and perhaps a stupidity tax, to me: after having their systems off line for a number of days, and not being able to recover from non-existent backups, the board decided to pay the ransom, and get control of their systems back. Probably the cheapest thing to do, hope they now invest in good backups.

Ransomware is probably here to stay. That is, as long as the quality stays up; a few bad apples might make ransomware into a lemon market, either by being easily crackable, or by not unlocking even when you do pay up. Crypto is still hard.

## IoT still doesn't take security seriously (Krebs on security)

A worrying piece on the state of Foscam cameras: apparently these systems have a life line to a more-or-less shady Chinese support organization, without disclosure or opt-out. As Krebs puts it, "This is Why People Fear the ‘Internet of Things."

## Amazon starts hosting games (Amazon)

Lumberyard is a games engine-and-hosting offering including CryEngine (the commercial game engine behind FarCry), Double Helix (components of a game studio), and backed by AWS. GameLift takes care of session hosting, and Twitch-integration makes this into a suspiciously full-featured, and hard to beat, game hosting offering.

It seems that Amazon is slowly but surely moving away from components (storage, computation, etc) into more vertical markets. Amazon's IoT offering is another one of these: a vertical that takes care of most of the issues in a market, while providing a convenient lock-in to the Amazon ecosystem. Be on the lookout for more of these!

## Microsoft acquires Xamarin (Microsoft)

Xamarin, the company formerly known as Mono, and known for providing a toolkit for developing native mobile applications using C#, has finally been acquired by Microsoft. After a close encounter on BUILD 2015, where Xamarin support in Visual Study (along with Cordova integration) was announced, Microsoft has finally pulled the triggered and acquired the company outright.

Some may see this as Microsoft being a good technology citizen; for me, it's another nail in Windows Phone's coffin.

Comment

### Angelo van der Sijpt

Last week, an article on CIO.com caught my attention: ARM will skip modems for now, despite being a huge force in mobile. I can only applaud them for this, as all too many companies have a hard time focusing on the things they do well--in ARMs case, creating an licensing designs for mass market, special purpose processor designs.

The problem with ARM also including modem chip designs is not that they won't be any good at it: it's directly in line with the current solutions they build (including Bluetooth designs), and will undoubtably be a huge revenue driver. In stead, there is a mismatch in business models: whereas ARM is very good a creating a small number of very high quality designs that are then licensed, diversifying into the modem market would lead them into a maze of different network technologies, regulations (more so than with Bluetooth hardware) and customers with very differing wishes, requiring close collaboration with each customer for each batch.

All in all, this decision is not about technology, but about alignment. ARM is the company that paused to wonder not whether it could, but whether it should.

Comment

# My productivity setup

All productivity starts with personal productivity. And every now and then I am asked about the setup I use to keep both productive and sane. I've now gathered this on a separate page, which I intend to update every once in a while. Enjoy!

Comment

# Legislation needs to push privacy liability to the strongest party

Over the past five weeks, I've followed DelftX University's excellent Economics of Cybersecurity course, which is concluded with an essay on my opinion of a topic in this field. I've picked the incentives that relate to privacy, and how regulation is the only feasible way to bend the outcome to one in line with the common good.

Coming from a technical background, my main experience in security has been around security measures (known as “controls” in this course). I have noticed that technical measures rarely tell the whole story: there is no black and white in this matter, and decision makers don't have a use for “this is just safer”-type arguments. This applies not in the least to privacy-related concerns: while it intuitively it seems obvious that privacy should be a concern, it can be complicated to construct it into a business decision. The technology field has some uncommon incentives, most having to do with restricted friction that technology brings, that make it impossible for a market-driven situation to shake out such that the privacy concerns of the public are served best. I therefore believe that regulation is needed that pushes the liability to the party best suited to control privacy.

As a software professional, I am well aware of the non-intuitive relations within the world of technology. The lack of natural friction on transactions opens the door for extremes in either direction of market share: either a huge number of small players in a race to the bottom (e.g., the current state of health- and fitness-related products and software), which later progresses into a practical monopoly for the player who understands this game the best. In both situations, either pre- or post-monopoly, market parties tend to make the choices that make best sense for their business goals. The winner-takes-all dynamics of this market means that the effects are amplified once one party reaches a practical monopoly situation. From my personal experience, I’ve seen that the direct business-incentives for user privacy are never those of the commons. This is exacerbated by (a) either unknowing or intentional company policy to make use of the wealth of information that many market parties are currently laying their hands on, and (b) the fact that most consumers currently willingly divulge information for marginal benefits, putting no pressure on market parties to change this situation.

The current situation—-customers don’t care, market parties are driven by business incentives—-is an unstable balance, waiting to break. On the one hand we see data abuses, breaches and security flaws running wild in various industries, such as insurance (Anthem), automotive (BMW) and appliances (Netatmo) which don’t get the backlash one might rationally expect. On the other, we see an unwitting movement towards trust no one (TNO) systems, such as Whatsapp’s inclusion of TextSecure’s end to end encryption, producing marginal security awareness in the public.

Some time in the near future, I expect these two trends to meet, likely in a large-scale breach whose effects will reverberate in the minds of the public. This can undermine public trust in all market parties that process private information, not just the bad apples of the industry, potentially halting technological progress as the public cannot distinguish good actors from bad ones, and turn their backs on both. The situation outlined above shows that market pressures will not produce any of the desired effects. Privacy, in this sense, becomes a communal asset, which needs (minimal) legislation to shepherd it. In situations of security, mainly banking, it has been shown that pushing liability to the party best suited to affect it, provides the proper results. The European Union’s General Data Protection Regulation (GDPR), which is expected to be adopted by most EU member states in 2015, and will become enforceable starting 2017, provides just this framework for putting liability with the correct party.

Comment

# Conversing Worlds column on Talent (Dutch)

For the February 2014 edition of Luminis' Conversing Worlds magazine, I wrote a column on Talent.

Toen ik bij Luminis aan boord kwam, was één van de eerste dingen die mij geleerd werd dat “Luminis talent niet dun uitsmeert.” Dit in tegenstelling tot klassieke consultancy, waarin ernstig groene medewerkers onder leiding van een overwerkte senior uren verbranden. Dat model werkt vooralsnog prima, dus waarom moeten we weer tegendraads zijn?

"Vooralsnog" is het toverwoord. Het klassieke model is commodity, en lijdt onder dalende tarieven, outsourcing, en erger nog, het helpt onze klanten niet meer. Als het er écht toe doet, kiezen gerenommeerde partijen niet voor de vertrouwde supplier, maar voor een klein clubje uit het Oosten des Lands. Dat is het resultaat van reputatie, track record, en ja, talent. En daarom zijn we tegendraads.

Talent? Ik geloof niet in rock stars of ninjas: het ergste wat je kan overkomen is alles wat je doet je zonder moeite lukt, terwijl je omgeving je vertelt hoe goed je bent.

"The first rule of Imposter Syndrome Club is that you aren’t good enough to be in it," las ik recent. Je kent het wel: je vindt dat je goed bezig bent, maar er knaagt een gevoel dat zegt "straks val je door de mand." Dát is het soort onrust dat ik in gedachten heb. Talent moet rijpen en groeien, en dat kan zeer doen. Je leert het meest van ervaringen waarin dingen niet gaan zoals je wil, waarin je onvrede voelt over je eigen handelen: je vraagt je af waarom je op een plateau zit, waarom het andere makkelijker af lijkt te gaan. Je kunt het groeiproces niet versnellen, maar je kunt het sturen.

Af en toe spring ik met een parachute uit een vliegtuig, en binnenkort doe ik mee met een obstakelrace met veel waterhindernissen, terwijl ik een hekel heb aan water. Ik doe die dingen niet omdat ik alles durf. Ik doe juist omdat ze eng zijn. De comfort zone heet zo om een goede reden: je bent er op je plek. Maar met die knagende onrust, is ook je comfort zone niet zo comfortabel. Daar kun je gebruik van maken: deel die onrust, ga op zoek naar uitdagingen, en neem daar ook collegae en anderen in mee. Het kan eng zijn om je skills te etaleren, maar het ergste dat je kan overkomen, is dat je iets nieuws leert.

Genoeg over jou, wat betekent dit voor je organisatie? Malcolm Gladwell--ook bekend van de 10.000 uur oefening om expert te worden--spreekt wel over The Talent Myth. Hij stelt dat talent bestaat, maar dat dit slechts een kleine factor voor succes is. Organisaties die talent aantrekken omdat het talent is, komen op termijn bedrogen uit. Werkelijk succes, zegt Gladwell, zit 'm in het vermogen om talent te laten groeien. Het tweede wat ik geleerd heb in mijn Luminis-tijd is dat alles kan, maar je alles zelf moet doen. Dat geldt ook voor de ontwikkeling van je eigen talent. We zijn geen GE, waar voor talent een uitgestippeld pad met afgemeten uitdagingen klaarligt. In plaats daarvan zijn we een organisatie waarin iedereen zijn eigen uitdaging kan zoeken.

Talent trekt talent aan. Maar iedereen die wel eens met Clickets (plastic knikkertjes met een magneetje daarin) gespeeld heeft, weet dat zelfs magnetisme tegenhouden kan worden als de Clicket stil ligt. Op de vloerbedekking heeft-ie gewoon een zetje nodig. Wij zullen zelf moeten zorgen voor die beweging. Luminis Arnhem heeft dan ook voor 2015 als overkoepelend thema in het businessplan "naar buiten!"

In welke fase van je carrière je je ook bevindt, de ontwikkeling van jouw en andermans talent is jouw taak. Wees niet bang, durf te delen, en maak er wat moois van!

Comment

# Seven years of Luminis (Dutch)

In the October 2014 edition of Luminis' Conversing Worlds magazine, the 12,5 year anniversary edition, I wrote up my thoughts on my personal history.

Meer dan de helft van Luminis' bestaan heb ik meegemaakt: in 2007 binnengekomen bij wat toen nog Luminis iQ Products heette, en na wat omzwervingen nu als fellow aan de slag binnen Luminis Arnhem. Ik voel me daar het technisch geweten naast onze directeur, Jeroen. Het maakt mijn rol alleen maar uitdagender dat Jeroen ook een technische achtergrond heeft.

Als ik in de afgelopen jaren iets geleerd heb over Luminis, dan is het "alles kan, maar je moet het zelf doen." Er is een minimum aan structuur, maar zodra het gaat over je eigen ontwikkeling, die van je kern, en hoe je de meeste waarde kunt creeëren voor ons en onze klanten, ben je op jezelf aangewezen. Je krijgt die vrijheid, maar ook die verantwoordelijkheid. Niet iedereen kan daarmee omgaan.

Wat deze organisatie uniek maakt is de mix van focus: zowel het écht begrijpen van de wereld van de klant, als het serieus nemen van software engineering als totaaldiscipline.

In zeven jaar Luminis heb ik meegewerkt aan het binnenhalen en zien verdwijnen van grote opdrachten, heb code geschreven waarop ik trots ben en code waarvoor ik me schaam, heb prachtige en volkomen foute designs gemaakt, en heb op het laatste moment demo's gered en verpest. Wat mij het meest bijblijft is het gevoel van een bruisend team dat samen gaat voor het resultaat waar de klant écht wat aan heeft. Dáár krijg ik energie van!

Al twaalf-en-een-half jaar is Luminis in beweging. Voor mij is dat nu een verschuiving naar naar de "toegevoegde waarde." Software maken is geen "kunstje;" als dat het wel is, kan iemand anders dat zeker goedkoper dan jij. De reden dat je als developer in dit rijke deel van de wereld mag werken, is omdat je de klik kunt maken: gebruik die rechter hersenhelft!

Comment

# Mandatory Viewing 2014w34: "The SOLID Design Principles Deconstructed"

In this December 2013 session at YOW in Melbourne, Kevlin Henny provides his claim that the SOLID principles are an open-ended set of guidelines, which aren’t as black-and-white as they seem. This talk works best when you have some experience applying (and maybe even explaining) the SOLID principles as they appear in code.

The best thing about this talk is how it shows that “it depends” is a real answer. It always depends, and there are no absolute truths; not in software engineering, not in life.

Are we all lost, then? Not really. Kevlin shows that there is value in the SOLID principles when used as a tool for learning, not as gospel.

Comment

# Mandatory Viewing 2014w27: "Find the Right Abstraction Level for Your Tests"

This week's Mandatory Viewing is by Gerard Meszaros (the guy behind XUnit Test Patterns).

Gerard talks us through a topic most of us have run in to: you start out with a nice set of readable tests, and while your understanding of the system grows, you end up with lots of cruft in your test code. Your tests no longer describe what the system is doing, but how you need to use the components of your system to make something happen. Good as documentation, bad as specification.

Comment

# Mandatory Viewing 2014w26: "Play by Play: Jim Weirich"

This weeks Mandatory Viewing is Jim Weirich's Play by Play. Pluralsight has put up this talk shortly after Jim passed away, as a tribute.

In this almost 90-minute session, you can watch Jim take a problem, and iterate through a vast number of API designs, trying to get a feel for how his designs influence the user's happiness. Even if you don't know Ruby, you can follow the process of someone who thinks in code, and isn't afraid to say "let's try this, and see what it does."

The process of "trying out" what an API will look like before using it resonates well with me. I prefer to make my tests read as close as possible to the thinking process of an API user. Try to put yourself in the user's IDE, and try to feel what he's feeling while using your API; empathy with your user reduces the number of WTFs per minute drastically.

Notable quotes,

• "The maturity of frameworks can be shown in how good their error messages are."
• "We've prove the basic technology works. We can write a proxy. Now is the task of finding the right API that works well... if it's too complex to use, people won't like it."
• "We explored a couple paths that proved unfruitful. I think that's good in that you explore these things and you find that's not really what I wanted."
Comment

# Software architecture as a wicked problem

While writing my master's thesis, quite a few years ago, I wrote a trio of supporting papers to help me structure my thoughts. I recently came across them, and was surprised by how relevant they still are, even given what I've learned about software architecture in the past years. You might like them!

• Software architecture as a wicked problem deals with what makes software architecture hard, and how this overlaps with planning problems.
• An engineer is not a carpenter shows how software engineering is not a real engineering discipline. It contrasts software with other 'materials' we work with.
• Architecting adaptive software is basically a readable shape of my master' thesis. It deals with what adaptivity is, how you can't design it into systems, and what factors you can use to make a system exhibit adaptive behavior.
Comment