Constrained Innovation

Abstract

My claim is that when you constrain people it fosters creativity. Let us dive into some exciting examples.

Danish Dogme

Lars von Trier made a complete fool of himself by throwing the dogme manifesto at participants of the Cannes festival in 1995. The idea was to constrain moviemaking with a set rules (Dogme 95). The hope was to catch a glimpse of reality. This set of rules started the Dogme film trend. Together with his three "disciples" the dogme-brothers made the movies: Idioterne, Mifunes sidste sang, Festen and The King Is Alive. This trend made movie-makers around the world rethink movie-making and at a point, it was almost considered inappropriate to not make handheld movies. I am a big von Trier fan so I could babble on about his greatness for a while but I will spare you :-)

Kashmir's constraints experiences

I'm also a big Kashmir and Kasper Eistrup fan. Kashmir's latest album E.A.R was created with a set of rules around the magic number 12. The rules were:

A. Record the album within 12 months
B. 12 tracks
C. 12 Instruments (max)
D. Release-date: 2012-12-12

At first you would assume that these constraints would make the creative process of writing music stop. It actually had the exact opposite effect! The rules resulted in the band having a lot of extra tracks (rule B violated). Reviewers loved the album which was released 2013-18-03 (rule D violated). Actually, I reckon, that the band only fulfilled two of the rules at the end, namely rule B and C. A danish blogger describes this process beautifully - Ørevoks

Gaming

Another example of how constraining people makes them more creative, is team building games like mashmellow-towerbuilding (The mashmellow challenge). My experience is, that these constraints make people extra creative and, if lucky, there is chance that this bubbling creativity lead to ideas. Ideas which in the end, if even more lucky, lead to innovation and when the probability approaches the improbable it might also lead to business value.

One of the talks, I still remember, from the GOTO Copenhagen 2012 conference was the Playmaking - Transforming Work Through Play talk by Portia Tung. The talk was designed with a bunch of games and she concluded that gaming is necessary for human beings. I could not agree more. When my life becomes dull, it is typically because the "play vs. no-play" ratio of daily activities is to low.

Boiling ideas

In conclusion

All the above exemplifies the general thesis, that when you constrain people it fosters creativity. The illustration above is my (best effort :-) attempt to illustrate what happens, when you place two professors in a large tea pot and start boiling the water. Hopefully they come up with an idea that prevents slow and painful death.

At this year's GOTO conference in Aarhus, I am looking forward to The beauty of Constraints, Faruk Altes talk. My hope is that Faruk will enlighten me further on this subject or even better he will surprise by talking about something (completely) different.

Agil...hvad er det lige det er chef?

Indledning

Lad os nu være lidt realistiske og indse, at der ikke findes nogen opskrift på god softwareudvikling. Ethvert forsøg på at beskrive hvordan den rigtige måde at udvikle software på vil altid kun være god i under bestemte forhold. Hvis man forsøger at beskrive hvordan processen skal håndtere alle mulige projektsetups, så går processen hen og bliver for tung. Derudover vil dem der skal fortolke processen have problemer med at finde ud af hvordan de skal gøre i en given situation. Her fejlede CMM big time og SCRUM er lige ved at fejle lige så fælt

I stedet skulle vi måske forsøge at fokusere på nogle ting der er gode at gøre.

Tidlig brugerinvolvering

Det ved jeg ikke noget om, men mange siger at det er en god idé og jeg arbejder lige nu på et projekt hvor jeg oplever dets fordele og ulemper. Ja, det er jo egentlig lidt en løgn men jeg ved at jeg taler på kundens vegne når han også opfatter sig som bruger af produktet.

Parprogrammering

Det er efterhånden et accepteret faktum at parprogrammering giver bedre kodekvalitet. Derfor gør parprogrammering det næsten unødvendigt at gennemføre efterfølgende peer-reviews af koden.

Cross-functional teams

Jo flere forskellige interessenter der er tilknyttet samme team eller endnu bedre sidder i samme rum jo større sikkerhed er der for at de oplever en success. Successen kunne f.eks. være at projektlederen blev glad, product owneren blev glad, salgsafdelingen blev stolt over det deres firma producerede og sidst men vist nok desværre ikke mindst kunden blev glad. Glemte jeg brugeren?

Pragmatisk Test-drevet udvikling

Jeg har det med testdrevet udvikling som jeg har det med sikkerhedsseler og cykelhjelme. Det eneste problem med TDD i forhold hertil er at TDD også kræver at man gør noget og bruger nogle værdifulde tastetryk. Lad mig sige det på en anden måde når jeg er ude på dybt vand og ikke føler, at det også gælder om at være en rigtig mand, så glæder jeg over den lille smule disciplin jeg trods alt til tider har. Det gør jeg fordi TDD sikrer mig en forudsigelig vej igennem dagen som kodeko / programmør / Senior Systems Engineer / Lead Developer / menneske. (så fik I også mit nogenlunde ærlige syn på titler)

Retrospektiv processforbedring

Retrospektives er gyldne muligheder for at et team eller en organisation kan få luftet ud og forbedre sig. Jeg har selv faciliteret en del retrospektiver og jeg synes tit de giver en del. De minder lidt om CMM's milestone reviews bortset fra at man typisk havde halvårlige milestones når man var lidt fremsynet :-)

Change by evolution not revolution

Problemet med Scrum tilgangen til agil udvikling er at den er revolutionær. Enhver ændring af en organisation er nødt til at ske evolutionært fremfor revolutionært. I Scrum bruger man meget ordet *skal* og beskriver nogle roller som har meget specifikke ansvarsområder og som har et meget fast defineret interface imellem hinanden. Det minder mig om en af de jobtitler jeg har grinet længe over (og som jeg senere faktisk også stødte på i SCBCD certificeringen) "Deployment Manager". Man kunne også kalde ham mr. Hudson eller mr. Jenkins for at være lidt med på beatet og samtidig en smule Oracle ditchene.

Bedste tips 2011 (top 3)

De tre bedste tips jeg har fået i år 2011:

1. Man kan afmelde telefonreklamer! På borger.dk kan man udfylde en formular og så stopper de fleste faktisk med at ringe
2. Strammer dine Nike Lunar Eclipse også lige omkring der hvor man binder sløjfen? Så stå så knæet hænger udover din fod når du binder skoene. Det fordeler trykket bedre. (Tak til @mwldk - Martin Westergaard Lassen)
3. I en presset situation så brug aldrig argumentet: "Jamen, jeg stemte på hende med de bedste bryster"

Æblemand

Det var nok fordi hun slog for mange mennesker ihjel

Min søns Lego(R) Batman spil frøs fast hertil morgen. Som softwareudvikler hørte jeg med glæde på mine børns forklaringer på problemet. Min ene datter mente, at det kunne skyldes at vi havde spillet for meget. Det afviste jeg (nok pædagogisk ukorrekt) som usandt. Herefter foreslog hun noget med, at det var da de begyndte at lade den. Det afviste jeg også som en smule usikkert (selvom det nok egentlig var forklaringen). Min ældste datter blandede sig i debatten ved at fastslå at den efter 500 opladninger ikke ville virke mere. Det reagerede jeg på ved at se en smule opgivende ud. Jeg tilføjede, at det var en af de karakteristika et Lithium-ion batteri har og at det nok ikke var forkert at batteriet efter ca. 500 opladninger ville begynde at virke dårligere. Herefter gik jeg hen i køkkenet for at lave mad til ungerne og bagved det genstartede Batman spil, der heldigvis (tak Lego(R)) har autosave, sagde min søn:

"Det var nok fordi hun slå for mange mennesker ihjel"

Hun var i det her tilfælde min datter, som havde hjulpet ham med at få nogle flere mænd (dvs. Lego(R) figurer). Det var jeg nødt til at give ham ret i :-)

Julestress

Google Dart interview

UPDATE: This blog post has moved to http://gototoday.dk/2011/09/29/google-dart-interview-help-us-with-questions/


On the 10th of October Lars Bak and Gilad Bracha will reveal the new and exciting Dart programming language for the web. This will be revealed in the opening keynote at the GOTO Aarhus 2011 International Developer Conference. After this interview I might get a chance at interviewing them about this subject and publish it on the GOTO Today Blog. Here is my draft brutto list of questions to ask - please help me add other exciting questions.

How will you sweet-talk other browser vendors?

Have other browser vendors already accepted to implement a Dart VM in their browsers?


Tool support
When will Brightly (the IDE for Dart and other web development) be released?


Language paradigm
Structural programming language - Why did you choose this programming paradigm? Why not the functional programming paradigm with its side-effect free programming? Or what about actor based programming like Scala, Erlang (Erjang) both paradigms are inherently designed for concurrency?


Language details
Where can I learn about the language details?
When you designed the language syntax and semantics, were you at any point disagreeing on what a particularly language construct should mean and/or expressed?

The language is optionally typed. This seems to be the type system of choice for new programming languages. But what about performance? Isn't easier to create a high performance VM with a statically typed language?


VM details
What about garbage collection - algorithm, memory management (heap, generations,???)


Marketing
Why keep it a secret for so long? To create a hype about it? Or to gain a technical lead? Or ...?


Unrelated to Dart
What is your biggest aversion, if any, in modern software development?
What do you typically do when you're stuck with a computer science problem?
"Do no evil" is, I believe, the motto of Google. Is it possible for a large company, like google, to fulfill this motto.