In this third podcast in the Oslo Developer Conversation series, I talk with Linda Rising about fearless change. We discuss the how to inspire an organization to change and touch on how developers are, at the end of the day, just another mammal.
See the (English language) podcast at ProgramUtvikling’s site.
This is a Norwegian language copy of an article I published with Niklas Bjørnerstedt in the Norwegian computing magazine ComputerWorld
Studier som utgir seg for å være vitenskapelig utført viser seg stadig å ikke tåle nærmere granskning. Kommersielle tenkesmier tar mange snarveier i kampen om å få frem oppsiktsvekkende resultater. Forskeren Magne Jørgensen har gjennom årene bidratt til å “avsløre” flere tvilsomme studier og dermed bidratt til å heve den vitenskapelige standarden innenfor systemutvikling. Vi synes dette er en hederverdig innsats som vi har lært mye av. Vi synes dog at Magne har blitt overivrig i det siste. I både artikler og foredrag virker han å fremfekte et syn som stiller spørsmålstegn ved all erfaring som ikke er vitenskapelig bevist. Det siste eksemplet på dette synet sto å lese i CW den 24. mars. Når artikkelen bruker denne skepsisen til å koble smidig utvikling med ord som “mote” og “tro” så føler vi at forskeren er i ferd med å kaste ut barnet med badevannet.
(more…)
This blogpost is a Norwegian language tribute to one of my home city’s great poets
Med takk til Joachim Nielsen
Ta en titt inn på skjermen din æ’kke testen grønn
Det var mye værre her om da’n da var alle tester røde
Skulle vært her i forrige uke, da hadde byggserver’n stopp
Alt jeg tenker på er test og kode og bygg og mat hver bidige dag
Alt kan refaktoreres, alt kan leveres
Alt kan refaktoreres, og ingen ting blir bedre
The last couple of months have been full speed and not much time to reflect and write. The fact that we’re pair programming on the team gives me less time to think about great blog subjects.
As an architect, it’s hard to find enough time to complete a meaningful unit of work without doing the dreaded “architect-commit-and-run” move. However, I found that when I have time to program, the pair programming culture on our team works really well. Even though the whole team is very excited about pair programming, there’s usually someone who’s not paired up when I get back from a meeting or finish some paperwork. Pairing up with someone is a great way to get some meaningful work completed in the middle of a day full of interruptions.
The team I’m on now is also remarkably good with pair programming, so it’s always fun. For most of the time, pair programming has been the default, but I ended up occasionally working solo for a few days in a row every now and then. Then, I was unable to pair for a few days. I found myself more easy distracted, more nervous about the quality of my work, and at the end of the day, more exhausted. Two of my team mates reported similar experience.
I think an instrumental part of the success of pair programming on this team was both to apply a little bit of force in making sure that people switched pairs daily for a while and the fact that team allowed the more skeptical members to pair programming less. In the end, everyone prefers pairing for almost all their work. After our last retrospective, we’ve instituted a pair programming star: An area on our whiteboard where the names of the team members are listed in a circle. Every time two people pair up, we draw a line between their names. Sadly, as I’m knee deep in analyzing the next release, my name doesn’t have many lines going to it.
But I hope that will change. Pair programming should be instrumental to the daily work of any architect.
Subscribe (atom)