Handovers, hangovers

Handover like a pro

Recently I started to read a book, the one that Christian was praising so many times. I’m just through the first few chapters but already one of the sentences sounds in my head all the time. John Seddon, in “Freedom from Command and Control” writes how there was an improvement made to a process in one of the call centres. He said that “all the information was filed in the form so it was never coming back from the downstream person with the request for missing information”. This one off step was making improvement as it was never coming back.

John explained that it was possible to realise the impact once someone took a step back a took a look at the system and the flow through it as a whole.

This made me think about something that my other colleague, Pat did at work. When he was rolling off the project, he WIKIed all the information about it and left the Spike (proof of concept) code in the repository. He also made some comments in a code, whenever it was not entirely clear of its intention. It was one of the best handovers with no direct contact I was ever involved in.

I realised that the handovers should be looked at from a different perspective.

Typical approach is to … drop whatever at someone and let him finish the work. Whenever more information is necessary, it could be chased.

Instead, I should prepare handover in a way that would make it possible for a person who will pick up the work after, to have a brief look (at the code in my case), realise where the info is (wiki, tests, some comments) and move on with the flow.

Funny enough it encourages some good coding and work practices, like:

• simplicity
• clean and understandable code
• less time context switching and interruptions (own and others)
• tests that ensures functionality and quality
• lack of outdated and non-maintainable documents

Handovers are a problem and should be avoided when possible. When programming is involved, Pairing reduces the danger of the need for them. If not, all the members should concentrate on the most important thing, make sure the work keeps flowing through the system and what could I do to make it happen.

Cheers, Greg

Agile multitasking, context switching

These days, computers made multitasking a doodle. In the same minute you can read this blog post, chat with friend on IM, check your email, Facebook or Twitter account, perhaps even do some work. We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?

It’s been few weeks since I started to talk to people about context switching and multitasking. Most of them recognize it as an issue. Many agree that it is counter-productive. I decided to take closer look at the problem and do a little research. Here are the results.

Human brain

According to many Neurologists and Psychologists our brain was not designed for multitasking. In 1999, Jordan Grafman used MRI to scan people brain. He discovered that frontal cortex of brain of people engaged in multitasking was more active than any other. This part of the brain is the least known to science, it is said that this is “what makes us human”.

Psychologist René Marois discovered that there is a bottleneck in the brain, when it’s being stimulated to perform more than one task. David Mayer thinks, that rather than a bottleneck, brain has a process that helps to select and prioritise tasks and obey any instructions that are not on that list.

Russel Poldrack, a psychology professor found that “multitasking affects the way you learn”. He discovered that people who multitask while learning, use the part of the brain responsible for learning new skills (striatum). Rather, they should be using part of the brain responsible for storing and recalling information (hippocampus).

There is a dozens more of scientists that have done research in brain and psychology area that will confirm the fact, that we work better if we focus on a single item.

I like the words of American novelist Walter Kirn who summarises multitasking phenomena:

This is the great irony of multitasking–that its overall goal, getting more done in less time, turns out to be chimerical. In reality, multitasking slows our thinking. It forces us to chop competing tasks into pieces, set them in different piles, then hunt for the pile we are interested in, pick up its pieces, review the rules for putting the pieces back together, and then attempt to do so, often quite awkwardly.

Multitasking or context switching

It is easiest for me to talk about multitasking or the process of switching tasks (context) when talking about software development. During our development process quite often we are getting in the state which is defined by Mihály Csíkszentmihályi as the Flow . If we are getting interrupted or interrupting others it’s the Flow that suffer.

Receiving end of the stick

Think of the number of times that email, phone, IM chat, news ticker or anything else that interrupted your work. Very often we drop whatever we are doing and we answer an email. We are voluntarily destroying our context, switching to another one, just to get it back on track minutes later. This comes for a cost. It cost time and your focus. It is a typical distracter that actually we have control of.

We can also get interrupted by other people. Project manager, team leader etc. comes to us asking to stop working on whatever we are doing and do something else instead. Something small and quick, that is only going to take you 5 minutes. So we do that, and then we consume our mental energy on getting the entire context of interrupted task back on track.

As a developer I always work in the teams. My fellow developers always have some questions, problems that they might need a help with. I can’t tell them to buzz-off. I will be helpful and pay the cost of interruption later

The trouble maker

When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.

It is the same when we aren’t using contact in person but electronic medium, like email, telephone or IM chat.

Too many things at the time

Almost 10 years ago, Joel Spolsky wrote on his blog:

As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they’re going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done.

Getting tasks under control

When I started my short research on multitasking it became more and more obvious to me how Agile, Lean and XP methodologies are actually trying to bring the software development process to the state where individuals are focused on single task, complete it in full and move on to the next one. With no interruptions comes better quality as well. I would like to mention and shortly describe some of the techniques that could help team members to achieve the Flow and Focus and produce results.

Pair programming

You might think that having other person next to you means a constant interruptions, and impossibility finishing anything. Nothing more wrong. The positives that are coming from pair programming in the context of help with multitasking issue:

• having another person next to you and focusing on a work, limits you to NOT respond to email, chat invitations and cutting short phone conversations or generally do anything else not related to work
• engaged in a work you need to keep constant focus, follow your colleague and check (improve) the quality of result
• when you think you stuck on something, you have a mate next to you that can give you a helping hand (that limits the interruptions to others as well). Also with switching and rotating pairs you have constantly a fresh source of knowledge on the project areas you have never worked on
• it might be harder for someone to come over to you and ask about anything or ask to switch task to do something, as it is more obvious that he/she will be interrupting

There is more positives coming from pair programming but I will not write about it as it is a story for separate article.

Pomodoro technique

I was writing about the Pomodoro Technique in one of my previous posts “How can Pomodore help you shave a Yak?” Technique used will help with:

• keeping focus on a task for period of time
• adding short breaks to refresh the brain and take a step back to look at the task from a perspective
• when interrupted by other person or own thoughts, writing the interruptions on a piece of paper makes you assure that the issues won’t be forgotten and ease your thoughts of it. This in turn helps you concentrate back on a task
• if you make people aware that, while you are in pomodoro you would rather be uninterrupted, you will be more effective

For more info on Pomodoro, you can look at my previous post or visit Google

Kanban

It could potentially take few more posts to describe Kanban. As simple concept as it is, it actually creates a wide range of improvements to development process. It is a great tool to be introduced by Project Managers for use by the entire team. Few upsides:

• working on a single item makes you focusing on a single task. The single story/task/functionality flow
• creating only quality results means that the actual task is not finished until QAs and BAs are happy with the result. This means that testing needs to come early into the process, even better – during the process (read this article by Christian Blunden, it will show you how)
• testing brought earlier, means also that you can help testers creating automated tests and keep in the same context until it is finished

Finally

It is in the basis of Agile techniques that work should be divided into small deliverable chunks (stories) that can be picked up and work on. If the chunks are small and team is disciplined, everyone will work uninterrupted until quality result is delivered. Project managers can employ techniques that help team members focusing on a single task and deliver it in full. I’m sure those techniques can save us many frustrating moments

This article is only a short introduction and brief summary of my little research project. I’m also preparing the talk and presentation with much wider explanation of the concepts and techniques mentioned in here.

Greg

Some of the sources if you would like to research more:

• http://www.thenewatlantis.com/publications/the-myth-of-multitasking
• http://eebatou.wordpress.com/2007/10/24/qotd-walter-kirn-on-multitasking/
• http://www.joelonsoftware.com/articles/fog0000000022.html
• http://www.wikipedia.org

A same cup of Java …

… at IKEA.

Recently I changed the job. After three years (longest I ever worked for a single company) I left ThoughtWorks. Majority of my consultant career oscillated in .NET space. It was almost three years since last I was doing Java. New job … is Java (packed full of Java technologies).

I had to do some IKEA shopping one late afternoon after work (something for the house). As my journey turned out to be a waste of time (items out of stock) I was sitting in front of the IKEA building consuming a horrible £1.40 Hot Dog Menu 2. Watching the sun set I had a little epiphany! I started new job, I got dropped into source code and I was able to work without relearning Java, libraries and tools.

Then I realised that through three years of work at TW, C# and .NET changed it’s shape a lot. In a mean time Java did nothing,well … almost nothing. C# introduced new language syntax, features, influenced by dynamic and functional languages. Java had got annotations and generics (somehow weird generics).

Is that a bed thing? It gives stable platform, and more consistent syntax in legacy code. On the other hand it lacks cool features, and I do have to admit, I like new features. It’s like every time when Apple releases new iPhone instead of all cool new things on it all you get is better performance and stability

There is also the explosion of languages that run on JVM. I like Groovy and JRuby, I need to check out Clojure and Scala.

There was a lot of fear when Oracle purchased Sun. Next new release of Java will have closures. If it is caused by Oracle’s influence I hope for more to come.

It is about time for Java to make some tuff decisions and stop being 100% backwards compatible.

What you think? Comment me your thoughts.

Cheers, Greg

Flex your Agile backbone

Today I would like to write a few words about the recurring theme I observed at work. I call it a “Stiff AGILE backbone”.

With some  of the practices and processes, learned over time, we tend to stop thinking and ask questions if they are appropriate in the situation and if they work. Our agile backbone is kind of a stiff and we are keeping the same position all the time.

It is important to REMEMBER that we need to keep an open eye into what we are doing, what are others doing, identify things that we could do better and execute the improvement.

It doesn’t make sense to keep the same posture only because it worked few times before and it will work again. Every project is different and every project should evolve into “perfection”.

“No change is bad” Toyota President Katsuaki Watanabe

Cheers,  Greg

How can Pomodore help you shave a Yak?

Two terms in the title that needs clarification.  Pomodoro is a technique for managing a task completion, or simply time. Yak shaving is a situation that everyone finds himself every now and than when we are trying to solve a problem in a wrong way. Usually it happens when we create a chain of tasks that will lead to a solution and we keep on repeating it until we get somewhere. Eventually we could end up with a very crazy solution after a long period of time.

Yak shaving

An example of Yak shaving I found myself in not too long ago.

I found myself doing a Ruby on Rails development on a Mac box. As I used older version of MacOS I had an older version of Ruby compiler. To use latest version of Rails I had to get newer version of Ruby. To get that I needed to install that via Mac Ports or something similar. While trying to install Mac Ports I found myself missing some of the development files that stopped Mac Ports from installation. It turned out that those files where in XCode. I had to find XCode that is going to work on my machine. Turned out that older version is available on Apple Dev website, all I need is to sign-in. I had an account, but forgot the password. Then I tried to retrieve a password and that didn’t work. After some battles I finally got a XCode on my box.  It was still Mac Ports impossible to install Mac Ports thought. That took me along time. Eventually I ended up installing VM image of Ubuntu and developing on Linux VM.

I think that being developer, the Yak Shaving problem is very irritating and could lead into a lot of wasted hours. When working in a pair,  the Yak issue will not appear that often. There is always a second pair of eyes to validate the sanity of the task in progress. It doesn’t eliminate the Yak entirely as I found out with some peers

When working alone that is entirely different story. Because there is no one to run you ideas by, sometime I make a decisions that lead me into “the shaving“. I found myself wasting hours before realizing that it doesn’t make sense and taking step back.

Pomodoro, mmm, delicious

Not to long ago on a project I was working on, we used Pomodoro to keep us focus for a period of time. This simple technique combines 25 minutes of un-distractable time of work and a 5 minutes break. After 4 successful Pomodoros (25 minutes + 5 minutes break) we had a little longer break. While working in a pairs, Pomodoro was keeping us focus and safe from emails, phone calls and coffee breaks. The 5 minutes break gave us a lot of time to discuss the issues around the task/problem.

When working alone the 5 minutes break could be the excellent opportunity to talk with someone else about the problem or just take a step back and reflect on a solution. This eventually could lead into new ideas and most importantly into STOP shaving a Yak.

There is more to Pomodoro technique than just a sanity check from a yak shaving. There is a free PDF book that can be downloaded for free http://www.pomodorotechnique.com/resources/cirillo/ThePomodoroTechnique_v1-3.pdf and some other resources on the Pomodoro Technique web site.

Cheers, Gregster

Easter break

Some pictures from the Easter break in Poland

Easter in Poland

Cheers, Greg and the Family.

How to use simulators during web development

This is probably two topics that I would like to combine into one, as they are related in the context I will be writing about.

In one of the previous articles I wrote about the story wall that we evolved on our project. Christian in his article, described the way we worked not in pairs but in threesomes. Two developers and a QA. This was the way that involved iterative, small-steps, story delivery with constant showcasing to QA. QA was able to instantly check the correctness of a functionality, business logic, even a site layout and provide feedback to devs about it.

As any application (at least majority of them) our application has multiple points of integration to other systems. Database, web services, file system etc. One of the integration points was delivered some time ago and never tested, we were ready for a problems and bugs.

It would be very unwise to stop development because the part of the system needs fixing or some rework carried. We decided that we will shield our selfs with the layer of wrappers around third party systems , that we called Anti Corruption Layer.

The Layer gives as a constant API controlled by ourselves but it doesn’t mean that we can continue our way of working and constantly showcase all the acceptance criteria to our QAs and BAs.

We decided to bring on simulators on a board and hooking them into our anti corruption layer. This is how we achieved it:

Control

It would be very painful to switch simulator on or off using configuration in one of the file. Knowledge about the environment was not sufficient enough as we don’t want simulators to be on or off all the time. What we decided was to create a class called SimulatorDecider that will use two variables to determine if the Simulator should be on or off: current environment and a browser cookie.

The environment variable allowed us to switch simulators off regardless of the cookie, in any environment other than DEV or TEST.

Cookie in web browser is very simple to set and to remove. We created a little page called Cookie Monster that has a simple on/off buttons for setting and removing the Simulator cookie.
The approach gives a possibility to control and switch on/off different parts of the system by using different cookies for each parts.

Simulator

We have a bunch of wrappers around the integration points. The one that we are interested in, the one that we would like to simulate, we decorate with Configurable object and inject SimulatorDecider into it. This is how it works:

interface IFoo
{
  ReturnType DoStuff(ParameterType type);
}

public class Foo : IFoo
{
  public ReturnType DoStuff(ParameterType type)
  {
    // Doing some real stuff that is very important
  }
}

public class SimulatedFoo : IFoo
{
  public ReturnType DoStuff(ParameterType type)
  {
    // Doing some other stuff that is only SIMULATED
  }
}

public class ConfigurableFoo : IFoo
{
  private SimulatorDecider _simulatorDecider;

  public SimulatedFoo(SimulatorDecider simulatorDecider, IFoo realFoo, IFoo simulatedFoo)
  {
    _simulatorDecider = simulatorDecider;
  }
  public ReturnType DoStuff(ParameterType type)
  {
    if (_simulatorDecider.ShouldSimulate())
    {
      return _simulatedFoo.DoStuff(type);
    }
    return _realFoo.DoStuff(type);
  }
}

Because we are using dependency injection container (Yadic) we don’t need to worry about dependencies.
It is also possible to not code SimulatedFoo as separate type and just inline simulated behavior within the configurable type. We made this decision on a base of how complex the simulated behavior should be.

Hope you find this useful when you stuck on integration pice that you don’t know how to carry on
Comments are welcome as always

Greg

How to deal with nulls

This week I’ve been refactoring and improving some code in a .Net world. In last few weeks I also had some close encounters with Java as well. When looking at the code in both environments I realized that there is a lot of checking for null values on in a code. Where it is not a bad practice to check for null it actually presents another problem.

For someone like me when I was new to a code I couldn’t guess, what is the goal of that check. When you dealing with null the very important thing is to know where they came from and why it happened that null values occurred. When dealing with integration points it is even more important.

As you can guess code:

if (serverResponse == null)
{
    DoSomeStuff();
}

is not very descriptive. What actually happend when I got null, does it mean that there was a communication problem, error occurred or perhaps a null means that the operation was successful.

I think the best approach will be to avoid nulls if it is possible at all. Ways we could try to avoid it:
• use Maybe pattern
• create Empty object values
• use Null Object pattern

Maybe pattern

I’m not sure if that is it’s appropriate name but I’ve used it on few projects and it seems like people are referring to it this way.

Have a Maybe interface and return it instead of the object itself.

interface Maybe<T>
{
    bool Hasvalue;
    T Value;
}

Also have two implementation of the interface:

public class Something<T>
{
    private readonly T _value;
    public Something(T value)
    {
        _value = value;
    }

    bool HasValue { get { return true; }  }
    T Value { get { return value; } }
}

public class Nothing<T>
{
    bool HasValue { get { return false; } }
    T Value { get { throw new InvalidOperationException(); } }
}

When returning value from an object return Maybe. Collaborator that consumes value can check if it is Something or Nothing or just ask if it has value.

Empty Object value

Just like string.Empty you can implement Empty or something similar as predefined value on your type. For example:

class Hen
{
    Egg LayEgg()
    {
        // doing stuff
        return Egg.Empty;
    }
}

class Egg
{
    public static Egg Empty = new Egg(“nothing in it”);
}

You can always check before the execution if the egg is empty.

Null object pattern

Object with no default behavior. For example:

interface TV
{
void ShowMovie();
}

class LCD : TV
{
    void ShowMovie()
    {
        // showing movie
    }
}

class Plasma : TV
{
    void ShowMovie()
    {
        // showing movie
    }
}

class NullTV : TV
{
    void ShowMovie()
    {
        // do nothing
    }
}

If something is not working well and we don’t have any of the TVs available we could return NullTV and nothing will happen.
Using the patter we can validate by type if the returned TV is a valid object and act accordingly.

I’m interested what other approaches people are heaving. Also what are the approaches in dynamic languages like Python or Ruby.

Please add your comment

Greg

QCon summary (my presence on Thursday)

I got the opportunity to attend some of the sessions on Thursday QCon London 2010 conference.

Quite a large number of interesting tracks. It was really hard to choose which one to go to. I decide to throw in a mix of everything.

Kicked of with Christopher Reed, a colleague of mine, and his talk on different Cloud solutions out there, and also what are they good for. Chris was emphasizing the trend in the industry. A lot of companies deciding to go into cloud as if could could be a solution to all their IT problems. Chris was pointing out that it is important to make a proper decision what solution to go with as they are solving different problems and require different treat and behavior from the organization. It is impossible to get the most of the cloud and actually not get into more trouble if you don’t accommodate the fact that you are in different environment now. I liked how Chris was dividing cloud solutions into areas based on Processing Speed needed and Data Sensitivity where Processing Speed means how fast you wont your computation to be done and how complex they. Data Sensitivity meant the amount and data importance, for example crucial amount of financial transactions versus widely available weather information served by a web site.

Second talk I was at was from another colleague of mine that actually I never had the opportunity to hear speaking live, Rebecca Parson. Rebecca was talking about the ways that people not skilled in the domain can come out with some really great solutions. She encouraged diversity and cooperation in a teams that could lead to better solutions to any kind of problems.

After Rebecca’s session and a lunch break I went into a presentation by my former colleague, Dan North. I find Dan one of the best entertaining technical speakers there. His fascination about the ways the human brain learns makes his talks always very informative and fun.

Dan was talking about the way human brain tends to see patterns, generalize and then complexify solution as a result. Very often there is no common functionality and there is no emerging patter.
I liked one of the quotes he used in his presentation:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.”
–Jamie Zawinski, 1997

Fishbowl discussion was last session. The topic was about the Future of Software development. It appears that there is emerging trend in the industry to follow the simplicity and go back to a roots of software development. Simple design and good algorithms over frameworks and bloated architecture. This trend appears to follow hardware development and new presence of mobile devices on a market.

Overall very interesting day. Pity I couldn’t make to all the sessions as they were all interesting Hope my colleagues who were at different presentations could share their views and notes if possible.

Greg

What is your favorite development platform, survey results

Not to long ago I posted an article on my favorite environment for software development. There was also a survey in that post asking about your favorite environment. The results are below.

Clearly, Linux is a winner. Here are some comments you guys added to a survey.

Can’t believe people are still using text editors to code… Visual studio rocks!

Well, not sure about this comment

Well, Ubuntu. For the package system, for the standard package archives and for the PPAs. And for everything else about it being good enough.

Windows 7, mainly because ive been using windows for, well ever. I find it really intuitive and i just know the tools really well. Windows 7 is really nice too.

Obviously I long for the day that will never come when I can develop my .net applications in intellij, deploy to a cut down windows vm for compilation and testing against iis… Anyway dreaming aside I pick mac osx for reasons you said and also because I have one and nothing beats dev on a native machine…

Mac is quite reasonable. Windows just feels clunky.

I need to be able to navigate to files and find things quickly, let alone use apps. Windows explorer/cmd is crap. Linux and Mac OS both work quickly and the command-line is effective. Mac OS X, however, just requires less of my time to maintain it than Linux. All three work similar from within an app like Eclipse.

Could be interpreted as a fan oy phrase, but for dev there is no better option than Linux…

I prefer Max because when I develop I am not just programming. Sometimes I need to check some screencast and last time that I used Linux (last year) I was not able to check all of them. Also I need a good mail and contact manager, I tried Thunderbird and Evolution. But none of them where satisfying my need.
Also i use my computer to develop and for personal use (creating video, music viewing videos). Linux is poor on that side.

I still have to fall back to Windows when working with clients who insist on using Outlook for calendaring and those horrible built-in surveys. Some aspects of my MacBook are pleasant, but I detest the keyboard layout – no home/end/pgup/pgdown and, worst of all, no visible # key

We all got a favorite environment, but what is the actual one that you use every day at work? I’m using Visual Studio as there is no real aternative to .NET development. Fortunatelly ReSharper makes it usable

Thanks for your answers guys, Greg