Frame – works?!


For last few years I’ve been listening to software architects having conversations about frameworks that should be used and where. There are always different opinions. Heated discussions. At the end, decision is made that turns out to be a pain in the developer’s back.

What is framework?

Framework is the common piece of code that provides some generic functionality, that could be reused. All the frameworks are created with the aim of solving some kind of a problem. I like to think of frameworks as tools with default solutions.

In software development the multitudes of frameworks are great. There are testing frameworks, for writing your tests. Dependency Injection frameworks for all your DI needs. Multitudes of web frameworks for every possible programming language that could serve html.

Framework creation

I was involved in building up the frameworks. They were designed for specific technology, with the purpose of solving particular problem. Once they had been created, people thought of those frames to be good at solving any problems.

Unfortunately, those frameworks were designed to deal with few issues one had. It is possible that by chance you might deal with exactly same problem and the framework would suit you.

Framework on steroids

There are frameworks that became monsters. The architects of those, started with a simple idea and developed them into mammoth projects. Those frameworks are trying to solve all your problems. All they do at the end, is creating more.

Process of selection

As I mentioned earlier, one designed a framework to deal with a specific problem, that is why most likely, it will not solve yours in exactly 100%. During my development life I have learned that there is no single Software project that looks the same as the other.

That is why you should leave some room for yourself when you select a framework. Don’t rely entirely on all the framework features. Don’t bind yourself to one framework as well. If there is a way, try to shield yourself with some kind of abstraction, which can be easily manipulated into another framework.

Avoid frameworks on steroids. If you are going to go the route of it, you’ll end up hacking around it, or putting up with it and jeopardising your design.

One tool to rule them all

I don’t like to use one tool to solve many problems. I always compare it to a use of a hammer. You can perfectly drive a nail into a piece of wood with it. I’m sure you can as well cut a wooden plank with a hammer but unfortunately the result might not be as pretty as if you used a saw.

Simplicity is a bliss

According to Dr John Medina, human brain is constantly learning, trying to see patterns, matching them and generalise. This is what we tend to do when it comes to a software design. We often see patterns in places where there aren’t any.

I was once at a brilliant presentation delivered by Dan North on architecture design. The bottom line of it was, that we should take a step back and look at what we are doing as the solution might be much simpler without any fancy framework.


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:

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, wri
    ting 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 🙂


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


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.


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

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.