Methodology

Methodology

Asynchronism in mobile

In Android, asynchronous tasks are done to avoid long operations in the main thread. Android documentation gives a good advice to the community to avoid ANR (Android Not Responding):

Therefore, any method that runs in the UI thread should do as little work as possible on that thread. In particular, activities should do as little as possible to set up in key life-cycle methods such as onCreate()and onResume(). Potentially long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a worker thread (or in the case of databases operations, via an asynchronous request). — Keeping Your App Responsive – How to Avoid ANRs

The point is that long operations like network, file system or database can freeze the UI, and that these kinds of operations must be done in a worker thread rather than in the main thread.

What is often misunderstood here is where to put asynchronism. The most current pattern is to protect the UI from long operations. Thus, long operations are wrapped with AsyncTask, Service, Thread, Executor or libraries which can be called asynchronously.

Read more

Methodology

Polar Expeditions and Agility: The 1911 Race to the South Pole and Modern Tales

www.octo.chA polar expedition and an IT project have much in common. They both share a goal, a team, and constraints. They share risk management issues, as failure is always a possibility even if the stakes are different. They also share a special relation with tooling and the influence of leadership style. But they mainly share the importance of the philosophy under which each project is undertaken.

We will see in this article how the approach taken to face a challenge can have tragic outcomes. And how the fantastic race to the South Pole in 1911, or modern polar explorers methodology, can relate to our daily IT experience.

My personal life as a software developer, a data scientist, a team leader and now an agile consultant is every day influenced by my ten years experience as a polar skier, and even more by the giants on whose shoulders I stood.

Vision, team, leadership, decision making, continuous improvement, tooling… The source of inspiration never ends. This post is an attempt to share some of it.

Slides are also available on slideshare.

Read more

Methodology

Are you self-deluding when measuring sprint velocity?

I‘ve seen the outcomes of making high velocity an objective in young agile teams you people wouldn’t believe. Attack ships on fire off the shoulder of Orion… Um.., maybe I am not going to talk about Tannhäuser Gate. But certainly, I am convinced that if one understands velocity the impact will be the improvement of the velocity. Even without c-beams glittering. Let’s slow down a bit.

As a matter of fact, focus on going fast could mislead me. So, do I want to run fast or do I want to run well?

Let me ask you a question. What are you going to do to have a high velocity? In fact, why do you track velocity?

Read more

Methodology

Joyful wind of change: A software craftsmanship short tale

This is the story of a team. A bunch of 11 aspiring software craftsmen who decided to change things around and get their job done in a better way.
The story takes place between the 30th and the 50th iteration of the development process of a software. This software is a website serving over 2 million regular users and providing legal information and services to 65 million French citizens.

Chapter one:
Start from what hurts and set a direction

Leaky pipeline

It is normal that the build fails. There are some automated E2E tests that fail randomly. Just try again, hopefully it will work next time.

This was the common answer to all new developers who struggled passing their first user story. And for information, the build then used to be about 45 minutes long. Almost nobody would get shocked anymore, as if everyone just got used to the pain. Read more

Methodology

A Journey into Industrializing the Writing and Deployment of Kibana Plugins (riding Docker)

by Alexandre Masselot (OCTO Technology Switzerland), Catherine Zwahlen (OCTO Technology Switzerland) and Jonathan Gianfreda.

The possibility of custom plugins is a strong Kibana promise. We propose an end to end tutorial to write such plugins. But this “end to end” approach also means “how to continuously deploy them?”, “how to share an environment with seeded data?” Those questions will bring us in a full fledged integration infrastructure, backed by Docker.

The Elasticsearch has grown from a Lucene evolution to a full fledged distributed document store, with powerful storage, search and aggregation capabilities. Kibana has definitely brought a strong component for interactive searching and visualization, transforming the data storage tier into an end user browser.

Customizable dashboards via a rich library of graphical components made its success, but soon, the need for real customization arose. If plugins were thought to be integrated from early on, the actual customization often lied into forking the master project and adapting to on particular purpose. Merging back fixes was soon to be a daunting effort to keep up with the high pace of the Github repository evolution .

Fortunately, as of version 4.3, the Kibana project took a more structured way to integrate custom plugins. The promise of maintainable external plugins became true. Those plugins, written in JavaScript, can be as simple as a standalone widget (e.g. a clock), a field formater (an up/down arrow instead of positive/negative number), a graphical representation of a search result (a chart) or a full blown application.

So, that should be easy. Just google and you would craft wonderful shiny visualizations.

But not fast, young Kibana Padavan! Documentation lacks, resources are valuable but scarce. But the promise is still shiny and we want to reach it.

In this post, we propose to share our journey into the writing of Kibana plugins, the little pitfalls we fell in and the setup of continuous deployment into a Docker environment. There is no dramatic discovery or stunning breakthrough today, but a tentative to write a map to make your journey easier.

Read more

Methodology

New digital challenges in life science: the Swiss Lemanic area and beyond

www.octo.ch

The life science sector faces great challenges when the time comes to meet modern digital opportunities. This sector is incredibly dynamic, both from an economic and a scientific point of view, but innovation in the lab often comes in pair with a deep evolution in the information system strategy.

In this article, we will first focus on the Swiss Lemanic area landscape and see how the main computational trends encountered there are representative of the domain at large. We will then try to extract the most prevalent technical issues, either methodological or technological.

More importantly, we will see that life science has a particular culture and faces original computational issues. But a lot of the digital aspects are strikingly similar to those of other industries, like finance, retail or social media. Therefore, a great deal is to be learned from how companies in those sectors have undertaken their own transition towards a new digital era (and vice versa). Read more

Methodology

Management 3.0: interview with Jurgen Appelo at USI 2015

Jurgen Appelo at OCTO USI Event 2015Management 3.0 is definitely a trendy topic this year and the lucky participants of the USI 2015 event could directly hear about it by its author: Jurgen Appelo.

In addition to his talk at USI, Jurgen Appelo kindly accepted to answer our questions.

OCTO: What would you highlight as new / disruptive with Management 3.0?

Jurgen Appelo: What is new is to manage the system, not the people. For example for our merit money bonus system, I don’t decide who gets how much money, I don’t see that as my job. I think the crowd knows better who has what kind of performance, so I let them make the decision together. What I do is to make sure that this process works as well as possible. That is my responsibility, introducing such an idea. This is the same for many practices traditionally used by managers with higher positions than their employees.
I don’t see it as my responsibility to use a carrot and a stick in order to get someone to perform better. My job is to set up things in such a way that people love developing their own performance.
Read more

Methodology

How to fail at code reviews – S01E01

In the previous article, we introduced a general overview of the code review practice as well as two specific formats we use in our projects.

Nevertheless, successfully introducing a new practice is not an easy task. It’s a bit like setting sail for the first time: once in the water, the first meters are always chaotic. There are lots of waves, we wonder whether it was really a great idea. Wouldn’t it be wiser to go back ashore? However, after a bit of dedication, we finally get to the quieter open sea: we just had to hold onto it.

During our code reviews, we came across several pitfalls that were detrimental and that could jeopardize code reviewing in the team.

Let’s explore, through real-life use cases*, why the first code reviews will certainly be difficult and what are the essential fundamentals to carry out successful code reviews.

Read more

Methodology

Which format for your code review?

We mainly use two code review formats in our projects: collective review which is rather formal and peer review, which is lighter. Both have advantages and drawbacks: Let’s look into these formats together and see how to implement them within a team.

But first things first: what is a code review and what benefits can we expect?

In most areas involving writing, we cannot imagine that what is written is issued without proofreading. An article will always be proofread before publication (e.g. the one you are currently reading), either to check the substance – is the subject of the article well treated? – or the form – spelling, grammar, structure and text readability. Similarly, the code review practice consists in having one’s code read again in order to track as many defects as possible, be it on the content – does this code work, and correctly implement the required feature? – or the style – clarity, readability, standards compliance, etc.

What about you: how many lines of code have you ever deployed in production without proofreading?

Read more