Jan Grape

Jan Grape

on software development

Every bug means two problems

Finding a bug in your application actually means you have at least two kinds of problems: symptoms and process issues. To deal with quality in a sustainable way, you have to fix both!

read more »

Learnings from a new technology stack

After years of programming in Java with frameworks like Spring, GWT, JBoss, Hibernate, Seam and other traditional stuff, I needed a new learning curve. My colleague Mats Strandberg invited me to create a new version of his code kata/hobby project SignUp.

SignUp has been built and rebuilt several times before, but for this incarnation (number 4 of the more prominent ones) we decided to use some stuff we haven’t used so much before: Scala, Play! Framework 2.0, Anorm, Twitter Bootstrap and Secure Social. We store the source code on GitHub and deploy on Heroku. In this article I’ll summarize some of the things I learned so far. Since I’m an IntelliJ IDEA user, there is some of that too…

read more »

Properties of a good daily stand-up

I had a conversation with some of my colleagues about what makes a good daily stand-up, here are some properties:

  • Time-boxed (15 minutes)
  • Everyone is engaged
  • Synchronization is taking place
  • Attention to problems
  • People ask for help
  • The conversation is about stuff that matters to most people, individual issues are postponed
  • Anyone can lead the meeting, not just the Scrum Master / Team Coach
  • The meeting is the starting point for the day, afterwards everyone feels energized and can start working right away
  • Ends with a punch that marks the end of the meeting and the start of the day*

* The team has dumbells by the scrum board. The rule is that if you feel the current speaker is monopolizing the meeting, you can hand the speaker a dumbell. Now the speaker can keep talking only as long as they can hold up the dumbbell with an outstretched arm.

The Product Owner team

In my opinion, the Product Owner (PO) role is the most demanding one in Scrum, since the PO needs to have so many talents and you rarely find all of them in one single person.

You need to know

  • the business (what makes money for the company)
  • the end users (what makes them spend their money)
  • the stake holders (what drives them)
  • the development team (how software is made).

You also need to know how to translate all of the above into user stories. On top of that, many POs are also responsible for finding funding for their product and development team within the company.

It’s very difficult to find one single person that does all this well, so in my current team we formed a PO team instead.

Our Product Owner team consist of two people: a business analyst and a project manager. This has turned out to be a really good combination.

The business analyst specializes in turning customer and stake holder needs into requirements. In our case, requirements are expressed as user stories, usually in the popular form “As a <role> I want to <do something>, so that <explanation why>”. Writing   user stories doesn’t come naturally to everyone, it requires practice and skills, so it’s really good to have the business analyst working with the stake holders documenting requirements this way.

To be able to write consistent user stories, our business analyst, working with the stake holders,  has made a domain model explaining all the concepts used and their relations. This model is not a data model for implementation, it’s more of a dictionary defining what we mean when we discuss various aspects of the application. This has proven to be very useful.

In essence, in our PO team our business analyst is responsible for the content of the product backlog. Every time requirements are captured and put into user stories they are reviewed (or written) by him.

The project manager in the PO team also works with the stake holders, but discusses priorities, funding and external dependencies (such as roll out of new functionality in the organization). This requires a different set of skills compared to doing business analysis. This is about in which order and when things are done and delivered.

In essence, in our PO team, the project manager is responsible for the release plan in the product backlog as well as ensuring funding for the user stories. In this organization it’s the stake holders that have the budget and not the PO.

Our PO team works in pairs having two different types of backlog grooming meetings with the stake holders every week.

The first meeting is about the content of the product backlog. They go through all the user stories clarifying, adding and removing stories as new opportunities come up and other become obsolete.

The second meeting is about prioritizing the product backlog and making a release plan for the next three sprints. Market windows, campaigns and product launches are taken into account when creating an absolute priority for each user story (that will last at least until the next meeting).

As I have described in an earlier post, the product backlog is posted on a wall and stored electronically in a PowerPoint document.

Having the PO team working as a pair has proven to be very successful. Each member contributes with his skills and as we know from pair programming two heads think better than one.

Q: Who has the final word about the priorities?
A: The project manager, since he is responsible for the release plan and funding.

Q: Are the ever confilcts between the two?
A: Not more than usual when two people discuss.

Q: If the team receives a task/user story by someone outside the sprint, who do they talk to?
A: The project manager, since it’s a priority issue and it affects the current sprint and the release plan.

 

Where to store the product backlog and the release plan

In my present team we have tried many formats for the product backlog and the best one so far is – PowerPoint!

We started out with Excel. Excel documents are nice because they are easy to distribute and almost everybody has the ability to read and edit them. You can sort the backlog by rearranging lines with cut and paste, but it’s a bit complicated. If you’re not careful you may lose lines/stories. Another drawback is that the the product backlog easily becomes really large. A 200 lines Excel document is a small one, but a product backlog with 200 user stories is huge, especially considering that we do about 15 stories per sprint.

Next we tried out Trac. Trac is a ticket system much like Jira. We liked the idea of having the product backlog in the ticket system where user stories/tickets never get lost, are versioned, accessible via a web interface and can have attachments.

Unfortunately it’s a pain to prioritize in a ticket system if you want an absolute priority order and not just categories like High, Medium, Low etc. You have to add a numeric filed with a priority number and sort the list according to that. Sooner or later you will end up having to manually renumber several stories just to be able to squeeze in some new stories between existing ones.

By now you probably understand that rearranging and prioritizing the product backlog is really important in our team. Our stake holders work very close to the market changing the priorities of upcoming user stories as market windows open and close.

It was with some excitement we tried out ScrumWorks. In ScrumWorks you can rearrange the product backlog using drag and drop. There is a fat client and a web interface and it doesn’t cost any money to get started. We tried the basic and the pro versions. However, there was no success for us. Perhaps it was the need for a fat client to be installed (and in this organization people usually are not permitted to install software on their own machines) or that people needed to learn a new application (Excel and Trac were already known and in use). As it turned out nobody used the application, for whatever reason.

So far, none of the applications we tried out had a natural limit for the number of user stories you pour into the product backlog, which in all cases lead to a very large backlog. That’s a bad thing since it’s only waste to have items in the backlog that won’t be implemented for the next two years, especially in a fast moving business. Unfortunately we didn’t quite have the discipline to keep the backlog small, so we needed something that would help us in this area as well.

Finally, our business analyst Magnus Almkvist came up with the idea to use PowerPoint – one slide per user story. At first it sounded strange, but it actually works really well.

A PowerPoint slide reminds a lot of the original index card that you read an learn about on all Scrum and PO courses. Whatever you write has to fit on a limited space and it’s easy to rearrange the order in the backlog in the slide sorter view in PowerPoint using drag & drop. Color is used to mark user stories that belong to the same epic/theme and different layouts (backdrop/font color) are used to indicate the readiness of a user story (approved, implemented).

The printouts (6 slides per page) are posted on a wall in the corridor where everybody that works with our team can see them. The wall is updated at least once per week, but the original PowerPoint file is stored in Subversion on the intranet and is available for reading to anyone who want the electronic version. We also have a link from our wiki to make the backlog really easy to find.

In our backlog grooming sessions (once or twice per week) where out PO team meets with the stake holders to prioritize, add to and remove from the product backlog, the printouts are put on a big conference table (no chairs). The user stores are arranged in the order all can agree on and as things are moved around, removed or added scissors are used and new stories are written on pieces of paper. This hands-on way of working is greatly appreciated.

At the end of the session, the original PowerPoint file is updated to document what’s on the conference table.

A PowerPoint file with 200 slides is huge, so there is a natural desire to keep the number of slides/stories to reasonable number. Also, the wall where the stories are posted and the conference table used in the grooming sessions make natural boundaries for the size of the backlog.

The release planning is illustrated in the product backlog by inserting head line slides with titles like ”Sprint 23”, ”Sprint 24” etc. The slides following ”Sprint 23” contain the user stories planned for that sprint, until the next head line slide. Normally we plan three sprints ahead and after that we have a head line slide ”Bad hair day” (referring to the fact that the last part of the backlog in not groomed very well).

On our wall where we post the user stories, each forthcoming sprint is represented by a column of user stories. This makes it very easy to see when a particular user story is planned to be released.

What about attachments and additional documents?

Well, you can paste almost anything into a PowerPoint slide – and we do. Sure it turns out really tiny because we have a limited space for additional info), but in MS Office all information from the original document is preserved when you paste into another document, so usually you can see all the details by double clicking on the pasted item and zooming.

So far, this scheme with PowerPoint has worked really well for us. It’s a nice mix of working with physical items (the wall and the conference table) and being able to share with people in other locations (wiki link to Subversion) and finally we have one indisputable original with versioning thanks to the version control system.

We haven’t let go of Trac completely though. We don’t use Trac for the product backlog, but for the sprint backlog. When the sprint starts each user story in the sprint becomes a ticket in Trac. We like the traceability we get when we check in code in Subversion with reference to a Trac ticket. We can see exactly what code changes each user story caused. And of course we use Track for bug reports and team wiki as well.

Why should I care about Scala and Akka?

Java is great and I have been doing it for years. Why should I care about things like Scala and Akka?

The short answer could be:

  • Scala is the future
  • Akka is the killer framework

Scala is a language that runs on top of the JVM with a better object orientation compared to Java and with functional programming as well. The OO part of the language is pretty easy to learn for a Java developer, but the functional stuff is trickier. Scala has a dedicated community and the language is predicted to become a really strong alternative to Java if Oracle continues to alienate the Java community. Since Scala interacts seamlessly with Java and Java almost seamlessly with Scala both languages can be mixed in the same application.

Akka is a library in Scala aimed at robust and scalable parallel programming. Instead of the old thread model with synchronization and shared memory you have actors (active objects) and messages. The actor model is present in core Scala, but Akka shows how it perhaps should have been done from the start. The founders of Scala and Akka have recently joined forces in a new company.

Since our computer hardware gets more and more cores (ability to do parallel processing) every year and The Cloud consist of an almost infinite number of boxes it is interesting with a programming model for parallel computing that really scales and is robust. That’s why Akka is interesting.

I for one, am looking forward to learning more about Scala and Akka and to using them in real commercial projects. What is the next thing you plan to learn?

 

Micro agile

When we develop using agile principles we have learned to "do the simplest thing that can possibly work". What happens if we apply this thought to agile methodology itself?

What is the minimum number of principles and processes that we need, to be able to benefit from agile? Finding them should help us know what to focus on when introducing and using agile methods.

In my experience the three most important components in a successful application of agile methods are:

  • Joy
  • WIP limit
  • Regular retrospectives

Joy

When striving for high productivity and a sustainable pace, I have found that joy is the key factor. It’s simply not possible to work really really hard for a long time if you don’t enjoy what you do. In addition, things that make the workplace and the work situation more productive also improve the mood of the team. It’s a positive spiral, people like the feeling of being productive and if you have fun it’s easier to become more productive.

So, sometimes when to choosing which way to go if you want to improve productivity, look at the joy factor too. Things that work in favor of a joyful workplace are for example: high spirits, control over your own work situation, recognition, trust, humbleness,…

WIP limit

Nothing in my experience can increase a team’s focus more than limiting the amount of work in progress (WIP). A natural reaction when a team feels pressed for time is to start working on more tasks. Probably it feels more productive to do something else if you for some reason are blocked, but it has the opposite effect since you start more work that you might be able to finish and thus wasting man hours.

With a WIP limit you are forced to address the issues that prevent you from finishing tasks, because you are simply not allowed to start a new task until the present one is finished if you have reached the WIP limit. This reveals obstacles faster and focuses on fixing them before moving on.

In my current team, we would never have automated so many tests unless we had reached the WIP limit and found that testing was the bottle neck that prevented us from starting new development tasks. The immediate solution was to have the entire team dig in and do testing, but soon some developers (who hated testing) decided to automate as many tests as possible to remove the bottle neck so that they could go back to coding. The testers found this to be very helpful, since they were so busy testing that they never found the time to automate the tests…

Regular retrospectives

Inspect and adapt. Without the possibility to change the work process itself, improvement isn’t possible. Since we never get things right the first time (we continuously learn things we didn’t know before) and the world keeps changing, we need to regularly evaluate our way of working. Can we change something to increase productivity, joy, focus?

Again, I have seen teams pressed for time going the wrong way, skipping retrospectives in order to save time (why put the whole team in a room discussing things when we already know what we have to do – deliver code?). But skipping retrospectives means cementing the way you work and you may never get out of the trouble you’re in.

Ivar har ju faktiskt rätt om en sak

I Computer Sweden skriver Ivar Jacobson att Det knakar rejält i Scrums fogar och trots att Ivar låter som en gammal sur gubbe som glömt att även RUP genomgått samma hypekurva som Agile/Scrum nu gör håller jag med honom om riskerna på en punkt: Det finns verkligen en tendens till "ingen arkitektur, ingen modellering, bara koda och strukturera om senare", eftersom många kopplar ihop arkitektur och modellering med BDUF och dokumentation – två fula ord nuförtiden. Hoppar man dessutom över integrations- och systemtest (vi skriver ju enhetstester) så lever man ännu farligare.

Jag tror verkligen på att jobba agilt och jag ser att vi har en mission att fylla när det gäller arkitektur, modellering och dokumentation. Vi måste visa och förklara hur man gör dessa saker på ett agilt sätt som inte är dokumentdrivet utan behovsdrivet och som
inte kräver att man gör allt i förväg utan i lagom små bitar och kan refaktorera.

Med Hans Brattberg har jag tagit fram kursen "Agile documentation …and how to avoid as much of it as possible", men vi på Crisp borde kanske ta fram kursen "Agile architecture" också? Det kanske är den svåraste biten att göra på ett agilt sätt inom systemutveckling.

När det gäller bristande modellering tycker jag att det varken är sämre eller bättre nuförtiden. Tyvärr har det alltid varit så att många utvecklare man stöter på är rätt dåliga på modellering och gärna hoppar över det steget eftersom det upplevs jobbigt. Så vi kanske skall damma av gamla klassiska kurser som OOA och OOD fast kalla det "Agile modelling" istället för att fånga den nya generationen utvecklare :-)

Lyft på rumpan!

I dessa agila tider sker allt mer utvecklingsarbete vid tangentbordet, men är det verkligen bra? Ställ er vid tavlan och rita pilar och bubblor innan ni knackar kod! Fast man kan inte göra som vi gjorde förr, BDUF är fortfarande dött.

Även om man parprogrammerar och kan diskutera fram kod och design och även om man nu för tiden inte fokuserar på att skriva dokument som ingen ändå kommer att läsa, får man inte glömma bort att göra design och arkitektur innan man sätter sig ner och implementerar. Så lyft på rumpan då och då och rita på tavlan. Hans Brattberg brukar hävda att ingen form av kommunikation är så effektiv som två personer framför en tavla.

Vid tavlan gör man både arkitektur och design. Eftersom vi jobbar agilt har vi alltså inte alla bitar på plats från start – inte ens arkitekturen – och därför behöver man komplettera (och refaktorera) även denna varje gång man lägger till nya funktioner av dignitet i systemet. En refaktorering av ett hörn i arkitekturen kan få stora konsekvenser i koden och just därför vill man stämma av den ofta. Annars riskerar man att åka på Big Bang.

Till hörnstenarna i systemkonstruktionen hör även domänmodellen. Inte heller här kan vi kosta på oss att göra den i förväg, utan den växer fram gradvis sprint för sprint. En av effekterna av att jobba agilt som jag märkt för egen del är att domänmodellen kan bli så mycket bättre, eftersom man putsar på den hela tiden och de nya objekt man lägger till är de som man precis skall till att använda i sin design och implementation.

Det här leder förstås till frekventa refaktoreringar av modellen och har man den persistent i en databas innebär det även frekventa uppdateringar av schemat. En del kanske backar inför detta, men det finns tekniker för att hantera detta som gör databasuppgraderingarna hanterbara eller rent av lätta. Kanske ännu ett ämne för ett framtida blogginlägg…

Det viktiga är att för det första ser till att ha en arkitektur och en domänmodell och för det andra inte låter någon av dem vara huggna i sten. Därför måste man se över och bättra på dem varje gång man tillför ny (vertikal) funktionalitet i systemet och detta kan man inte göra vid tangentbordet. Bästa sättet är att rita upp sin design på tavlan och se om den, arkitekturen och domänmodellen håller.

När man sedan sätter sig för att koda kanske man rent av börjar med en smärre refaktorering för att "kratta" för sin nya fuktionalitet.

Hur man får bättre kodkvalitet




De flesta och vanligaste misstagen man gör när man programmerar är konstruktionsfel, tankefel, designfel, eller vad man nu vill kalla dem. Det är mer vanligt att en programmerar skriver exakt den kod han vill skriva (men det är fel ändå), än tvärt om.

Men om vi ändå skall börja med kodkvalitet är snabba återkopplingscykler och disciplin viktigast. Därför förordar jag (i slumpmässig ordning):

  • Parprogrammering (snabba återkopplingar + en massa annat bra)

  • Kodningsregler (spelar nästa ingen roll vilka, bara det finns en uppsättning regler som alla följer)

  • CI-server (återkopplingar igen) med stop-the-mill-mentalitet (släpp allt annat och fixa felet CI-servern rapporterar)

  • Automatisk kodgranskning medan du kodar (á la IntelliJ eller med någon pluggis till Eclipse). Acceptera bara "grön" kod.

  • TDD

  • Putsa på koden. En del säger att man inte skall ändra sådant som funkar och det är ju rätt i många fall, men man kan ändå alltid rätta stavfel i kommentarer, ändra dåliga variabelnamn och metodnamn, lägga till kommentarer. Det här tar ingen tid eftersom det är något man gör när man läser/bläddrar igenom gammal/andras kod för att förstå den.

Lyfter man blicken från tangentbordet bör man rikta den mot whiteboarden. Det ritas alldeles för litet på tavlan nuförtiden tycker jag. Det är inte BDUF bara för att man ritar ett UML-diagram innan man kodar! Däremot kan man kanske tänka bättre med bubblor, pilar och pseudokod innan man uttrycker sin design i Java-syntax. Det här gör man också lämpligen i par så det är inget annat än parprogrammering, fast framför tavlan.

Man skulle kunna kräva att man har ett klassdiagram och en domänmodell för den lilla del man tänker koda idag innan man sätter sig vid tangentbordet. Att rita på papper eller tavla räcker för tankeprocessen. Något av det hela kan också bli dokumentation (nu svor jag visst i agilkyrkan), men få saker kan få mej att snabbt sätta mej in i kod som ett par rutor och pilar som beskriver den övergripande konstruktionen.

Sammanfattningsvis innan du kodar:

  • Rita på tavlan innan du kodar.

  • Skapa början till och bygg sedan gradvis vidare på en domänmodell.

  • Se till att alla kan domänmodellen.

Vilka är dina bästa tips?

Lean = Mini waterfall?

Min gode kollega Hans Brattberg ställde denna provocerande fråga:

Vad i Lean hindrar oss från att göra en kejda av
Req Spec -> Architecture -> Design -> Program -> Test -> Production

Med handovers hela vägen?
Utan kommunikation?
Utan Cross Functional?
Utan Feedback?

Kedjan "Req Spec -> Architecture -> Design -> Program -> Test -> Production" som Hasse beskriver är visserligen ett vattenfall i den bemärkelsen att man gör saker i en viss ordning. Det gör man ju alltid i en verksamhet med litet koll på läget; "bäst att tänka litet först innan jag kodar" eller "det går ju inte att driftsätta innan koden finns".

Det är alltså inte dåligt utan bra att  göra saker och ting i rätt ordning.

Det som gör en kedja till en vattenfallsprocess av det dåliga slaget är:

  • om varje steg i kedjan innebär ett (del-)projekt i sig. Man gör t.ex. design av hela systemet innan man börjar programmera.
  • om varje steg i sig innebär en överlämning. Det är inte samma människor som gör efterföljande steg och man kommunicerar t.ex. via dokument (designspecar) istället för ansikte mot ansikte.
  • om det finns få tillfällen där man kan ändra kraven, innehållet eller konstruktionen. När t.ex. designen av systemet är satt och inte får ändras eftersom tidsplanen kommer att gå åt skogen då.
  • om det finns få återkopplingstillfällen att förbättra processen. Exempelvis en projektavslutning var 18:e månad.

Så vitt jag vet motverkar lean varenda en av ovanstående punkter. I lean handlar det om kontinuerligt flöde, små köer och korta cykeltider. För att uppnå detta försöker man:

  • bara göra saker som är kopplade till den aktuella produktelementet (ett försök till översättning av "feature") man jobbar med. Allt annat (t.o.m. andra produktelement = parallellt pågående arbete) betraktas ju som waste.
  • minimera antalet överlämningar och effekten av detta. Bara för att man gör saker i en viss ordningeng behöver man ju inte ha olika stationer med olika kompetenser på varje station. Till skillnad från biltillverkning där man måste ha olika stationer pga att maskinerna man använder i många fall bara står på en fysisk plats behöver vi mjukvaruutvecklare inte lida av detta. Vi kan använda samma dator till alla steg i kedjan om vi vill. Skall man slippa överlämningar är tvärkompetenta team (en ny lyckad översättning av "cross functional teams" :-) att föredra.
  • eftersom man bara bygger ett produktelement i taget och cykeltiden för denna är kort kan man innan man startar nästa element prioritera och välja vilket man vill göra härnäst. Kanban är ju ett exempel på detta då PO får prioritera varje dag vad som skall göras.
  • I Scrum har man återkoppling (retrospective) minst en gång i månaden. I lean skall man ju ha det varje dag hela tiden, eftersom det är katastrof om man inte gör saker bättre idag än man gjorde igår (efter vad jag hört om Toyota).

Sammanfattningsvis tycker jag inte det blir vattenfall bara för att man gör saker i en viss ordning. I så fall är allt utom kaos vattenfall. Lean motverkar det som vi anser är problem med traditionella vattenfallsprocesser på ett rätt explicit sätt.

Parprogrammering – är du tveksam?

Jag var själv en motståndare till parprogrammering från början, men är numera omvänd då jag av egen erfarenhet sett effekterna av det hela.

Om målet är att knacka ner så många rader kod man kan på en dag, gör två personer på varsitt håll detta snabbare än två personer vid samma dator. Men så går det inte till när man programmerar, även om många (programmerare också) tror att det är det de gör.

Ser man över en period, kommer en programmerare att vilja bolla idéer, göra design, få den konfirmerad av andra, diskutera vad kraven egentligen betyder, så småningom skriva kod, hitta buggar, rätta buggar, rätta fler buggar, osv. Bara en del av all tid går åt till att skriva själv koden. Det mesta är ju andra saker.

När man parprogrammerar gör man allt det här på en gång vid datorn i små små bitar. Det känns som man är mindre produktiv, eftersom man sitter längre tid (eventuellt) vid tangentbordet och dessutom är två, men räknat över en period sparar man tid, eftersom man gör design och förstår saker bättre när man är två, man kodar bättre och snabbare när man är två, man gör framförallt färre buggar när man är två, man gör snabbare felsökning och rättningar när man är två.

Frågan är då; går det dubbelt så fort när man är två med allt det här? Ja, faktiskt och ibland ännu fortare. Räknar man dessutom med den tid man sparar genom att andra inte drabbas av programmerarens misstag; felrapportmöten, testare, CMar, kunder m.fl. blir tidsbesparingen ännu större.

En kollega till mej (Mats Henricson) brukar påpeka att parprogrammering sprider kunskap om den kod som skrivs och vad som är sund programmering. Vill man ha ett företag där ett lite längre sjukdomsfall gör att en del av koden blir förlamad, eller ett företag där alla sitter på sin rum ensamma och skriver likadan halv-bra kod år efter år, ja då är parprogrammering fel grej. Vill man ha ett företag där alla lär sig hela tiden, och där man undviker att koden kollapsar för att någon blir sjuk eller säger upp sig, då är det parprogrammering som gäller.

Till sist får man dessutom ut en produkt av högre kvalitet. Om kvalitet är en nyckelegenskap borde det vara lätt att sälja in parprogrammering. Det går aldrig lika bra att testa in kvalitet i programkod (i efterhand) som att skriva kod med hög kvalitet från början. Det vet ju alla, inte minst testare och kunder.

Så om utvecklarna i en organisation känner sig oproduktiva när de parprogrammerar kanske man skall fråga dem hur de mäter produktivitet och koppla till detta. Man ska dock ha i minnet att antalet kod i sig självt inte är ett mått på produktivitet. I själva verket skriver man färre rader kod när man parprogrammerar eftersom man skriver bättre kod. Så man får titta på saker som är kopplade till det funktionsinnehåll man levererar (t.ex. velocity om man kör Scrum).

Till sist, parprogrammering är en vana man tillägnar sig. Det finns många saker som gör det svårt för en del att börja. Inte minst att du måste förklara vad du håller på med för den som sitter bredvid. För en del är det pinsamt, eftersom de helt enkelt provar sig fram (vilket inte behöver vara fel i alla lägen). Dessutom får man ju omedelbar kritik av den som sitter bredvid och alla kan inte ta det sådär direkt.

Innan man blir bra på parprogrammering tar det ett tag. Man kan inte köra att par dagar och sedan säga något om effekterna. Det tar ett par veckor innan man börjar bli en van parprogrammerare, men det är ju bara en halv sprint!