Autonomie, vlastnictví, agilita

Chcete aby byl váš tým agilní? Je to jednoduché. Musíte mu dát autonomii, z ní může vzejít pocit vlastnictví a teprve pak se může začít objevovat agilita. Pro mě je totiž Agile v první řadě neustálý proces učení se a zlepšování. Nikdo není dokonalý, takže je potřeba se neustále ohlížet, zjišťovat co funguje a co ne a na základě toho se učit. Proto máme iterace a na konci každé z nich retrospektivu. Tento pravidelný rytmus rituálů zajišťuje, aby se na učení nezapomnělo.

Ale je nutné si uvědomit, že rituály jsou k ničemu, pokud nemá tým pocit, že může něco změnit. Pokud si nevezme problémy za své, tak můžete udělat třeba tisíc retrospektiv a bude vám to k ničemu. Pro to, aby měl tým pocit vlastnictví, musí mít nad svou prací kontrolu, musí být autonomní. Musí mít prostor a zdroje, aby mohl měnit věci které nefungují, musí vidět že opravdu může něco zlepšit.

Pokud tým nemá autonomii, tak nemá důvod se snažit. Proč taky, vždyť o všem důležitém rozhoduje někdo jiný. V podobné situaci jsme byli před rokem, dvěma. Pokoušeli jsme se o Kanban. Šoupali jsme kartičkami po tabuli a nevím co ještě, ale pořád jsme měli moc rozpracovaných věcí (Work In Progress). Kanban je při tom na sledování množství rozpracovaných věcí postaven. Pokud je jich moc, tak je to příznak problému. Tým si toho všimne, zjistí co drhne, opraví to a jede dál.

Ale v našem pojetí to vypadalo následovně: „Proč děláš na třech věcech najednou?“ „Tady čekám na předávku kvalitě a tady na operations.“ „A proč to nepopoženeš?“ „Copak jsem jejich manažer?“ Zpětně je evidentní, že problém byl v nedostatečné autonomii týmů. V každodenní práci byly moc odkázány na ostatní, nebyly samostatné a jejich členové necítili vlastnictví. Proč by měli popohánět lidi z jiného oddělení? Proč by se měli snažit o zlepšení? Vždyť je to problém někoho jiného.

Pomohlo až to, co píší v každé knížce o Agile – dali jsme operations, kvalitu a vývojáře do společného týmu a najednou to není problém někoho jiného, najednou se to dá řešit, najednou se týmy snaží zlepšovat. Navíc nám už nikdo shora nepřikazuje zlepšovat tu a tu metriku, najednou se týmy snaží zlepšovat samy. Ano, není to procházka růžovou zahradou, jde to pomalu, drhne to, ale hýbe se to.

Nicméně jak říká Henrik Kniberg, Agile is Fragile. Je velmi snadné to rozbít. Nám se to částečně povedlo u releasů. Máme složitou platformu takže i releasy jsou složité. Některé týmy si to vyřešily po svém a nasazují samostatně. Jinými slovy, cítily problém, který přesahoval jejich možnosti, tak si odtrhly část platformy pod svoji kontrolu a zbytek neřešily. V rozdělování platformy měly navíc velkou podporu vedení, takže se to některým týmům povedlo.

Problém s releasy se tím ale nevyřešil. Některé týmy to mají s odtrháváním složitější, mnoho částí navíc zůstalo v zemi nikoho. Třeba společné testovací prostředí, to nikdo nechce, ale každý ho může rozbít. Zkrátka a dobře, problém s releasy se sice výrazně zlepšil, ale pořád se nám občas na produkci dostane něco, co by se tam dostávat nemělo.

Protože se to stávalo opakovaně, tak se naše vedení rozhodlo s tím něco udělat. Sešli se páni direktoři a rozhodli, že releasovat se bude tak a tak. Na tom také není nic špatného, dělají svoji práci. Viděli problém, tak se rozhodli ho řešit. Jenom jim nedošlo, že tím berou týmům část jejich autonomie. Teď už nejsou releasy záležitostí týmů, teď už jsou záležitostí directorů. Že se nová funkcionalita dostala na produkci pozdě? Ptejte se directorů. Že nevíme co, kdy a kde testovat? Ptejte se directorů. Je hrozně snadné k takovému přístupu sklouznout. Představte si, že vám někdo začne mluvit do věci, s kterou si beztak nevíte moc rady. Je hrozně snadné rozhodit rukama a tvářit se, že to tím pádem není váš problém. Znám pár lidí, kteří dokáží těmto pocitům vzdorovat, ale například mě to fakt nejde. Pokud mám pocit, že nad něčím nemám kontrolu, tak se nedokážu přinutit to řešit.

Hrozně rád bych tady napsal co s tím, bohužel to ale nevím. Na jedné straně vidím, že pokud týmy mají opravdovou autonomii, tak to funguje mnohem lépe. Čím víc si toho můžou řešit samy, tím lépe. Na druhou stranu ale nevím, jak řešit věci, které se dotýkají víc týmů nebo celé firmy. V chytrých knihách píší, že je potřeba určit společný cíl, který si lidé vezmou za svůj. Pak už jen údajně stačí jim dát prostor a oni vás k němu dostanou. Hmm.

How to specify thread-pool for Java 8 parallel streams

Java 8 streams are cool. Parallel streams are even cooler. They allow me simply parallelize operations on large streams of data. For example, if I want to find all prime numbers smaller than one million, I can do this

 range(1, 1_000_000).parallel().filter(PrimesPrint::isPrime).collect(toList());

Just by calling the parallel() method, I will ensure that the stream library will split the stream to smaller chunks which will be processed in parallel. Great. There is only one drawback. It is not possible to specify the thread-pool to be used. All the tasks on parallel streams are executed in a common fork join pool.

And that’s problem in larger multi-threaded systems. The common pool is a single point of contention. If someone submits a long-running task to the pool, all other tasks have to wait for it to finish. In the worst case, the task may run for hours and effectively block all other threads that use parallel streams.

Luckily, there is a workaround. We can execute the calculation in a pool like this

ForkJoinPool forkJoinPool = new ForkJoinPool(2);

...

forkJoinPool.submit(() ->
    range(1, 1_000_000).parallel().filter(PrimesPrint::isPrime)
		.collect(toList())
).get();

It seems ugly, luckily with Java 8 we can create a lambda expression for the Callable, so submitting is not so painful. Using this trick, the tasks generated by the parallel stream stay in the same pool. I was afraid that this behavior may be implementation-specific, that it’s just a coincidence. Luckily, if you look at ForkJoinTask.fork() you can see that it has to work this way. Its documentation says “Arranges to asynchronously execute this task in the pool the current task is running in, if applicable, or using the ForkJoinPool.commonPool() if not inForkJoinPool().” And since parallel streams use fork-join framework, they use the fork method and thus all the tasks stay in the same pool.

So we are able to use parallel streams and choose the thread-pool at the same time. But that’s not all. The trick solves other two issues you might not be aware of.

The first one is that the submitting thread is used as a worker. In other words, if you execute calculation on a parallel stream, the thread that submitted the calculation is used for processing. So you are basically mixing threads from a pool with a thread that has completely different life-cycle. I can imagine several scenarios where it can cause problems. Some of them are described here. By explicitly using fork join pool, we make sure that the parallel stream is processed only by threads from the thread pool.

The other problem is that the parallel processing might take a long time and I would like to limit the time spent on the task. By explicitly using submit, I can specify a timeout in the get method. It comes handy in real-world systems where we just do not want to hope that everything will go according to plan.

CompletableFutures – why to use async methods?

I have been playing with Java 8 CompletableFutures and one thing has been bothering me – shall I use methods with Async suffix or the variant without it. Let’s take a look at the following example:

CompletableFuture.supplyAsync(() -> getUser(userId))
                .thenApply(CreditRatingService::getCreditRatingSystem1)
                .thenAccept(System.out::println);

private static User getUser(int id) {...}

private static CreditRating getCreditRatingSystem1(User user) {...}

Here I want to get some data about a user from a remote system, then call another system to get his credit rating and once it is finished, I want to print the result. All of the tasks may take some time, so I do not want to block the main thread, hence the use of completable futures.

If you are not yet familiar with Java 8 syntax, () -> getUser(userId) is a lambda calling getUser method. CreditRatingService::getCreditRatingSystem1 and System.out::println are method references. Underneath, the supplyAsync method creates a task which gets the user details. The task is submitted to fork-join thread pool and when it finishes, the result is passed to the next task. When the next task finishes, its result is sent further and so on. It’s quite neat and simple.

The question is, whether I should use the previous variant or this one.

CompletableFuture.supplyAsync(() -> getUser(userId))
                .thenApplyAsync(CreditRatingService::getCreditRatingSystem1)
                .thenAcceptAsync(System.out::println);

The difference is in the async suffix on the method names. The methods without async execute their task in the same thread as the previous task. So in the first example, all getUser, getCreditRating and println are executed in the same thread. It’s OK, it’s still a thread from the fork-join pool, so the main thread is not blocked.

The second variant always submits the succeeding task to the pool, so each of the tasks can be handled by different thread. The result will be the same, the first variant is a bit more effective due to less thread switching overhead. It does not make any sense to use the async variant here, so what is it good for? It was not clear to me, until extended the example to download the credit rating data from two different systems.

CompletableFuture<User> user = CompletableFuture.supplyAsync(() -> getUser(userId));

CompletableFuture<CreditRating> rating1 = 
    user.thenApplyAsync(CreditRatingService::getCreditRatingSystem1);
CompletableFuture<CreditRating> rating2 = 
    user.thenApplyAsync(CreditRatingService::getCreditRatingSystem2);

rating1
    .thenCombineAsync(rating2, CreditRating::combine)
    .thenAccept(System.out::println);

Here I have two actions waiting for user details. Once the details are available, I want to get two credit ratings from two different systems. Since I want to do it in parallel, I have to use at least one async method. Without async, the code would use only one thread so both credit rating tasks would be executed serially.

I have added combine phase that waits for both credit rating tasks to complete. It’s better to make this async too, but from different reason. Without async, the same thread as in rating1 would be used. But you do not want to block the thread while waiting for the rating2 task. You want to return it to the pool and get a thread only when it is needed.

When both tasks are ready, we can combine the result and print it in the same thread, so the last thenAccept is without async.

As we can see, both method variants are useful. Use async, when you need to execute more tasks in parallel or you do not want to block a thread while waiting for a task to finish. But since it is not easy to reason about such programs, I would recommend to use async everywhere. It might be little bit less effective, but the difference is negligible. For very small small price, it gives you the freedom to delegate your thinking to the machine. Just make everything async and let the fork-join framework care about the optimization.