CodeAndCoffee

fredag den 10. juli 2020

Moved to Medium.com

I’ve migrated to Medium.com

Find new posts there. Search e.g. by name :-)

fredag den 6. oktober 2017

The GOTO Copenhagen 2017 was in my opinion a great conference. Below are some of my key take-aways.

Even-though Jessica Kerr and Russ Miles did a very confusing presentation on the No slides - just Code track, I would like to try out Atomist's Slack integration tools to automate the tedious tasks in my day-to-day work and to enhance team co-operation. For instance, if you create JIRAs in the team's slack channel everybody can immediately see that you created the JIRA. Jessica Kerr reminded me about the Pragmatic Programmer and automating for acceleration.

I must read "The Why Axis" book. Correlation is not the same as causation. Linda Rising again did a fantastic presentation and I got the book she offered in the end. Linda proposed us to do experiments or trials as a better word for it, since it will never be research-like experiments. Do little trials in your organisation and hope for them to fail because, at least you tried and maybe one of the trials changes your organisation a little bit - bit by bit :-)

It might not be the best solution to use Neural Networks (pseudo-science). Instead you might be better of using probabilistic programming and Bayesian Networks (science). Michael Green taught us that you have to pose a hypothesis, do an experiment and then decide whether the hypothesis holds or not. It is very dangerous to do it the other way around: fitting you model (hypothesis) to the actual data (experiment).

I must get my team to try Mob-programming (team-programming). It made so much sense when Woody Zuill explained why this is such a sane approach to software development. Isn't that immensely ineffective? You might ask. I'm not so sure. Think about how much work you have in progress at any given time. Think about how much knowledge is needed after af unit of work is done. Check this danish blog-post out or take a look at the talk in the GOTO Play App.

We need to aid the customer buying IoT equipment so he can see how secure a given product is. This is not easy since most products are secure until proven otherwise. But Leif Nixon's presentation "Internet of Targets" showed a lot of examples of bad IoT security. I especially liked (spoiler-alert) his presentation trick where he placed a scenario about a damn somewhere in the north, that if IoT enabled could flod a large beautiful country, but this damn is not "IoT enabled"....

torsdag den 24. september 2015

Multiple-choice anti patterns, learning patterns or why I love GOTO

Here are some of the known anti patterns or things to avoid when doing multiple choice questionnaires or tests:

Do not mention parts of the question in the answer.
Do not have one answer with long explaining text.
Design answer combinations to avoid lucky-as-a-monkey winners.
Do not use multiple choice tests :-)

The anti patterns above can actually be used to pass poorly designed multiple choice exams!
Unfortunately the ones in tech knows these anti patterns, so they will not do the trick here. I really hate certifications. At best they only give you level 2 (out of 5) level knowledge of a subject.

So what to do if you want to learn new stuff? It depends on your personal learning strategies. Personally I prefer:

Use it to learn it. I cannot learn to program in a new programming language by listening to a teacher or by reading a book alone. I have to get my hands dirty and try new language constructs etc.
Teach it to learn it. When you explain stuff using your own words you learn it yourself.
Study it hard to learn. I used to be good at that in university. But it seems harder with an older brain, a family and the ability to really deep dive into something is rusting.

Hmm, this was supposed to be a GOTO conference sales speech :-) I would not say, that I haven't learned anything from attending JAOO/GOTO. Here the training sessions have been the best. What I most love about GOTO, is the inspiration and the networking.

So, the main conference is good at giving you hints when choosing leading edge technologies. Hints to other ways of working. Great stories told by interesting Key Note speakers. It also is a unique opportunity to meet old and possibly future colleagues.

At this years GOTO Cph I'm actually hosting two tracks. The Testing track and the Drones and Robotics track.

But let us get back to the wrong way to do multiple choice tests. Below are some of examples of really bad multiple-choice tests. Can you identify the before-mentioned anti-patterns? Actually I think there are a lot of other bad questionnaire patterns and some of them might be hidden in the examples below (including bad english):

TDD is a known tool in software testing and development but what does it stand for?

a) Tool Driven Development

b) Test Driven Devlopment

c) Totally-awesom Driven Development

d) Debug Driven Development

What is pair programming good for?

a) Getting things done quickly

b) Ensuring team communication

c) Pair programming is actually good for a lot of stuff. If your team does not do pair programming at least 2 hours a day, you have an unhealthy team. //FAIL: long answer = right answer

Quick test: //FAIL: 1) Bi-ased questions, 2) Monkey-answer-machine will win by identifiying an obvious pattern and answer good good good OR bad bad bad

Is test driven development good or bad?

a) good

b) bad

Is pair-programming good or bad?

a) good

b) bad

Is design-patterns good or bad?

a) good

b) bad

Does the picture below illustrate

a) The meaning of life?

b) Proportions and perspectives?

C) One of the most popular art pieces in Esbjerg?

tirsdag den 7. januar 2014

At lære børn at programmere - og læring generelt

Abstract

Det er vigtigt at den danske ungdom uddannes i hvad IT handler om. Det er vigtigt for alle og jeg vil mene at Datalogi eller noget lignende burde være et fag i den danske folkeskole. Der er efterhånden flere interessante tiltag på området. Allesammen handler om at lege med børnene og om at lære de spirende programmører hvad programmering er for noget. Jeg lister her nogle initiativer, motiverer mit synspunkt og udvider horisonten med nogle overvejelser over design af en god udvikler-konference og om designet at et lærings-emne/konferencetrack/kursus.

Initiativer

Her er nogle af de initiativer jeg kender til:

Devoxx4KidsDK Minecraft Modding underviser i at lave MODS til Minecraft. Et MOD er en modification til et spil således at spillet opfører sig anderledes. Det kunne f.eks. være at gøre alle zombier i stand til at springe i luften. Dette initiativ er startet som et samarbejde imellem Devoxx og Javagruppen.

Kodepiraterne underviser i mange forskellige ting (KODU Game Lab, Raspberry Pi, Kinect til pc, Scratch og LEGO Mindstorms). Aalborg universitet (Sydhavnen, København) har startet dette initiativ hvis mål er "at skabe et bæredygtigt ugentligt fritidstilbud fra januar for børn og en forælder".

GOTO Junior Kan jeg nok næsten ikke stoppe med at snakke om :-) Jeg har fra mange venner og kollegaer, som vel og mærke ikke er ansat i Trifork kun hørt godt om dette initiativ. Der undervises i Visuel programmering (Scratch) og i 3D programmering (Unity).

Motivation

Jeg synes virkelig der er plads til forbedring i Danmark mht. børns læring og IT. Måske står det slet ikke så slemt til og ovenstående og forhåbentlig mange andre initiativer er med til at flytte os i den rigtige retning.

Hvorfor?

Datalogi er et vigtigt fag af mange grunde. Stort set alle danskere kan ikke undgå at få berøring med IT i deres hverdag. Derudover er datalogi og programmering - især visuel programmering - et godt værktøj for børnene til at forstå verden, modellere verden, udtrykke deres ideer.

Læring er jo i det hele taget vildt interessant

For mange år tilbage fik jeg æren af at skrive artiklen til noget IDA halløjsa ny-uddannet civil-ingeniør. Overskriften var "at lære er at leve". Det mener jeg stadigvæk. Jeg er involveret i at arrangere en udvikler-konference i København i juni måned. Den bliver interessant af flere årsager. For det første fordi det er et forsøg på at reboote GOTO i Danmark. For det andet, fordi jeg vil gøre alt for, at den centrerer som omkring læring.

Jeg har stærke aversioner mod mindmaps, men det skyldes mest, at jeg så dem første gang for mange år siden præsenteret af en overordnet i mit første job som flaskedreng. Den overordnede havde fået karakteren 6 og ville gerne lige høre mig hvad jeg gjorde, for at gøre det bedre til eksamen. Det jeg bed mest mærke var det patetiske mindmap, som ikke hjalp ham særlig meget. I virkeligheden er mindmaps ret gode til personligt at skabe et overblik over en brainstorm eller et tema. Så her er mit foreløbige mindmap. Det skal siges, at jeg ikke har clearet med chefen at lægge dette på nettet, så sig det ikke til nogen :-)

Mindmap - læring og GOTO conference design

lørdag den 23. november 2013

Søvnløse tanker

Det er sgu ikke nemt altid. Man vil gerne alt, men når kun så lidt. Man håber på det bedste, men frygter det værste. <lorteindledning>

I dag var jeg til gymnastikopvisning. Min datter Freja var på eliteholdet. Jeg blev helt orange af stolthed (ja, jeg kender ikke farven, men det er i hvert fald ikke grøn som i grøn af misundelse). Hun lavede et meget flot split.

Imorgen skal vi holde børnefødselsdag. Det er nok derfor jeg ikke kan sove. Øv.

Jeg kom til at sige "Giv den gas!" til en meget travl (storløbende) far i regntøj, som jeg både mødte på vej ind og ud af centeret i dag.

Årets julegymnastikopvisning er ret underholdende på mange måder. Det er jo hele hr og fru Tranbjerg, der er samlet på godt og givtigt ("godt og ondt" udtrykket stemmer ikke overens med den forfærdeligt vigtige management trend for tiden - vist kaldet: "positiv psykologi" ... Jeg ved ikke om det er samme trend der har fundet på at man skal spørge stressede medarbejdere om følgende: "Har du nok at lave?"..."klap i grøntsag!" Er det eneste svar jeg lige kan komme på! ... teksten: "Nu er den her parentes vist ved at tage overhånd!"... .)

Nå så da dada.

Der er alt for mange udtryk, som er svære at tegne. Jeg nævner i flæng:

*Ben i næsen (Ser to sko hænge ud af næsebor)

*Kamme over (Ser en kam...?)

*Fik ben at gå på (Ser et juletræ med ben at gå på)

*Hvile på Laurbærene (bladene?) (Ser Master Wu hvile på en fin sammenfejet svævende bunke laurblade)

*En skygge af sig selv (rekursivitet?)

*lige til øllet (Øl-krus med afpustet skum?)

lørdag den 19. oktober 2013

Ode to Dave Thomas

Most people will not find this post interesting. In fact, I think about one person, in the whole wide world, will do so. And possibly he won't find the time to actually read it.

I attended speakers dinner at this years GOTO; conference in Aarhus. I did not speak at the conference nor was I part of the crew or an official track host. So you could argue that I shouldn't have.

Anyway I did (thanks to Liv Beswick Skov). After a nice meal, the rest of the party was held in a kitchen / cantina. It was a very relaxed atmosphere and everyone seemed to talk to anyone.

At one point I observed that Dave Thomas started talking to a bunch of crew members. I liked the idea, that this Guru kind-of-guy talked to these young people. The party went on and I found a 23 year old (Rum) too good to mix with cola.

Dave is right in the middle of the picture. Crew folks typically in green.

About half an hour (seemed like hours) later, I realised, that it was as if 5 people had been frozen in the same position. Dave Thomas and the same bunch of young computer science students, that is. This stamina from an, how should I put it, grand old man proves to me, that he is more than just big words on a stage. He wants to influence young people and maybe even: he wants to make the world a better place.

Dave Thomas in the same position. At least one crew person repeated compared to picture above :-)

mandag den 30. september 2013

The Smallest Distributed System

I attended the "The Smallest Distributed System" talk by Mathias Meyer at this years GOTO Aarhus, and I quite liked it. The speaker got his message through to the audience and he touched upon a lot of the important points to remember when doing a distributed system. The points were nicely exemplified, by presenting his experiences with the Travis-CI system and the problem this system faced growing from 700 builds per day in 2010 up to currently 70000 builds per day. The main lessons that he advocated for were the following:

Visibility

You need to be able to monitor your system and at real-time be able to tell what is broken. When you get this visibility, it will lead to the need of responsibility because you need to react to the problems you see in production. The visibility obtained in the Travis-CI system led to a bunch of restructuring and refactoring of the system. Time-outs against external APIs (e.g. github api) were changed from 10 minutes to 20 seconds, and a retry mechanisme was introduced enabling the system to fail fast and also to ignore when non-important requests failed.

Uncertainty ... Modularity

You need to deal with the uncertainty associated with running a distributed system in production. There will always be something failing or performing badly somewhere in a complex distributed system. To be able to deal with this, the codebase need to be well-structured with simple and small dependencies between the different modules in the system. In the Travis-CI codebase, they had (and probably still have :-) a big ball of mud, where everything heavily depend on the travis-core module. So in short to deal with complexity and uncertainty you need modularity.

Simplicity

One of the problems in the Travis-CI architecture was the logging module and the need for ordering logs to be able to display and persist them in the correct order. The first implementation had to synchronise log events to ensure the ordering. Changing the solution slightly by having each log entry know its order, within the full list of events in the a build job, simplified this radically. Having the log entries know their order, made it possible to scale-out the logging functionality. So simplicity made it easier to scale. Simplicity also made it easier to reason about what for instance went wrong when having a breakdown i production.

Mathias concluded by mentioning that in the Travis-CI system, they still have a problem with scalability because of the relational Postgres database being a bottle-neck.

Q&A

The most interesting part of the session actually was the Q&A part. Here is my take on the questions and answers:

Q) What book can you recommend on this topic?

A) None that I know of. I read papers instead. You can find reading lists on various blog posts. Leslie Lamport (http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html) has a written numerous papers on the topic which can be found on the Microsoft Research web page. Steve Vinoski (the Track Host) recommended the work published by the Distributed Systems Research Group at MIT and also Michael Nygaards Release IT book was mentioned.

Q) Are you using circuit breakers?

A) No but we are considering it and will probably implement it in the future. Matthias explained the concept, you can read about in Michael Nygaards work. In short it is a pattern that when implemented open and closes the connection to a service based upon a heuristic about how many erroneous responses the service has returned.

Q) Have do you share a temporal clock between the modules in the distributed system?

A) We don't. We have isolated the responsibility of incrementing counters for ordering log events within one module.

Q) (my question so the app actually works :-): Wouldn't it be obvious to use a NoSql database [like for instance Riak] (added by trackhost Steve Vinoski) for persisting the log-events?

A) I'm actually quite fond of Postgres, but yes - it could be a good idea to add a NoSQL database like for
instance Riak. Because of the isolation of different services in the current architecture it would be quite easy for us to exchange the current database with a NoSQL variant. But introducing a distributed NoSQL database also introduce an extra distributed system and thereby it also extra complexity a sources for failure.

Q) What is the Gatekeeper doing? (see slides for more details on the architecture)

A) The Gatekeeper transforms a commit into an executable build job

Q) How do you collect metrics?

A) We use Librata metrics with a custom collector. We need to improve it. We have assigned a unique UUID to each build job request and thereby making it possible to track its log entries through the system.

Q) Does all of Travis-CI only run on AWS?

A) No it actually also runs on EC2 and Heroku and we also have dedicated hardware for the system. L

onsdag den 4. september 2013

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.

lørdag den 10. marts 2012

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:

Man kan afmelde telefonreklamer! På borger.dk kan man udfylde en formular og så stopper de fleste faktisk med at ringe
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)
I en presset situation så brug aldrig argumentet: "Jamen, jeg stemte på hende med de bedste bryster"

søndag den 12. februar 2012

Æblemand

fredag den 23. december 2011

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 :-)

søndag den 18. december 2011

Julestress

fredag den 23. september 2011

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.

søndag den 14. august 2011

Working Title: Organisational/Social antipatterns

Introduction

M. Sc. Software engineering - Aalborg University

PhD-wannabe

Employment: 7 years at SSE, 2,5 years piloting software @Trifork

Disclaimer:

1) This is NOT science. It is based on my 10 years of experience as a developer in the Danish IT business.

2) I'm no better. I've done most of the things mentioned here.

Purpose:

Present some ways (not?) to do software engineering and/or to behave in mutipeer-social relationships.

Real purpose:

To get revenge ;-) of all the times I've been hurt, ridiculed or even worse struck on my alpha-male wannabe ego :-)

Agenda

Introduction
Some Org. Anti-patterns
Side-tracks: Programming paradigms vs. human stereotypes (WIP)
Conclusion

Conflict creator aka. Firestarter

Illustration: 1) Overskyet …. lyn …. frisk blå himmel. 2) To elefanter der slås.

Idea: Let the others take the fight, then you can concentrate on the job at hand. OR Clearing the thick air of despair by a nice fight.

(Examples: Predator vs. Alian Predator. long bath...)

References: Alpha male theory? Organisational Elephants crossing [snapler]

----

OLD NEWS!!!: Work harder not smarter

******************************************

Illustration: ?

Idea: Deadline ahead - plan not ok - lets put more people into the project. Or even worse: lets put 1 person from another country, another part of the organization, and with a different language one (mythical) man month before deadline.

Examples: Red weeks in a wellknown big company....

Reference: Mythical Man Month. Cope, study: perfect work week 16 hours

----

More hats, more productivity

*******************************

Illustration: En jonglør der er ved at tabe den 6. bold

Idea: Get more productivity out of smart people by giving them multiple roles.

Examples: A promising young employee is making good progress on a team. Overtime lets make him: Teacher, Part Development knowledge leadership, test manager and lead developer.

References: Men multitasking. Context-switching. Pleasing everybody is pleasing nobody.

----

Everlasting impression

*************************

Idea: Make a negative or positive everlasting impression. Then you will never be forgotten in an organization. Backfire: - Nagging and ridiculed because of funny stories.

Examples: The Fight of the Red Screwdriver. Get really drunk after 14 days on your first ever IT-job, at the company summer party. (Simon Spies)

Relatives: Bad publicity is better than no publicity.

Conclusion: Antipattern? I don't think so, but it is a dangerous strategy that can backfire. OOOPs wait a minute - that is the definition of an antipattern.

----

More deadlines, more productivity:

*************************************

Illustration: Agurk der skærres i tynde skiver.

Idea: Short iterations, short-terms goals, more productivity

Problem: Stress. Employers never able to have a day of non-productivity at work will get stressed out. First experiences with Scrum The big welknown company: Employer citation: "You have to get used being in hurry all the time"

A.k.a: Agility gone bad?

----

Punish Manager

******************

Origination: Team christmas party. Drunk Simon: "When someone makes serious bad things with the codebase they should be physically punished."

Illustration: Video youtube - HMM.

Idea: Have a crumpy old man which knows the product very well punish fresh green developers each time they make the tiniest small mistake.

Problem: Green developers escape the project and/or company and all their nice new University knowledge is not exploited.

Examples: "You just use SVN-update? Man, you must be crazy you will get your sandbox polluted with all the green developers bad code - Use SVN-synchronize",

----

Scapegoat:

*************

Illustration: Nød der bliver til egetræ.

Idea: Lets as a group select one individual in the group who will be the scapegoat. Could be: The slowest coder. This way we can all feel above him and when anythings goes wrong, we can implicitly insinuate that it was his fault.

Problem: Instead of using this talent we misuse it.

Examples: Hi-knowledge consultants meets crumpy old developers.

Solution: After 35 years of living, I know that the following is not entirely true, but I used to believe the following: "Everyone has a talent. The hard part (for some people) is to figure out which talent". A person can't be all bad. If you give her a bit of confidence, she might very slowly evolve into a decent or even invaluable employee. A metaphor: Try treating other people as plants. If you give a plant (sun, varmth, water and attention) it will grow into a nice flower.

----------------------

Create an enemy:

********************

Idea: Lets make a common enemy. The one we are fighting against. This will make good team spirit.

Problem: Backfires when people interact with enemy.

Candidates: Customer. other subcontractor, other division of same organization, other team on the same project.

Examples: "The customer does not understand why the system is not performing well"

-----------------------

Career paths:

***************

Illustration 1): En gruppe kodekvæg der kigger på en mark med forskellige blomster.

Idea: Lets make some career paths to strive for. Then we can make people have titles like Senior Chief Architect or Senior Project Manager. Problem all the american companies have peoples with longer and greater titles! Solution lets upgrade all our employees with a new title. (Remember: not to mention that this upgrade has no money attached :-)

Illustration 2): En gruppe kodekvæg der kigger på en mark med kun een slags blomster.

Idea gone bad: Lets only make a project leader career path.

Problem (idea gone bad): All the bad developers become leaders. Secondary problem: All the good developers leave the company.

-----

Conclusion:

Antipatterns are as valuable as patterns. Because its stories about ideas that seemed like a good thing but could turn out very bad. Like building an eternity machine by digging a very big whole in the earth an putting a tea pot of water above it.

tirsdag den 9. august 2011

Livets mening m.m.

Da jeg var yngre brugte jeg rigtig meget energi på at finde ud af var svaret var på livets store spørgsmål: Hvad er meningen med livet? Dengang var jeg sikker på at der var et entydigt svar på dette spørgsmål for alle mennesker. Nu er jeg omkring halvvejs og livets mening er rykket lidt i baggrunden. Sagt på en anden måde: Meningen med livet er nogenlunde gået op for mig.

Status: 3 dejlige børn, 1 kone, 1 hus, 1 bil, 1 marsvin, 1 job, 1 familie.

Hvad der bekymrer mig i dag er flere ting og på flere niveauer:

I mit eget liv:

- Mit og konens helbred

- Min søns helbred

I Danmark:

- At vi fortsætter ud af en kurs med mindre demokrati, uforståelig fokus på penge og økonomisk vækst som altings mål. Penge er kun papir!

I Verden:

- Overbefolkning

- Krig

- Sult

- Miljø

Mit håb:

I mit eget liv:

- Helbredelse af min kone og min egen Colitis Ulcerosa

- Styr på min søns fremtid.

- Forening af mine skildsmisseramte forældre. Dvs. at de kan kommunikere.

I Danmark:

- At nogle visionære politikere vinder valget. Politikere der er i stand til at brug balanceret menneskelig vækst som mål.

I Verden:

Det driver jo af kliché men:

- Fred, fordragelighed, religiøs forening, færre våben, fokus på miljø, styr på befolkningsvækst, bedre fordeling af verdens resourcer.

fredag den 4. december 2009

Dan North at JAOO 2009 - Adventures of an Agile Architect

Dan North gave his talk: "Adventures of an Agile Architect". Dan is an excellent performer - and one is quite sure to be entertained by his talks. He had very few simple slides but a bunch of interesting stories.

(writers note: This post was originally intended for today.jaoo.dk but I thought I'd start by posting it here as a draft since nobody reads this blog anyway :-) Thanks to Rolf Njor Jensen for co-authoring this post!)

Have a shaman - be a shaman

Every team needs a shaman. A shaman is person who tells stories. So, when someone in the team asks "Why the hell is this code like this?". The Shaman tells the story of this partibular piece of code, its past and how it fits into the rest of the stuff.

Strip away everything you can

When you start to strip away stuff that has no real value in your codebase. You of course will get a simpler system. But another advantages is that other unnecessary stuff pops up and becomes visible.

Use transitional architectures

Developing software is performing structural changes on existing bodies of code, occasionally adding new pieces of code and chipping away old, unnecessary code. If you want a nice loosely coupled architecture with good performance but your current architecture is a big pile of crap. Then it might sometimes be necessary to take one step at a time and for instance start by removing all God classes. An architecture with no God classes then becomes a transitional architecture (or you could say a temporary solution). This architecture does not fully fulfil the goal but is one step towards the wanted solution. It is very important that everyone are aware of the fact that the transitional architecture is not the final solution.

Dan gave another example of a transitional architecture namely to get from the current build system to Ivy. Maven was used as a transitional solution. Maven is this obsessive compulsive friend. When you bring Maven on a date it brings all its friends from all over the internet. The obsessive compulsive disorder has one advantage: Since Maven is very rigid about the placement of different parts of the source less duplicated code is created (since developers discover that the needed code has already been developed before introducing a duplicate solution). After Maven had done its tricks the team was ready to move to Ivy. As Dan put it “When bringing Ivy on a date, Ivy asks if he can bring one of his friend who will clean up the house during the dinner”.

Avoid Standup Stasis

Dan gave a nice demo of how daily standups should not be performed. It is hard to replicate in words so I will try with a strip instead:

The team that Dan started working on as an consultant had stopped doing daily scrums. Dan asked how they used to do it and the team did as the above strip tries to explain – i.e. everybody on the team just reported. No one listened and no one commented on others statuses – Scrum Stasis. The team refused to start doing scrums again so Dan did a clever trick. The next day he said “Well I've just had this fantastic idea: why don't we meet each morning and have a chat about the rest of the day answering the question - how we can have the best today?”. The team thought this was a brilliant idea and this way Dan North reintroduced daily scrums (without using the term).

Finally, here is a list of points and citations that did fit into this post:

There is always a reason
Ensure deterministic deployment
You shouldn't "buy" architecture
Nice architects listen, and are not-very-self-important.
“Take a pile of crap A, take another (larger) pile of crap B, and make them into a nice lightweight group of services.”

torsdag den 5. november 2009

Hvidt i hvidt

Jeg er træt af ikke at kunne have mine trælofter i fred. Hvorfor skal alt tapes til med intetsigende gipsplader. Hvidt i hvidt se det er flot! Naej, hvor er det intetsigende flot, og se alt det lys det giver. Hvad var der galt med et hjem med lidt farver og lidt karakter? Hvorfor skal alt være så pænt? Det gælder sgu også alle de kedelige nybygger kvarterer, hvor det hele skal være åh så pænt og åh så intetsigende. Når kvinderne har fået deres vilje over hele landets indvendige og udvendige indretning, så skal jeg love Jer for, at så flygter alle mændene og det duer jo ikke så...

Tag os sammen!

Det må være slut! Du danske mand, tag dig sammen! Sig nej til din kone! Bestem selv over hjemmet så det ikke ender med hvidt i hvidt.