Month: August 2013

Tests – Silver Bullets?

A colleague wrote:

I have a client who needs to convince their old-school management that unit testing has value. I know. I know.

and he got some good material to work off. I myself recalled a very interesting session on CITCON in Budapest where a person playing the role as CTO asked us all to convince him that they needed pre-production tests (such as unit tests). Their (the company’s) experience was that they were doing absolutely fine without it, since they had close collaboration with the customer throughout the development process and lots of eye balls looking at hourly reports on how their web site(s) performed in terms of business.

In the rare cases where a bug went through and caused “damage”, the sales and support people had turned the unfortunate events (such as selling some Gucci or Versace type of bags for 1£ each, instead of 1000£ because of an unexpected comma (thousands delimiter) in the in-data file) to something positive and a marketing “event” kind of thing. These kinds of things, bugs/errors, didn’t happen very often at all and their customer base were actually mostly positive about when it did happen as they saw a company that in very short time responded to customer feedback, were open and honest about what they did to correct the situation etc. They had lots of in-production metrics/monitoring in place and people that closely monitored their systems. From a tech point of view, they seemed to have 0 issues. Business was happy with time-to-market etc.

The session was titled Do_we_need_tests_on_planet_retail? but no-one seems to have taken notes (or at least post them). Essentially, in this case we concluded that the only valid reasons to spend time writing pre-production tests were:

a) if the developers wanted to, then they should,
b) if the organization wanted to attract developers that wanted to write pre-production tests, then this could be encouraged by the organization as means of helping the recruitment of such individuals
c) if they started to get quality problems that they couldn’t sort out with whatever other means of quality improving measures they’d try (more code reviews, code analytics tools, …), then this is one route/option they could try out to see if it would help them fix that problem (but as of that day, they didn’t really have a quality problem)

We tried to pursue the argument that “tests/regression test suites” documents expected behavior of the system and helps people new to the code base not break features. Being strict with pair programming and not touching new areas without pairing with an “old timer” would ideally solve that too (and they didn’t have problems retaining their personnel). Risk obviously is a factor, “X people gets hit by a bus”-scenarios and such.

Teams of about 20 people in total doing development and ops. More people on community facing activities and sales. I understood they bought assets from companies that had gone bankrupt, and sold the stuff on-line. They’d been doing that for several years and were very profitable. Most of the work seemed to setup web sites and/or campaigns targeting certain audiences (high profile/expensive jewelery, football fans, 2013 Olympics Gadgets, …) and get statistics out of that to see how profitable the bought set of assets turned out to be. As such they monitored, from a businesses point of view, the system closely to see how the market responded to various on- and off-line activites and events.

I wouldn’t personally want to have my evenings with the kids depend on on that (systems with zero pre-production tests) but if/when what what you’re doing is mostly routine (similar things had been done many times) the value of writing the same tests over decreases as they become assertions of not typing the wrong thing. Good pair programming should save you from most of that.

TDD:ing in order to design the code, perhaps differently from previous iterations, is another subject. But in short – since the business was happy with what they were getting, and the developers lead happy lives too, it was hard to find reasons for them to have to change.

Försvinner utvecklingssamtalet i en agil organisation?

Läser med ett öga (barnpassning med det andra ögat) Peter Antmans “Riv pyramiderna igen”:

de agila värderingarna (teamet är ansvarigt, betoning av inre motivation, återkopplingar hela tiden, systemtänkande, vid behov) skar sig mot de värderingar som ligger bakom individuella utvecklingssamtal (bedömning, extern motivation, individinriktat, sällan förekommande, förutbestämt).

Spontant håller jag inte med. Möjligen (eller troligen) har vi olika bild av hur utvecklingssamtal genomförs och varför. Min erfarenhet säger mig att utbildningssamtal ger möjlighet till inspect & adapt.

Negativt?

“Bedömning”, ja mot egna uppsatta och antagna mål borde ju vara ett minimum. Vilken transparens har vi annars att jobba utifrån? Att få en extern vy på sina förehavanden och mål är sällan skadligt utan positivt – på samma sätt som att lära någon befäster sina egna kunskaper, att kunna visa och motivera sin bedömning för någon annan kan hjälpa till med att vässa sina argument och ställa djupare krav på eftertanke.

“Extern motivation”, detta ämne förstår jag inte.

“Individinriktat”, går visserligen bokstavligt stick i stäv med “teamet är ansvarigt” men inte bildligt. Det går inte att skapa grupper utan att ha individer. Att stötta individer till att växa och utvecklas borde göra teamet starkare.

“sällan förekommande”, detta håller jag med om. Min erfarenhet är att det sker sällan (varje kvartal). I för långa och för korta cykler är det svårt att se orsak och verkan.

“förutbestämt”, förstår inte riktigt vad Peter menar med detta. Förutbestämda datum behöver inte vara något negativt – i Scrum-ramverket ger det möjlighet till just att se orsak och verkan genom regelbunden inspektion. Ett metodiskt angrepp att försöka öka kontroll/riktning i en komplex miljö/omgivning/verklighet (och på så sätt reducera risken att komma ut i fel ände). Förutbestämd agenda kan vara jättebra för att komma igång, de flesta retrospectives jag deltagit i tror jag haft nytta av detta. Givetvis behöver man variera sig, men att ha något att börja titta på kan hjälpa till. Det kan också baseline:a och begränsa resultatet genom att det avgränsar tankerymden.

Positiva agila värden

“Teamet är ansvarigt” – vilket innebär personligt ansvar för den egna insatsen (inför teamet och sig själv).

“betoning av inre motivation” – kan man kanske se hänga ihop med Software Craftsmanship (för de som känner att det är vad de gör). En bra mentor/coach/chef bör kunna hjälpa till att hitta och formulera, och kanske även “maximera”, de aktiveter och den omgivning som stöttar en individs motivation. Att varje team skall bestå av personer vars innersta inre motivation kommer till fullt utlopp genom arbetsplatsens åtaganden känns eutopiskt.

“återkopplingar hela tiden” – instämmer att det traditionella utvecklingssamtalet är långt från tillräckligt här (samtidigt som viss ledtid måste finnas i “långa” processer)

“systemtänkande” – här tänker jag att utvecklingssamtalet inte bidrar till “systemtänkandet”, men inte heller skadar. Troligen optimerar man inte endast “flaskhalsen” genom att se till varje individ i teamet, vilket då skulle medföra “waste” i att se alla som inte är flaskhalsen. Jag skulle bli förvånad om det ändå är kostsamt att genomföra bra utvecklingssamtal, regelbundet.

“vid behov” – nja: visst som värde; nej som aktivitet för styrning. Om vi har komplex miljö vill vi göra kontinuerlig inspect & adapt, inte “vid behov”. I en enkel och repetitiv aktivitet vill vi minska waste, men att kalla individers utveckling inom arbetet för potentiell waste tror jag inte är lyckat. Det är antagligen inte heller vad Peter menar, så jag missförstår säkert hur utvecklingssamtalet “vid behov”.

Coach, mentor eller chef?

Givetvis får man kanske fundera över grundinställningen till utvecklingssamtalet. Om det är ett halvårsvis avstämningsmöte, eller förtäckt lönesamtal så är det väl tveksamma incitament för transparens etc.

Kanske Peter förtydligar sina tankar senare i boken.