The innovation paradox

bulb_onThink about your work and ask yourself this simple question: “What would I improve if their were no constraints?”. Next ask yourself the questions: “How sure am I that the constraints really exist? Did I try? Is there really no workaround?”.

“What would I improve if their were no constraints?”

The paradox

Businesses tend to steer for compliance, cost reduction and security to achieve financial stability. They also wonder why they fail to innovate. I learned that this is called the “innovation paradox” as organizations tend to pursuit two seemingly opposite goals. So if you are caught in that struggle, then I suggest that you read Jeffrey Phillips on his blog “innovate on purpose”.

Quotes

These 10 quotes may inspire you on your search for innovation:

  1. “The arrogance of success is to think that what you did yesterday will be sufficient for tomorrow.” – William Pollard
  2. “When all think alike, then no one is thinking.” – Walter Lippman
  3. “Managers maintain the present while leaders create the future.” – Orrin Woodward
  4. “The difficulty lies not so much in developing new ideas as in escaping from old ones.” – John Maynard Keynes
  5. “Dreaming is largely lost among adults drowning in self-imposed realities.” – Ryan Lilly
  6. “A key ingredient in innovation is the ability to challenge authority and break rules.” – Vivek Wadhwa
  7. “If at first the idea is not absurd, then there will be no hope for it.” – A. Einstein.
  8. “Innovators are inevitably controversial.” – Eva Le Gallienne
  9. “Creativity is thinking up new things. Innovation is doing new things.” – Theodore Levitt
  10. “No obstacle is so big that one person with determination can’t make a difference.” – Jay Samit

Parallel thinking

Even in a team of people that are creative and have the guts to innovate, there is one thing that can ruin everything: ego play. All creative ideas and innovation plans should be team owned and not be associated with a single team member. Tools like De Bono’s “Six Thinking Hats” can help you to create a parallel mind that dreams up team owned ideas during a brainstorm session.

Share

Panda 4.1 impacts organic traffic from Google

Here is a screenshot of my Google Webmaster Tools search statistics for the past 3 months (sorry for the Dutch dates and text):

panda41

It seems that LeaseWeb Labs was affected by an update of Google’s ranking algorithm named “Panda”. Every now and then Google adjusts the ranking of websites to avoid search engine spam.

Google launched Panda 4.1 on September 25, 2014 and told us it would be a “slow rollout” that would go into the following week. No one really expected the rollout to continue into this week but it has and the fluctuations and ranking changes you are seeing are likely related to that. – searchengineland.com

As you can see in the above graph we have lost 10-20% of our search traffic from Google. We believe that update 27 (version 4.1) of the Panda ranking algorithm is to blame. Although Google may be optimizing their algorithm continuously, updates with high impact do not occur often. It is believed that on Friday 8 August 2011 7% of the queries were affected by an update. Until the May update this year there was never such a big impact of any update. In September we have seen another update and although the impact is said to be smaller, it seems bigger on our site. Below an overview of this years algorithm updates (source):

Update   Name        Date         Queries affected
26       Panda 4.0   2014-05-20   8%
27       Panda 4.1   2014-09-25   4%

So it this really bad? No, not at all! Google needs to fight search engine spam and every honest site benefits from that, so this is also good for us. And we are not completely dependent on Google search traffic. It is estimated that about 40-50% of the total visitors of this site come from Google. So this small loss of organic traffic is hardly visible in our total traffic graph (from the “Count-Per-Day” WordPress plugin) as you can see below:

panda41_2

Did we learn any lesson from this? No, not really. We will just continue to make good (unique) content and trust that Google will keep rewarding us with lots of visitors.

Share

Gaming on Ubuntu with Steam for Linux

Valve-SteamBox

Is gaming this what Linux needs to win the hearts of kids now and thus of the IT managers of the future? I sure hope so.

Many people say that the Linux desktop is not getting popular because Linux can’t play popular game titles. If there is one company that is doing everything to change that, it is “Valve Software”. With their Steam platform they explicitly target Ubuntu Linux. They even released an Ubuntu based Linux distribution called “SteamOS”. They are also working with hardware vendors on SteamBox concept: a game PC with SteamOS pre-installed. With this box they hope to win the most important screen of the house: the TV.

Steam has lots of great commercial (non-free) games for Ubuntu Linux. These games all work flawless and perform just as good as the Windows versions. I will alphabetically list 10 popular titles from their library of over 700 games:

Counter-Strike: Global Offensive (FPS)

Counter-Strike: Global Offensive

Counter-Strike: Source (FPS)

Counter-Strike: Source

Dota 2 (RPG)

Dota 2

Europa Universalis IV (Strategy)

Europa Universalis IV

Football Manager 2014 (Strategy)

Football Manager 2014

Portal 2 (FPS)

Portal 2

Sid Meier’s Civilization® V (Strategy)

Sid Meier's Civilization® V

Team Fortress 2 (FPS)

Team Fortress 2

The Book of Unwritten Tales 2 (Adventure)

The Book of Unwritten Tales 2

Tropico 5 (Strategy)

Tropico 5

Play anytime and anywhere

On the Steam platform you can buy games and all bought games can be downloaded anytime and anywhere. The games are also automatically updated over the Internet. There are people that criticize this system, because the games are bound to an account and you cannot trade the games you have bought on Steam. I think this complaint is understandable, but I feel that the cloud based game storage is extremely convenient and works like a charm so I can live with that flaw.

Share

About hiring programmers and Asperger’s syndrome

Managers in software teams are often confronted with highly intelligent programmers; programmers that all suffer in some extent from Asperger’s syndrome. These people are very intelligent, question authority and do not do what is told unless they are satisfied with the reasons why. They have a low social sensibility and love endless discussions about principles. They like to stick to rules onces they are settled, can focus for hours on single pieces of code, love to be fully focused and hate it to be disturbed.

Am I generalizing? Yes, you bet I am, but I am sure: If you are a programmer you will recognize some of it.

“Managing programmers is like herding cats” – Meilir Page-Jones

I love that quote, because it holds so much value. Some say it only applies to senior programmers. But that leads to the following dilemma: hire easy-to-steer junior programmers that may have little or negative contribution to the software you are building or hire hard-to-steer seniors that can bring big value. Whether it is true or not, I think the latter is preferable.

Dealing with senior programmers is hard and I believe it is a challenge that does not have its match in other industries. One of the factors that is making matters worse is the global lack of senior programmers. These programmers can afford to behave arrogantly and non-compliant because the software business needs them so badly. They can always find another well-paying job. All they have to do is mention on their social media profile that they are “available” and it will rain job offers on them.

One of the methods I see that people use to get a grip on their developers, is to pay them above average or get them secondary benefits that are so good they cannot be matched elsewhere. But then again, you must be careful this does not lead to arrogance, lack of self-criticism and a feeling of superiority. These are definitely enemies of a good working team, so this cure may be worse than the disease.

Further reading on Asperger’s syndrome

The following links give some more insight into Asperger’s syndrome:

  1. http://archive.wired.com/wired/archive/9.12/aspergers_pr.html
  2. http://www.dailymail.co.uk/home/you/article-2557765/Is-man-wired-differently.html
  3. http://www.healthcentral.com/autism/c/1443/153287/asperger-difficulty/
  4. http://edition.cnn.com/2013/04/11/health/aspergers-work-irpt/
Share

There is no Silver Bullet like ‘Rush code to live’

There is no Silver Bullet for software development, as you can read in Fred Brooks epic 1975 book about software development titled “The Mythical Man-Month“. But if I have to come up with any Silver Bullet it would be: ‘Rush code to live’. This is a theoretical model for doing software development, which follows the DevOps model. Since it is a ‘Silver Bullet’ it claims to be a revolutionary way to produce software much faster and cheaper.

SaaS needs a rush

In a Software-as-a-Service (SaaS) landscape you need to keep your customers happy by continuous, incremental improvements of the software, which follow an organic growth model. By doing big bulky updates, the user will have to wait a long time before anything changes and the user experience will suddenly change, which might alienate your users. Apart from that: 1) the moving target kicks in; 2) risks grow, since reverting will be increasingly difficult; 3) it is unclear what needs to be tested; 4) and users lose confidence when you keep moving the deadline for the next version.

Organize carefully

So take SCRUM, with a product owner and everything that comes with it. Now split your big software team of into small expert groups of 2-3 people that own a specific part of the code. Increased feeling of ownership encourages responsible behavior. Next is to make sure every group has one natural leader (a more senior developer), to avoid unproductive coding style/architecture discussions. Let the programmers develop blocks of code that are as small as possible, but can be brought to live individually. This would make them work for 2-3 days on a single small feature. If a feature is too big, simply cut it up into parts to make it smaller. Test the feature and bring it to live by the next day, when the code is still ‘top of mind’ and bugs can be fixed fast and easy. It is important the testing is done together with some other developers in demo-like sessions to avoid blind spots and encourage competition and enthusiasm.

Testing and deployment

When bringing the code to live, make sure this is done carefully by only the best developers. Do it when usage is low and do not tell customers about your ‘Ninja deployment’, since this may increase the expectations and thus the bug costs. When bringing code to live, your monitoring must be top-notch and you must be able to revert fast (only to fix bugs and redeploy). This means that if something fails, it will always be the new feature and only a limited set of customers will notice. If you can, bring the feature live for only a subset of the customers first. Both of these measures help further reduce the risk and positively influence the test (test vs. bug costs) trade-off on which you decide the amount of testing effort. Do not hesitate to bring code to live that does not add value. Even if it only provides part of a feature and must therefor be hidden, you should still deploy it.

Change your thinking

Now think outside the box and consider the truth of the following ‘Rush code to live’ principle:

Every 10 lines of code written but not brought live (into production) will cost you one extra man-hour every day.

Reasons it might be true? Only after code is running flawlessly on live will people stop discussing, changing, arguing and worrying about it. Note that I only have a gut feeling to back this claim up, and is not based on any research whatsoever. Still, I believe the cost of unreleased code is way higher than anyone can imagine, so ‘Rush your code to live’ for fun and profit!

Share