DEV Community: Lauri Hiltunen

Estimates and Anchoring When Playing Planning Poker

Lauri Hiltunen — Sun, 10 Feb 2019 15:29:25 +0000

Rudimentary Introduction to Planning Poker

The term of planning poker is used to describe the method which utilises a group of developers to estimate the relative size of a development task, or multiple of. When a team is playing planning poker, people go through the tasks one by one, estimating the task as they go. You can read more about the method in Wikipedia, for instance.

One benefit of planning poker is including the opinion of each developer when the estimates are done. Generally the more experienced developers, who might know the system inside and out, may lean on the smaller side of the estimate spectrum. This is quite natural, as it is how that person sees the task. What he might fail to note is that not every developer in the team shares the same experience, expertise or insight on how the app works currently.

Before Moving on...

Before we move on to the cool stuff, try answering these two questions. I promise it'll make sense in just a minute.

The Cool Stuff

Now, where the game gets interesting is the psychology behind it. The Wikipedia description includes this, sometimes overlooked rule of planning poker: "all participants show their [estimate] card at the same time". For a successful round of planning poker, I consider this quite essential part of the game. Why, you might ask...

It all boils down to something called the anchoring effect. In a nutshell, anchoring means using some initial piece of information as a base on which we build our own opinion of the matter. Daniel Kahneman's Thinking Fast and Slow elaborates this by using an example:

The guests at San Fransisco Exploratium were subjected to an experiment to see how the anchoring affects people's estimates. People were split into two groups, each of which two questions were asked as follows:

Group 1
Is the height of the tallest redwood tree more or less than 365 meters?
What is your best guess about the height of the tallest redwood tree?

Group 2
Is the height of the tallest redwood tree more or less than 55 meters?
What is your best guess about the height of the tallest redwood tree?

What was noted that the first question affects how people will respond to the second question. The average estimate of height of the tallest red wood tree for the group one was ~257 meters while the group 2's average was around 85 meters. Quite a big difference just by changing one number in the first question. The anchor.

So if we skip the "everyone reveals their estimate at the same time" we establish the possibility to anchoring to happen. It means that whoever speaks their mind first might affect the estimates of people coming after them. Following estimates might not necessarily become the same, but it's easier for the person to drop their original estimate of 5-7 points to 3, for instance. And that's a big difference.

The lesson is this: if you're playing planning poker, go all in!

P.S. Oh btw, about the answer you gave earlier, did your answer reflect with the findings described above?

Managing State with Vuex - the Guide I Wish I'd Had

Lauri Hiltunen — Wed, 28 Mar 2018 16:12:10 +0000

TL;DR: see the vuex flow and/or skip to see the code.

Frontend apps have been growing more and more feature-rich in recent years. "It's for the web" is not a proper reason to deny desktop-like feature requests anymore. At the same time frontends are switching from the traditional MVC model to a more componentized structure, and the need for a solid state management pattern has emerged. After all, the components interacting with each other is a vital part of any bigger app.

Flux is a design pattern released by Facebook, created to structure client-side, component-based applications. There are many implementations of the Flux-pattern but in this post we're going to focus on one: Vuex. This is the guide I wish I'd had when I first started reading about state management with Vuex. There will be code!

Concepts

The key concepts with Vuex are: the state, actions, mutations and getters. The state object contains the application state, and is shared with all the components. Mutations change the state - and they are the only way to change it. Actions commit mutations, the key difference being that mutations can not be asynchronous. We should invoke async actions which commit mutations when the async code has completed. All state mutations must be synchronous! Finally the getters return specific parts of the state for components to use.

The flow of data inside store: components create actions which commit mutations, mutations alter the state and getters return parts of it.

You can choose not to use some of the steps described above, but for the sake of completeness I'll go through the flow as it's designed to be used.

The sample app

We're going to take a look at some code, which creates the store for one property, mutates it and returns it for components. The sample app is a concept of an activity calculator of some sorts. The basic idea is that you'll select an exercise you're working with and then add the amount of that exercise done, like stairs climbed, the distance you've ran or the pushups you've done. The app for this example consists of two components: one that selects the exercise and the other one that uses the selected exercise and allows you to mark the "reps" you've accomplished and send the data to a backend service for further processing.

Bring on the code

Let's get going with the code - I did use the vue-cli simple webpack setup to enable ES6 features. First of all, let's create the Vuex store.

The state inside store.js

The state inside the store is just another object, it can contain anything you want.

//store.js
import Vue from 'vue'
import Vuex from 'vuex'
Vue.use(Vuex)

const state = {
  selectedExercise: undefined
}
// ...

We have the state object in store.js, it contains the selectedExercise which we'll mutate in a little while.

Actions

Then we're having the action methods, they get the context as their first parameter and the possible payload as the second param. This action creates a mutation by calling context.commit with the name of the mutation and passing possible payload to go with it.

//store.js
const actions = {
  selectActiveExercise(context, exercise){
    console.log('selecting exercise action, ' + exercise.name)
    context.commit('selectExercise', exercise);
  }
}
// ...

Actions commit mutations

Mutations

And then there are the mutations. Mutations get the state as first parameter and an optional payload as second. The action from previous step committed a mutation which calls the selectExercise method which in turn changes the state for real.

//store.js
const mutations = {
  selectExercise(state, exercise){
    console.log('selecting exercise mutation, ' + exercise.name)
    state.selectedExercise = exercise
  }
}
// ...

Mutations altering the state

Getters

The last missing part - the getters exposed by the store. You can call the selectedExercise getter from any of your components and it'll return you that specific portion of the state.

//store.js
const getters = {
  selectedExercise(state){
    console.log('getting selected exercise')
    return state.selectedExercise
  }
}
// ...

Getter returning a part of the state

Exporting the Vuex store

Build up the store and export it so we can use it.

//store.js
export default new Vuex.Store({
  state,
  actions,
  mutations,
  getters
})

Import the store and use it in your app

Initialising the app with the store.

// your app.js/main.js, some code omitted
import store from './store/store.js'

new Vue({
  el: '#app',
  store: store,
  router: router,
  template: '<App/>',
  components: { App }
})

We're importing the store from newly-created store.js and assigning it as a store to our app.

Using the store inside components

Running actions and mutating the state

Now that we've set up the store, we can use it in our components. First of all the exercise-selector component, which triggers the action that selects the active exercise for our context by running the select exercise action which in turn runs the mutation that commits the change to state.

import { mapActions } from 'vuex'
export default {
  name: "exercise-selector",
  methods: {
    ...mapActions( {
      selectActiveExercise: 'selectActiveExercise'
    } )
  }
// code omitted...    
}

Exercise selector vue component, it maps the selectActiveExercise action for use in our Vue component

<template>
    <li class="exercise-row" @click="selectActiveExercise" role="button">
      <div class="name">{{ exercise.name }}</div>
      <div class="pointsPerUnit">
        <span>{{ exercise.pointsPerUnit }} points per {{ exercise.unit }}</span>
      </div>
    </li>
</template>

Using the mapped "selectActiveExercise" method inside the template

Getters

After taking care of mutating the state, we're mapping the getters defined in the store to our other component. This effectively creates a computed getter method with the name "selectedExercise" for our component.

import { mapGetters } from 'vuex'
export default {
  name: "exercise-input",
  computed: {
  ...mapGetters([
    'selectedExercise'
   ])
  },
//...    
}

Mapping the getter "selectedExercise" from vuex store for use as computed properties

When the getter is in our component's context, we can use it in our template as follows.

<div v-if="selectedExercise">
  <h2>Add exercise</h2>
  <div class="input-container">
    <div class="input-selected-name">{{ selectedExercise.name }}</div>
    <in-put class="input-number" v-on:keyup.enter="addExercise" type="number" placeholder="0" v-model="units"></in-put>
    <div class="input-unit">{{ selectedExercise.unit }}</div>
    <div class="input-details">Points {{ selectedExercise.pointsPerUnit}} per {{ selectedExercise.unit }}</div>
    <button @click="addExercise">Add to your exercises record<span class="forward"></span></button>
  </div>
</div>

Mapping the getter "selectedExercise" from vuex store for use as a computed property

So we are using the mapped getter method inside our template. This effectively gets the data from store and is updated automatically when any component commits the mutation that changes the selected exercise.

And that's it, Vuex with a couple of lines of code.

Afterword

I got into Vuex a couple of weeks ago during a get-together with my colleagues. At first all the talk about actions and mutations seemed a bit confusing and complicated, but to see it in a few lines of code makes it quite clear and understandable. And in the end using centralized state does make application development easier as the size of the application gets bigger. When the state changes are reactively rendered in every component, you can focus on the key features which alter the state instead of doing something like emitting events or updating your views manually.

I like it, it beats all the manual scripting and event-based solutions I've seen before. By a mile!

What Is Null? (Baby Don't Hurt Me)

Lauri Hiltunen — Wed, 22 Nov 2017 17:31:08 +0000

There are two kinds of programmers out there. Those that have had null-related errors in their programs and those that are just starting their careers. The dreaded null, nil, undefined… Most programming languages have a concept for “nothing”. But what is nothing? Have you ever thought about null, what is it really? And what is it not? Let’s see what null means in Java.

To get things started, null in Java is not an instance of any type. Java’s type comparison operator, instanceof, is defined as follows:

At run time, the result of the instanceof operator is true if the value of the RelationalExpression is not null and the reference could be cast to the ReferenceType without raising a ClassCastException. Otherwise the result is false.

So by definition null is not an instance of anything.

However, the Java Language Specification, or JLS, defines a special null type. The null type has no name, and as such you can’t declare a variable of the null type. You can’t cast anything to the null type either. The only possible value ever to exist (or not?) for null type is the null reference itself. For every other reference type, you can always assign the value as null. As JLS states:

The programmer can ignore the null type and just pretend that null is merely a special literal that can be of any reference type.

In Java, null equals null. Meaning “null == null”. Also, by contract, the equals method from java.lang.Object states that for any non-null reference “ref” of type TYPE, ref.equals(null) should return false. So while null equals null, it is not equal to anything else.

How do you use null then? Propably the most common use-case is to denote the fact that the reference requested does not exist or is unavailable. For instance, Java’s System.console() method returns null, if no console is available.

Null is also the default value for all reference variables. This means that for every reference variable, if you won’t assign a value, it’ll be null. This fact can be used, among other things, to implement lazy initialization of your fields, where you populate the possibly expensive fields only when you need them for the first time. In cases like these null is used to represent an uninitialized state.

In addition to referring to non-existing object or uninitialized state, general use-cases for null include signifying termination condition (see BufferedReader.readLine();) and having an unknown value (like mapping null to certain key in a Map).

Sir Tony Hoare has famously stated that inventing null has been his billion dollar mistake. There are ways to work around the concept of nullability, for instance using Null object pattern. Whatever you decide to do, be mindful of your code when it's even remotely possible that a reference could be null. Otherwise your app might just

Exception in thread "main" java.lang.NullPointerException
    at to.dev.WhatIsNull.main(WhatIsNull.java:42)

Programming by Coincidence (Don't Do It)

Lauri Hiltunen — Wed, 18 Oct 2017 17:41:00 +0000

The book Pragmatic Programmer introduces the concept of programming by coincidence. In a nutshell it means writing code without really understanding what you're doing, how your snippet of code or app works. While everything seems to be working just fine on the outside, it might break later on for reasons unknown to you. I will break down the issue on this post, please correct me if there are obvious (or not so obvious) errors in the text.

Accidents Waiting to Happen

The concept itself has been broken down to following "accidents".

Accident of Implementation

Accident of Implementation might happen because of the way code's written. Maybe you're relying on some undocumented feature/bug of the library you're using, or some side effect that just happens when you're making your method calls in a certain order, without properly initializing your parameters etc. etc. In the end your relying on undocumented features or boundary conditions which just work with your code, but are breaking up often/easily when something else changes.

Accident of Context

Accident of context means that you create your code for a specific scenario but there are aspects you're not thinking of. You might be programming your modules assuming there's a GUI present, while that might not always be the case. Context accidents happen when you're relying on something that's not guaranteed to be there. I would also want to include copy-pasting code as a flavor of Accident of Context; if you're copying something (do consider DRY - don't repeat yoursef - as well), you need to be aware of both contexts, what do they have in common, how are they different.

Assumption Is the Mother of All F-Ups

Basically both of these accidents have their roots in assuming things. You assume that the code needs to be written in a way it is, you assume the API does what you think it does intentionally, even if it seems odd. You assume that your clients are literate and smart, that you know the context and environment in which the software will run. You assume your assumptions are correct :)

How to Avoid Programming by Coincidence

If there's a name for the problem and people have written about it, then there's bound to be a simple cure for it as well. Right? No. There are no easy step-by-step guides on how get rid of the issue once and for all. It takes conscious effort and focus to avoid this pitfall.

First and foremost, always be aware of what you're doing. Don't go on autopilot and make the easy assumptions. Look into things and how they work, test and document your assumptions for reference. Testing your assumptions and finding them wrong on the spot... That's a bullet dodged right there.

You should not program "blindfolded". Try to understand the basic concepts and what your (and all the related) code's about. Also, working with legacy software it's easy to take a look at the similar implementation for reference, or even copy-pasting it to get a head start. But try asking yourself a question: is there a reason why it was made like it was? Could you possibly improve the code base? The ones who come after you might want to thank you if you do!

Why am I writing this? As a reminder really, as I've recently bumped heads with hard to find bugs because of this very matter. Errors that could've been easily prevented if people would have paid attention to what they were doing. Everyone slips up sometimes, it's natural. Just try to be aware of what you're doing to minimize problems caused by programming by coincidence.

If you made it to the bottom, congratulations to you! If there's one thing to take in from the post, it's this:

Don’t Program by Coincidence