Category Archives: stuff

Anything else that is not rest of it.

There is six people between you and the President of the USA, Barack Obama

Yes, according to “Six degrees of separation”, it would only take up to 6 people to let the President of the USA know about your holiday plans.

People Network

Six degrees of separation is a theory that anyone on the planet can be connected to any person by a maximum of 6 steps (6 people). Theory that I was planning to prove via Twitter. Unfortunately the Twitter API has rate limits that would make it rather hard to search through connections.

I find myself saying these days more often that the world is a small place. It didn’t shrink, communication and transport made it smaller.

Here’s a bunch of links that explain more about the theory:

Difference between Innovation and Creativity

The subjects of my recent posts are “creativity” and “innovation“. But what does do creativity and innovation actually mean?Discussing both terms with my colleagues, we couldn’t not notice that we sort of arrived at the same definitions. We did recognise that there was definitely a difference, but somehow couldn’t point out what it was. I decided to consult the Internet :)



  • A new method, idea, product (Google)
  • The central meaning of innovation thus relates to renewal or improvement, with novelty being a consequence of this improvement. (Wikipedia)
  • Something newly introduced, such as a new method or device (
  • The action or process of bringing something into existence (Google)
  • Refers to the phenomenon whereby a person creates something new (a product, a solution, a work of art etc.) that has some kind of value (Wikipedia)
  • The act of producing or causing to exist (
Reading definition of both those terms it is rather clear that the difference is very subtle. However:
  • Every Innovation is a Creation of something new. Innovation is a Creative process.
  • Not every Creation leads to Innovation. Creating new processes/devices/art doesn’t mean that something was renewed or improved.

Little creative fingers

We all have heard about creativity but did we ever take a moment to think about it for a while. What it really is or what it means? How to be better at it?


Definitions of creativity are actually rather simple. Wikipedia states that Creativity is the ability to improve, adding value. Google quotes Princeton University’s website saying that it’s “The ability to create”.

Creativity is a mental process, involving discovery of new ideas, or new view on the old ideas. The process is powered by our conscious and unconscious mind.

With today’s modern psychology and cognitive science, creativity is still rather unknown field. There are number of theories on the process, but all of them can’t explain it precisely.

Graham Wallas presented his theory about creative thinking in 1926. He is dividing creative process into following steps:

  1. Preparation – work on a problem that involves understanding it and exploring different views on it
  2. Incubation – where the problem is injected into unconscious mind
  3. Intimation – it happens when one get the feeling that idea is going to emerge soon
  4. Illumination – where the creative idea bursts into conscious mind
  5. Verification – when the idea is consciously verified, elaborated and applied

My own findings

I started with reading some book on the topic and browsing the Internet. Then I saw TED talk by creativity and innovation expert, Sir Ken Robinson. He inspired me to observe my 3 years old daughter when she was playing. They say that small persons mind is like a sponge. It soaks in all the new encounters.

Things I noticed

A lot of my daughter’s new toys emerged from an item of everyday use, used in a completely new way (laundry basket became a boat, toilet paper roll became a telescope, etc.). She has a great skill to take an item, turn it around, look at it from different angle and than decide what new toy it will be.

My daughter is very good girl and she is hardly ever destructive  (I only assume that boys are more talented in this area). She grabs things that are around her and puts them together. New creation is inspected and either accepted as new toy or discarded (sometimes put together in different way).

Kids have more simple/different way of looking at things. This is what makes them so creative. When “Little Prince” saw picture of a hat, he said it was a picture of giant snake that swallowed elephant (perhaps he was right).

Thinking about the way my daughter creates new toys I came to conclusion that creative adult thinking is very similar most of the times. We look at the things from a different angle, look at it upside down, take tools that we have never used to do different sometimes odd job (using shoe as a hammer).

Putting things together is less physical, more mental. It involves taking pieces of information, knowledge, experience, and combine them together to produce something new. A book, real life observations, notes and mind maps turned into this article.

Recall any music interview that you might hear. Musicians typically mention who is their inspiration. Normally they mention another musician/music style etc. You can recognize in their music, tunes from other musicians, same musical patterns, instruments, etc. This is being creative by combining all the bits together in a new way.

Creativity and software development

Above description of creative processes are sounding very familiar to what I’ve been doing everyday creating software. All my experience from working with other people, technical knowledge I have, domain knowledge I acquired and everything else I know influences the code that I write.

I found that knowledge of different languages and patterns that are present in those, helped me to bring new ideas, become more creative at what I was doing. C# experience helped me to introduce some new patterns to Java. Dynamic and functional languages gave different view on type safety and state. Tools that I typically used in one technology, gave new light to a better use of tools in other technology.

I also found that being brave enough to try new things, use of different tools, led me to a new discovery. For example, swapping build tool to brand new, helped defragment not fully automated release process.


Everyone can be creative however it doesn’t mean that it is simple. More information you have (including domain, technical knowledge and everyday life things) is helpful. More willing you are to try new and different things the better.

Try to stay open to information but be careful, as it is easy to get overflowed with it in the age of Internet. Be open to new things and listen to other’s ideas, don’t shut them down immediately.

Handfull of links (somehow references)



Innovation, academia VS industry

Last week I was presenting the paper me and my collogues wrote. You can find it here: Enabling Testing, Design and Refactoring Practices in Remote Locations.  The paper was accepted for ICST 2011 conference workshop, RefTest. It is a short paper about problems and some solutions for practice transfer in distributed team.  However this is not what I would like to write about.

The workshops gave me something to think about. The whole conference was targeted at bridging industry and academia together. Unfortunately at the track I attended there was only two papers and presentation from the industry (one was mine).

I was hoping to hear some new innovative ideas that I would be able to take into my everyday work. After a whole day of workshop sessions I was left with no extra ideas. Plenty of smart academic people were presenting research that I found rather useless in everyday life.

I was also little disappointed after the presentations, as none were actually summarizing the research in a way useful for the industry.

I thought of all those blog articles, posts, tutorials, video presentations, etc. from industry people with the ideas and the way of using it. Of all the technical innovations, processes, practices that got discovered in last few years.

Does it mean that academia lost their leading role in software development industry? There is very little in press about new discoveries in the field of software development.




Evernote as blog software

From Evernote:

Evernote as blog software

I was looking for a good software to use as offline writing tool for my blog. Something in the line of the great Windows Live Writer. Unfortunately some good candidates for Mac were not free.

I’m using Evernote to store notes of different kinds for my ideas and research. Idea just popped into my head that I could use one of the Evernote’s notepads to create blog entries. Each note could be a separate entry.

Evernote has editor that enables me to style it. The only thing that is missing is the “Post to blog button”. gives a possibility to post by email though. I will give it a try now.

If you see this post it means that it was a success :)

If by any chance you are a Evernote developer or could influence the features, you might consider my simple idea.

Cheers, Greg

Edited after this line.

As you can see Evernote adds additional header. Pity as it could be such a great way of hacking Evernote and together :)

Innovation at Google

Light bulbLast week at CQon London 2011, one of the day’s opening session was Patrick Copeland from Google, talking about the way they innovate. Thoughts that speaker was trying to get across:

  • Idea is only 1% of the successful innovation, 99% is constant repetition of try and fail cycle. Thomas Edison as an example of the cycle that lead to invention of a light bulb.
  • Every idea can be a winner or a loser. Twitter was never suppose to catch up and Windows CE was suppose to be the greatest mobile platform.
  • Surround yourself with innovators, not thinkers. Look for track record of innovation in portfolio/cv.  Innovators beat ideas.
  • Build fast, build the THING, and don’t worry about the RIGHT way of building it. Just get it out. Iterate fast. Dare to fail.
  • Create Pretotypes. Google’s Android application design kit contains a paper clip and a pencil. Draw your idea, application on a piece of paper. Put it into pocket and try to use it like a real thing.
  • More time you spend on the idea without releasing it, the more in love you’ll be with it. Therefore less likely to dump it.
  • Data is apolitical and factual. Use data not opinion to decide upon idea, if it’s worth doing, if the prototype/prototype/beta is getting more popular, etc.

Are you feeling like innovating something now? Go and do it :)

Scalable Lean and Agile, QCon London 2011

qcon-londonToday was the first day of QCon 2011 in London that I attended. I thought about sharing what I remembered while it is still fresh in my head (and the head is buzzing with ideas).

Craig Larman spoke at opening note and at one of the sessions. Embarrassing that it is, I never heard about Craig before, neither I read any of his books. I did enjoyed the way he presented his material.

Craig was talking about scalable, distributed agile teams. Apparently he has a lot of experience working in this kind of environment, gathered throughout many years of his professional career.

Craig described a typical situation where delivery teams are physically located in different countries, working on the same project. In his presentation he provided practical tips for dealing with issues that rise in distributed environment.

The most important points that Craig delivered in his presentations are:

  • No disperse team – all the teams are sharing same goal and work as equal partners. There should be no hierarchy in teams.
  • Practices should be shared and guarded by Committees of Practice. Committee should have a leader that gets slack time to overlook the Practice and organize teams appropriately.
  • Software design should emerge as a collaborative work during workshops. Embrace open space in the office and lots of white boards.
  • Diverge and merge – teams should come out with design on their own sites, then they should hold Video, show and tell session with all the other sites.
  • When teams come with design on a specific part of the system, team leaders should work across all teams to have a common design for the whole system.
  • A documentation workshop after iterations embraces knowledge sharing and collective code ownership.
  • Avoid PowerPoint architects. Architects that are so far away from the code that they became architecture astronauts.
  • Component guardians are team members who look after code across all the teams, making sure that high quality is kept. If only one team takes care for only one component, the crap code is going to be maintained and accepted within. Teams needs to be cross component and cross-functional.
  • When components involve public interfaces, start with weakly typed, for example do ( aMap ). Once you know more and more code is stabilized you can make those more formal and strongly typed.
  • Continues integration is a must have.
  • There is a need to see the people across all teams. It builds trust and respect. Try to use cheap technology like Skype and web cams.
  • Team members should meet, rotate and travel to other sites.
  • Keep on thinking and adapting your methodologies and processes. Never retire.

Above points are mainly from the keynote Craig was giving. The second session was more about contracts and collaboration on “offshore” delivery model.

Some more interesting points:

  • Outsourcing development you will have to deal with culture, language, knowledge, domain, skills difference issues.
  • Address skills difference via internal education. Brown bag sessions or workshops made by more experienced team members.
  • Avoid single point of contact with the team. Visit teams before project kick-off. Physical contact is very important to create relationship.
  • Ask and rephrase questions in different way (or from different viewpoint) to test the answers.
  • Encourage team members to say no when needed, remove fear.
  • Don’t patronize teams capabilities by giving simple, disconnected tasks. This will reduce morale and make people leave, as they would think their job sucks.
  • Before project kick-off organize Domain Workshop (so the team can understand the domain) and Vision Workshop (so they can understand what to deliver).
  • Specification by example.
  • Make sure team is stable as much as possible (no leavers and joiners).
  • Make it clear that at the end of every sprint you are expecting a shippable product with the number of functionality developed.

Many of the things that Craig was talking about can be found in his book “Scaling Lean and Agile development”.

Many more info and a good introduction to Lean Software Development can be found at Crag’s web site. You can also enjoy a video of him telling a bad joke :)

Cheers, Greg

Agile (not) multitasking

So I did the talk. It was scary. I was stressed all the time, until I finished. I actually enjoyed questions session. They were very good. Unfortunately, sometimes there is no simple answers.


One of the participants created a great blog post summarising the talk:

I lost a lot of good thoughts I could deliver due to stress. First time is the worst one. Should be down hill from now on :)

Not too long ago there was an article on a subject of women multitasking better than man. I was looking for some research in the scientists community, but this is the only thing I found.

Women do multitask better than man. So guys, when you are watching a TV and talking to your Wife/Girlfriend, and she complains about your ignorance, she’s got a point. It doesn’t work the other way around thought :D

As my friend Christian used to say “Less haste, more speed” and Lord Chesterfield “There is time enough for everything in the course of the day, if you do but one thing at once, but there is not time enough in the year, if you will do two things at a time.”

Don’t multitask, stay focus !

Cheerios, Greg

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