Posts de ‘Bernardo Heynemann’

[Bernardo Heynemann] – a story of fun, iterative development and a boatload of javascript

Sunday, December 2nd, 2012 is a game where you use your javascript skills to code a robot that goes into an arena against other robot.

It’s a project for the Github Game-Off 2012 contest. It’s a different kind of hacking contest, in that you have a month instead of a day, two or a week.

It might seem like a minor detail, but it makes all the difference. At least it did for our team. We worked it like we would any other iterative project we might work with at our daily jobs.

The team is composed by myself, Cezar Sá, Guilherme Souza, Fábio Costa and Rafael Carício as devs. The incredible designer Marcela Abbade did the layout for our product.

A small team set for building a product that we didn’t actually believe could be built in such a small timeframe.

TL;DR was developed iteratively and uses Javascript for both client and server.

We run node.js at it’s serverside components and the code for the engine is EXACTLY the same running in the browser or the server.

This was the first time I actually benefitted from running the same Javascript in the server and the client, so I found it interesting enough to share. The code can be found at

How did you come up with the idea for it?

As all such ideas begin: in a table with friends. Someone said: “What if we did an arena where robots fought each other and you did the robot coding with javascript?”.

We all laughed like “yeah like that’s possible”, but the idea started growing on us. A couple months later and here we are.

Some Stats

Before I start I’d like to share some stats with you, because I’m actually very impressed with them.

At the time of this post, we have in the database more than 1500 fights.

Since we launched the website at 4pm of the 28th of November (date of the first fight in the database), that means roughly 14 fights an hour. It’s A LOT more than we expected.

We also have more than 200 people registered and above 150 robots created. Amazing, right?

What REALLY got me, though, is our stats in Google Analytics:

  • About 1000 visits in just a couple days;
  • About 500 unique visitors;
  • More than 11 thousand page views;
  • An incredible average page duration of 11 minutes;
  • Bounce rate of 30%, which means that most people entering the website navigate through it.

I gotta say that again - 11 thousand page views. Even if that counts our own page views, it’s still amazing in a couple days.

You said iterative?

Yep, we worked VERY iteratively. First, we didn’t have anything. Then we had the engine. And then we had the animation.

We spent the whole month of the project iterating and improving over the previous iteration.

And you know what? Iterative development CAN be fun. People spoil all the fun with metrics, meetings and other useless bureaucracy.

What about the game?

Well, the game is pretty simple. Build you robot, we’ll run your code against the other person’s code and see who wins. The easiest way is to go there and play a little bit.

What’s really interesting about it is how we calculate things and how we render the fight in the browser.

The first peculiarity about our game is that it’s engine needs to be 100% deterministic, since we can’t have different results in the server and the browser.

What that means is that we DO NOT store the rounds of the fight. We calculate them in the server based solely in the code of both robots and some initial info (like robots positions).

The engine is 100% javascript. That helps us A LOT in running it in both the server and the client. We used Coffeescript for it and were very positively surprised. If you are wondering what the engine looks like, go take a look at it.

The Engine‘s engine is a turn-based engine. It might seem realtime in the browser, but it’s not. I’ll cover how we do it’s animation below.

The engine loops on the robots codes, logging everything until one of the following happen:

  • Only one main robot (not a clone) is left alive;
  • The fight times out (after a fixed number of rounds), in which case it’s a draw.

The really interesting part of the engine is it’s code: collision detection, line of sight and a lot of interesting stuff there. The end result is an array of rounds that will get passed to the interface to be animated.

The code for the engine can be found at the file.

The Animation

The animation part was tricky for myself, since I didn’t have much experience with RequestAnimationFrame. I couldn’t be more pleased. It was so easy making animation that actually renders the same across different computers.

Other than animating, we calculate the fight (run the engine) in WebWorkers so that we can maintain a responsive UI even when hardcore CPU cycles are being demanded. If you haven’t tried them, I seriously advise you to play with this amazing browser technology.

The fight goes like this:

  1. WebWorkers calculate the entire fight;
  2. We animate the resulting rounds with RequestAnimationFrame.

The RequestAnimationFrame method takes a callback function as argument. The function should receive a timestamp that represents the time at which the animation you requested is scheduled to occur.

What this means is that you can easily find out how many milliseconds of animation you have to run in this “step”.

In our case, we just subtracted the timestamp from the last processed timestamp to find out how many rounds should be rendered by the browser.

The code for the main portion of the animation is in the file.

What’s next?

I have an amazing robot and I want more! What’s next?

Glad you asked. I’m not sure what’s next. If you feel that there’s something missing, please feel free to create an issue at our github repository and we’ll consider it for our next release.

Right now we can’t do anything. We have to wait until the judges try the app for themselves.

Hope you guys have as much fun as we did.

[Bernardo Heynemann] r³ – A quick demo of usage

Saturday, August 4th, 2012

My new map/reduce engine project, got a lot of attention last week and before that in twitter, facebook and even hackernews.

So I decided to write a sample project demoing the usage of r³.

The problem

I had to find an interesting, yet simple problem to show in this demo. Since I am a huge fan of github, I decided that I would show each committer’s percentage of commits in a given repository.

GitHub has a VERY nice API that you can use  to retrieve a myriad of information on your own repositories or on other people’s repositories (provided they are public).

You just have to access to get the first 100 commits in the linux kernel repository. The resulting document comes with a link header that specifies where the next 100 commits can be found.

The Input Stream

Cool! So my map/reduce operation should operate on top of all commits for a given project. That means that in my input stream I just need to capture all those commits and return them.

I just built a simple crawler that keeps looking for the next page of commits until it can’t find one.

To save myself some time and bandwidth it also stores those commits in a temp folder as means of caching them.

The code:

 1 #!/usr/bin/python
 2 # -*- coding: utf-8 -*-
 4 from os.path import exists, join, dirname
 5 from urlparse import urlparse
 6 import os
 7 import sys
 8 import urllib2
10 from ujson import loads
12 CACHE_PATH = '/tmp/r3-gh-cache'
14 class Stream:
15     job_type = 'percentage'
16     group_size = 10
18     def process(self, app, arguments):
19         if not exists(CACHE_PATH):
20             os.makedirs(CACHE_PATH)
21         user = arguments['user'][0]
22         repo = arguments['repo'][0]
24         return get_repo_commits(user, repo)
26 def get_repo_commits(user, repo):
27     next_url = '' % (user, repo)
28     commits = []
29     index = 0
31     while next_url:
32         index += 1
33         content, next_url = get_url_content(next_url, index)
34         json = loads(content)
35         for item in json:
36             commits.append(item)
38     return commits
40 def get_url_content(url, index):
41     parts = urlparse(url)
43     url_path = join(parts.path.lstrip('/'), parts.query.replace('&', '/').replace('=','_'))
44     cache_path = join(CACHE_PATH, url_path, 'contents.json')
45     next_path = join(CACHE_PATH, url_path, 'next.json')
47     if exists(cache_path) and exists(next_path):
48         print "%d - %s found in cache!" % (index, url)
49         with open(cache_path) as cache_file:
50             with open(next_path) as next_file:
51                 return,
53     print "%d - getting %s..." % (index, url)
54     req = urllib2.Request(url)
55     response = urllib2.urlopen(req)
57     contents =
58     print "%d - storing in cache" % index
60     if not exists(dirname(cache_path)):
61         os.makedirs(dirname(cache_path))
63     with open(cache_path, 'w') as cache_file:
64         cache_file.write(contents)
66     next_url = None
67     if 'link' in response.headers:
68         link = response.headers['link']
69         if 'next' in link:
70             next_url = link.split(',')[0].split(';')[0][1:-1]
72     if next_url is not None:
73         with open(next_path, 'w') as next_file:
74             next_file.write(next_url)
76     return contents, next_url

This stream is very simple. All it does is get all commits for a given project (using the arguments user and repo) and return it as a stream for r³.

The mapper

Now that we have all the commits for the given project it can’t get any simpler. We’ll just separate the commits per commiter like this:

 1 #!/usr/bin/python
 2 # -*- coding: utf-8 -*-
 5 from r3.worker.mapper import Mapper
 7 class CommitsPercentageMapper(Mapper):
 8     job_type = 'percentage'
10     def map(self, commits):
11         return list(self.split_commits(commits))
13     def split_commits(self, commits):
14         for commit in commits:
15             commit = commit['commit']
16             yield commit['author']['name'], 1

That gets the number of commits per user in the project.

All that’s left is to reduce this to a coherent value.

The reducer

The reducer just iterates through all committers and assigns percentages:

 1 #!/usr/bin/python
 2 # -*- coding: utf-8 -*-
 4 from collections import defaultdict
 6 class Reducer:
 7     job_type = 'percentage'
 9     def reduce(self, app, items):
10         commits_per_user = defaultdict(int)
11         total_commits = 0
13         for commit in items:
14             for user_data in commit:
15                 login = user_data[0]
16                 frequency = user_data[1]
17                 commits_per_user[login] += frequency
18                 total_commits += frequency
20         percentages = {}
21         for login, frequency in commits_per_user.iteritems():
22             percentages[login] = round(float(frequency) / float(total_commits) * 100, 2)
24         ordered_percentages = sorted(percentages.iteritems(), key=lambda item: -1 * item[1])
25         return {
26             'total_commits': total_commits,
27             'commit_percentages': [{ 'user': item[0], 'percentage': item[1], 'commits': commits_per_user[item[0]] } for item in ordered_percentages]
28         }

Getting it all together

Now it’s time to get all the things we done together and start looking at some famous repositories.

In order to make this easier, I setup a repository in github that has everything in place.

Just clone it, type make run and the server will be running.

WARNING: The make run command will install some python packages. If you don’t want them to be installed system-wide, create a virtualenv before running the command.

Interesting Trivia

I ran r3-gh against some famous repositories and got some interesting information. Be advised that the number of commits does not reflect code committed and/or effort spent, since some people commit more often than others. This is meant simply as trivia and as a way of demoing r³.

That said, let’s take a look at the rails repository (total of 25974 commits):

Now let’s see how django is distributed among committers (total of 12403 commits):

And finally the linux kernel (total of 63226 commits):

It’s worth noting that I excluded every committer that had less than 1% of commits (and more than 0.5% for the linux kernel),  so the percentages are a little off.


It is pretty simple to get r³ to do some cool calculations for us. I got the whole sample in a very short amount of time. It took me more time to write this post than to make r³ calculate the commiter percentages.

Hope you guys come up with some interesting stuff to calculate as well.

[Bernardo Heynemann] thumbor is a freaking awesome project or why open source will win every time

Saturday, July 21st, 2012

People who know me are well aware that I love Open Source with all my heart. I have more than 50 open-source repositories in my github account. Some are maintained, some are not.

This post is not to talk about me, though. It is to talk about how freaking incredibly awesome Open Source is and how people will surprise you every time.


Thumbor is a much better project because of the MANY MANY contributions we have received from the comunity.

I can’t stress enough how incredibly fortunate we are that there are so many VERY SMART people out there willing to contribute back to our project.

That’s why Open-Source will win every time against proprietary software. Because of the people. Keep reading if you want to know more about our story.

The Project

Thumbor is an open-source image operations server. Don’t let this simple description fool you. IT IS powerful. It does INCREDIBLE stuff that saves our company a boatload of money.

When we started the project, the development team decided on open-sourcing the project.

It is general purpose enough as not to require any of our internal information and/or business details to leak.

This decision comes with some trade-offs, that seem very negative at first. A couple questions that came up?

  • How are we going to change the way Thumbor stores images? Do we need to fork the project to have our “company version” of it?
  • How do we load images from our domains only? (Repeat first question proposed solution and rinse)
  • How do we stop attackers from overloading our servers with requests for images of different sizes?
  • How do we stop competitors from using our software to their advantage?
  • How is this any valuable compared to using a proprietary solution (given we have the money to buy it)?

As you can see, there are many questions people came up with NOT to open-source the project.

We decided we would tackle each of those problems when their time came.

The Team

I want to give a brief description of the team behind Thumbor just to clarify why we decided to open-source it even in the face of so many questions.

First, there’s Fábio Costa. He’s a kick-ass developer, committer of the MooTools project and a great colleague. He’s also a BIG supporter of the Open-Source philosophy.

Rafael Carício is also a big-time supporter of Open-Source projects, being committer of Pyvows and many other open-source projects. Recently he spent two days just fixing issues with the default Python interpreter. Pretty awesome if you ask me.

Then, there’s Cezar Sá. Again, an avid Open-Source supporter. He’s committer of Rubinius, an alternative implementation of the Ruby language. He’s the guy behind Thumbor filters architecture.

The Decision

If we were going to open-source Thumbor, we needed to make sure it was as extensible as possible.

Every single part of Thumbor needed to be easily switchable for a different part with the same contract.

This kind of architecture is not simple to build, so we came up with parts that would be general enough so you can start using Thumbor right away.

We also needed to come up with a system to stop people from exploiting Thumbor to generate an infinite number of images and thus overload the server. We came up with encrypted URLs. We don’t believe in security by obscurity either, meaning that even if the software was closed source, people would exploit it.

The company we work for,, has many, many images (millions) and many users (nearly 5B page views/mo). So we had to make sure Thumbor was up to the task. So we fine tuned it.

The Premises

Ok, so what were our premises for thumbor?

  1. We need everything to be extensible, so we also need to come up with reasonable implementations of the extensible parts;
  2. We need Thumbor to be safe, so we must stick to secure by convention, meaning that if you don’t change a thing, Thumbor is secure;
  3. We need Thumbor to be fast so it can handle many operations per second without requiring expensive clusters

I’m skipping intentionally the main premise which is we want Thumbor to be the best software at cropping images which is what drove us to build it in the first place.

Skip a couple months to the future…

Ok, we have the first version done! Let’s go live with it.

So we fire up our servers and Thumbor is a go. We notice it’s a little slow, but hey, it’s doing its job and we started with a small team of users.

Then the unexpected happens!

Community created issues start popping up! And then they start coming up with CODE ATTACHED.

Now let’s stop for a moment and analyse this. There are MANY companies out there that charge A LOT of money for testing services.

We have FREE skilled testers in our project now. People who are proactively testing it for us and reporting back their findings.

Not only that, they are fixing our software for us and giving us back the code with NO STRINGS ATTACHED.

Let me say this again, these people, highly skilled individuals, all of them WITH JOBS, are working for free in a project they did not start.

This is humans at their best if you ask me!

Extreme Makeover

Remember I said that we’d implemented all the extensible parts and security?

That’s another incredible aspect of Open-Source Software: people READ your code.

People read ours. They found MANY, MANY things to improve/change/add/remove. We are grateful for every single one of them.

The project would not be as good as it is for our users if it wasn’t for the people that are contributing.

Why do I say that Thumbor underwent Extreme Makeover? Because if you look at the first version that we released and how Thumbor is right now there’s no way you would say its the same software.

Through contributions we improved storage, loading, graphics engines, security (A LOT), performance (A LOT) and our software practices.

That’s actually one thing of the process of developing open source software that is very humbling. People pay more attention to software practices like testing and continuous integration when they are trying to get their patches accepted.

And they call on you when you are slipping on your side of the fence. And we got called! And we listened. All of us came out of the process better at our craft.

The Conclusion

Thumbor has already payed for itself many times. It is so useful to us that we don’t care if our competitors use it, as long as the community keeps improving it.

As for buying a proprietary software, I haven’t found a single one that does the same as Thumbor and even if we do, we’ll never get this level of creativity, support and diversity from any given company.

This means if we have to choose again between open or closed source, I think we’ll stay with open source every single time.


I think I did stress in this post how much I appreciate all the contributions, but I still feel obligated to thank you guys. Your contributions have been incredible and are all INVALUABLE.

So sincere thanks to (in no particular order):

[Bernardo Heynemann] 2010 in review

Sunday, January 2nd, 2011

The stats helper monkeys at mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

Featured image

A helper monkey made this abstract painting, inspired by your stats.

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 1,500 times in 2010. That’s about 4 full 747s.


In 2010, there were 17 new posts, not bad for the first year!

The busiest day of the year was May 26th with 104 views. The most popular post that day was 4×4 Dojo Technique.

Where did they come from?

The top referring sites in 2010 were,,,, and

Some visitors came searching, mostly for django compressor, bernardo heynemann, django-compressor, django js compressor, and storage module “” does not define a “appsavvycompressorfilestorage” class..

Attractions in 2010

These are the posts and pages that got the most views in 2010.


4×4 Dojo Technique May 2010


Django Compressor – Minify/Reduce Requests June 2010


Deming – System of Profound Knowledge and Key Principles July 2010


Dream Team – Part I – The People July 2010


About May 2010

[Bernardo Heynemann] Dream Team Part VIII – Autonomation

Monday, December 27th, 2010


Jidoka, also known as “intelligent automation” or “automation with a human touch”, is lean’s way of automating repetitive tasks.

This time we join the INews team as they try to define how far to go with automating or not repetitive processes.


John – Hey guys! How was christmas?
Jane – Pretty good! Yours?
John – Really cool. What about the rest of you?
All – It was great!
Christian – We’ve been talking a lot about lean concepts and I’m not that familiar with lean methodology. Whenever I don’t know something I yearn to learn it. I’ve spent all my free time in the last weeks studying it. One thing that comes over and over is autonomation. That is a kick-ass concept!
Jane – Autonomation?
John – Yeah Jane. Autonomation means automation with intelligence.
Jane – What do you mean “with intelligence”?
John – Well, machines lack intelligence, right? That’s why it’s called artificial intelligence. So automation with intelligence means automation with humans involved. It means automating to become more efficient. It means automating well-known repetitive tasks.
Jane – Oh. I see.
Susan – I think we do that already, right? Our build is automated, for one. Oh! Our tests are automated as well! Hmm… I see your point! We could build and test our app ourselves. We just automated it so we are more effective. We didn’t replace ourselves for a machine. We are using it to help us!
John – Exactly. Still, I think we are not aggressive enough with autonomation. Susan, when we finish stories, what do you do to help us accept them?
Susan – I verify the results versus my mock screens to see that you got the proper sizes, margins, etc.
John – And that’s pretty repetitive, isn’t it? That’s something we could come up with a creative way of automating. Joseph, you perform a lot of exploratory testing as well don’t you?
Joseph – Yes I do, but how can you automate exploratory testing, which is by definition human?
John - Hmm… We can’t automate exploratory testing. What we can do is automate the tests you perform every time. We could come up with some strategy to record the tests you do and automate those. This way, every time you did exploratory testing we would end up with a richer testing suite.
Joseph – I see. Well, I guess we could be more aggressive about autonomation.
Christian – So it seems like a team value, doesn’t it? Automating things to improve our effectiveness.
Joseph – Indeed it does, Christian. Indeed it does.


There’s a big emphasis on not automating things with the intent of replacing humans. The goal of jidoka is to make humans more effective and aid them in detecting problems early and often.

Whenever something can be automated to improve the team’s capacity to respond to change, it should be. The automation should not happen before the actual way of doing things is well-known to the people involved. This is paramount so the automation has the proper goal (as outlined above).

[Bernardo Heynemann] Python Test Spy Engine – MI7

Sunday, November 21st, 2010


MI7 is my new pet project. I grew tired of the other mocking/stubbing/spying engines in Python that never did quite what I expected them to.

I’ve been TDDing for a while now in .Net, Ruby, Python and JavaScript. I’ve got my fair share of experience, so I figured I’d give my 2¢ in this issue.

You can check the project at It’s got a nice tutorial and is currently in 0.1.1 alpha release.

I’ve got a lot of work to do to make it my main tool for test support, but I’m going to get there. Without further delay, let’s get to it.

Why another Spying Engine?

If you check the MI7 wiki you’ll see that I don’t have anything against any single python test support engine. I just haven’t found one that suits my needs and those needs ONLY. IMHO they all do too much. I want a simple, straightforward, fun to use spying engine.

Don’t get me wrong, but I do not believe in mocking in Python. Or stubbing for that matter. Both are akin to dependency injection, IMHO. It just isn’t pythonic.

Python has been around for a while. In this time, there has been a certain Modus Operandi of doing work. This MO has never included injecting your dependencies around. I figured that’s why I feel the weirdness on the part of the mocking/stubbing/spying tools.

With MI7 I’m trying to interfere as less as possible with your code. Production code should be optimized to be production code, and not changed to accommodate your poor testing tools. In the Ruby community they try HARD to make tests and code as clear as possible, not make code work according to tools. I’m trying to get some of that.

The last point of me doing MI7 is to have some fun, and I’m trying to bake in the library as much of that fun as possible, with the spy agency metaphor. Hope you enjoy as much as I am.

Test Sample

Ok, so I’ll write a test with MI7. It’s pretty simple:

from controllers import MyController
from models import User
def test_user_is_authenticated():
    agents.User.intercept('is_authenticated') \
    agents.User.intercept('username') \
    ctrl = MyController()
    result = ctrl.index()
    assert result == "Welcome Bernardo"

So what’s happening here. I’m telling MI7 to keep an eye in the User model, wherever it may be used. Then I’m instructing the User agent (the agents get their code-name from the target they are spying), to intercept calls to is_authenticated and username and return my values.

Now the controller code:

from models import User
class Controller(object):
    def index(self):
        user = User()
        if user.is_authenticated():
            return "Welcome %s" % user.username
        return "Unauthorized"

As you can see, there's not a single line of code in that controller that says "I'm testable". It's just plain old python coding.

Current Status

Currently MI7 supports intercepting modules and classes and telling agents to intercept methods and attributes and to raise exceptions.

Impersonation (stubbing) may come next. Definitely assertions are coming, like what an agent has seen and such.


I’ll keep going with MI7 development as much as I can, because I believe the Python community needs better testing tools and I’m willing to put extra effort into this.

[Bernardo Heynemann] Dream Team – Part VII – Ownership

Monday, August 30th, 2010


The INews team has reached an important milestone. Four of the team’s values are defined and understood.

This time they are talking about a very controversial topic: product ownership.

Who owns it?

John – Hey! How are you all today?
All – Good!
John – I was reading an awesome article last night. It was so good I felt like calling you guys immediately.
Susan – What was it about?
John - About product ownership. The idea here is that you push product decisions as close to the people working with them as possible. The company is responsible for setting the context that allows those people to decide.
Jake – What do you mean by context?
John – The company is responsible for setting strategies and broad scope goals, as well as providing the team with whatever other intel they might need – financial, internal, market share, marketing, you name it. If the team needs that information, they should get it.
Christian –
Ok, I totally agree with that. I’m still wondering about the ownership part, though.
Susan – In the last event I attended, Wackile – agile for the wacky – I saw a brilliant presentation about how projects are killing agile initiatives. Projects are tricky beasts. They have start, finish and handover. At first there’s nothing wrong with that, except there’s no incentive whatsoever for developers to choose long term decisions. They’ll be long gone by the time their decisions affect the product.
John – I see. Well, Chris, what I meant with ownership is that we as a team should be the ones deciding where the product should go. Not someone with no context about the intricacies of the product. What Susan just pointed out just reinforces the need for the people working with the product to feel part of it.
Jane – I couldn’t agree more. As an experience designer I get to decide quite a few things about the product. Sometimes, though, I wish the team had more freedom to choose their own path.
Joseph – I’ll get Daniel here as I believe he’ll be able to tell us whether this value is aligned with the company’s values.

Ok, you guys don’t know Danny, but he’s a great CIO at Acme. He really fights for his teams, in order to provide them with the best possible work environment.

Daniel – What’s up guys? What can I do to help you?
John – Hey Danny. Thanks for joining us in so short notice. The thing here is we decided as a team that one of our values is that we want to own the product in the lean sense that we get to make product decisions…
Daniel – While the company sets the context, right?
Joseph – Right.
Daniel – Perfect. No problems with me. I’ll get our CEO buy-in. As a start is there any intel I can help you with?
Susan – Hi Danny. Actually, there is: Other news companies’ market share on mobile news delivery.
Daniel – I’ll get you guys that info asap. Now I gotta run. See you all. Take care.
All – See ya!

“What a great guy!”, I think to myself.

Joseph – I guess we just got another team value: we own the product and we’ll take care of it thinking about the long run.
Me – IMHO this was the best meeting so far. Danny is the best.
Joseph – That he is, Bernardo. That he is.


The people who are more qualified to make important product decisions are the same ones working with it on a daily basis. They know all of its intricacies and constraints.

Why risk having someone that does not fully understand the issue deal with it?

Yet, most companies keep pulling decisions up in their hierarchies, trying to protect their products from the poor judgement of their employees.

Not trusting the people doing the work to make decisions results in shallow decisions and lack of commitment by the people working with the product. Short-term actions are made, the product evolves in unintended (and bad) ways and eventually people want to get out of the product team. At some point a major redesign and rebuild is needed.

Have you guys ever seen this?

[Bernardo Heynemann] Dream Team – Part VI – Respect and Fun

Monday, August 30th, 2010


The last time we met with the Acme INews team I was telling you guys how they came to the conclusion that if you don’t release it, you lose it. Ok, I’m just kidding, but they all agreed that unreleased code is waste and that it was a value for all of them to diligently work on reducing cycle time variation.

This time around we touch a subject that most companies (well at least some of the ones I know of) don’t like to discuss. Respecting your employees as you expect them to respect you, and allowing them to have fun. Yes, that’s right, FUN! Let’s see what the INews team thinks of that.


Jane – Hey guys. I wanted to talk to you about something since we first met to do this job.

John – Sure Jane, go ahead. I think we must maintain an open channel for communication at all times if we are to succeed as a team.

Jane – Thanks John. Well, sometimes in my previous projects I got the feeling of being an outsider among developers. I heard comments about how I was being picky and annoying. That made me feel very bad and in those projects I feel like I contributed less than I could because I was afraid of that behavior.

Jake – Jane, that’s a very good thing to discuss. As a client-side developer I heard comments in these areas as well. After discussing with the devs and explaining to them my point of view, things worked out quite alright, though.

Jane – Yeah, it might be so. Even so I still think I shouldn’t have to do that. If we are in a team we trust each other and respect each other’s point of view, right?

John – Absolutely right! There can be no better opinion or prevalent point of view. If we are a multidisciplinary team, we should value each other’s opinions above all and treat each other as we want to be treated in return.

Susan – No offense, guys, but sometimes I feel the designers take our opinion for granted as well.

Jane – Hmm… I see… Can you ellaborate, Susan?

Susan – Sure. Sometimes a designer comes up with an user experience that’s great. It really is. I can see myself loving that experience. It just isn’t realistic given our constraints (might be hardware, network, you name it). Usually I approach the designer and explain that. A lot of times I got a “it’s not my problem” look and had to resort to my boss for help. I would say I didn’t get the same respect I was showing for that professional.

Jane – Sure you didn’t. Well, I guess it does go both ways, doesn’t it?

Joseph – I’m pretty sure we can get along if we just try to always see the other person’s point of view and treat them with the same respect we expect them to show towards us,  don’t you agree?

All – Yep.

I keep getting amazed by how simple they make these things look.

Christian – I’d like to discuss a related topic. When I’m contributing to some project or even coding one of my own, usually I have a purpose to fulfill (I need the feature, someone at work does, or I just find it cool). Even though I have a purpose, if it’s not fun, I won’t do it. No matter how much I force myself to do it, I just won’t.

There will be something else that is a lot more fun to do, or I’ll go read something. I was wondering how can we make sure working in our project is fun. How can we enjoy that feeling of “Great!!! I’m going to work today!” when we wake up?

John – I don’t think there’s one right answer for that. I believe it’s a set of things. A great project makes we want to come work on it (the cool tasks as you said). A great environment where we respect each other does that as well. We already have our XBox 360 and our foosball. How do you guys feel of ‘do whatever you want’ friday?

Christian – What do you mean?

John - Every two or three fridays we’ll get a free day. We can code whatever we want, with whomever we want. We can study, experiment or just play a game together. Anything that improves our project in any way whatsoever.

Susan – That’s a very interesting idea. Can we refactor our own product’s code or implement a feature we’d like to see int he product?

John - Sure. Anything we want.

Jane – Could I use that day for discovery and experimenting with different things?

John - Of course! Anything that you think will help!

Jane – Ok, can’t wait till next Friday!!!

Joseph – I really love that idea. I think we are set in two VERY intertwined values. Might be the same value altogether. Respect and Fun with responsibility. Meaning that we’ll respect each other and have fun together, while delivering business value to ACME. Is that about right?

All – YES!!!

Me - Ok, again with time to spare, and it’s about time to go. Anyone for a settlers game?


Several companies (like Yahoo, JotSpot, Atlassian, Facebook, Google, Atom and Technorati), have already found that by letting your employees self-organize and make their own decisions about the product they are working in pays out big time.

Having a fun environment is not only a bonus to productivity. It is a requirement for creative skilled workers to unlock their full potential. Companies that keep trying to control what their employees are doing (via timesheets, task monitoring or metrics) are in fact killing the motivation that could trigger incredible features to their products.

A product team must be kept in a fun, respectful environment where they can decide what they want to do instead of being bossed around. This way, they’ll be working in the product in their free time, because they want to do it.

There’s a very good video by Dan Pink about what motivates us. Basically it’s authonomy, mastery and purpose. You can learn more by watching the video. I VERY DEEPLY recommend it. It really changed my way of seeing some things.

[Bernardo Heynemann] Dream Team – Part V – Delivery

Sunday, August 22nd, 2010


In our last installment, we learned that the INews team decided to never let problems grow and instead solve them as soon as they appear. They also decided on having a formal way of solving problems, so that they (and the rest of the company) may benefit in the future.

This time we accompany them as they discuss a topic that is very near to my heart: Delivery.

Release or not Release, that’s the question

John – Morning all! We had a very productive day yesterday, now didn’t we?

All – Yep.

Susan – I’m sooooo sleepy, John! (*chuckles*) Yesterday I went home thinking about some values that I hold dear. I’m not sure this is the time to discuss it, but I really enjoy delivering business value. I’m filled with joy when I realize that my work is helping our coworkers in being more productive RIGHT NOW. How do you guys stand on this?

John – Well, when you study Lean Manufacturing, you learn all about delivering, since they consider anything that is not being used by a customer or adding value to a product to be waste. So, if you are a factory worker, your sole purpose is to drive the product as fast as possible to a client. Please note that as fast as possible takes into account every single quality factor that the customer expects.

Christian – I have a lot of experience in delivering, but we call that releases in my projects. I release as often as I can so I can gather feedback from the community. It is also a very good idea to release as much as you can to minimize the amount of work that goes into a release.

Jake – I don’t have much experience in this area, but something tells me that releasing often makes a lot of sense. I was just wondering how the big guys do it: JQuery, Django, Apache and other projects like that. How do they release?

Christian – I’m not sure how they do their releases, but I love apache’s concept of a release: “Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released.” [1]

John - Yeah, couldn’t agree more. You should release as much as makes sense. Unreleased code sitting in our laptops does no good to our clients.

Jane - Well, when I design a user experience for a product, I have to think a little ahead about how our users are going to interact with it. Imagining their experience is in no way a substitute for learning how they are actually using it, so I too consider it to be crucial to have customers using our product as fast as we can, even if we have to cut a little bit on the feature side.

Joseph - Funny thing, I just purchased Continuous Delivery, a book that was just released (no pun intended). This is one of my favorite subjects. I do believe in continuous delivery. As soon as we mark features as complete, we have them in production. Lean Manufacturing introduces a measure called cycle time, which means the total time between a customer requesting something and the customer getting to use it. What I understand we just agreed, is that we will work diligently to reduce our cycle time as much as we can.

John - That sounds about right!

Me – Once more with time to spare! Let’s play some foosball.


Sometimes we are working in something really cool in our projects. Sometimes we are just fixing stuff. The point here is not what we are doing. It’s who’s benefiting from it.

If you are building software I assume that someone is going to use what you are building. If that’s the case, until that customer starts benefiting, your code is waste.

Cycle time is a very interesting measure, in that it measures your turn-around time to new features, as much as your responsiveness to issues that you or your customers find in the software.

From Wikipedia:

Cycle time variation is a proven metric and philosophy for continuous improvement with the aim of driving down the deviations in the time it takes to produce successive units on a production line.[1] It supports organizations’ application of lean manufacturing or lean production by eliminating wasteful expenditure of resources. It is distinguished from some of the more common applications by its different focus of creating a structure for progressively reducing the sources of internal variation that leads to workarounds and disruption causing these wastes to accumulate in the first place. Although it is often used as an indicator of lean progress, its use promotes a structured approach to reducing disruption that impacts efficiency, quality, and value.[2]

In my humble opinion, the best thing about cycle time is that it is a TEAM metric and not an individual one. That means that if the team collaborate to improve work and reduce waste everyone benefits from it.

[Bernardo Heynemann] Dream Team – Part IV – Problem Solving

Wednesday, August 4th, 2010


So far our team has decided on a set of values and we saw how they discussed the first one.

Now we join them as they get back from Starbucks to discuss again their values.

Problem Solving

The meeting starts again and once more I’m in charge of keeping time. John starts:

Credits to Ell Brown

John – Hi guys! Welcome back! That was a nice coffee break. There’s something I’ve been thinking about and I’d really like to talk with you guys about.

I would like to discuss how each of you feel about problem solving. If we are to keep continually improving we need a systematic way of solving problems. At least that’s how I feel.

Jake - What do you mean by systematic?

John - I mean we need some way to archive the knowledge we gathered and the solution we had for each problem. This way we don’t need to repeat ourselves when solving the same problem, or even when some other team in the company wants to solve it. I read about how Lean companies do it with A3 report cards and I really liked what I read.

Susan - Even though I never worked with a formal way of solving problems, I often thought that we should have a way of publishing our findings when we decide something.

Christian - Can you give an example?

Susan - Sure. In my last project we were using Python as our main language. Some team members had experience with Django, while others preferred to use a more low-level framework like CherryPy. Preferences aside, we were expected to provide real-time dynamic data to more than a hundred thousand concurrent users, so performance was a key constraint for us.

Jake - Wasn’t there a benchmark you could use to decide?

Susan - We didn’t find one, so we ended up doing a thorough comparison of some Python Web Frameworks with many different production settings (Apache, Nginx, you name it). The results pointed us in the right direction.

The thing is that even though it was very cool to learn all that on a personal level, I feel that we didn’t leave behind any trail of this knowledge to other teams. Probably others have done this already, as was reported by our production team. If we don’t have a formal way of solving problems like this, we are bound to repeat this effort time and again.

John – I couldn’t have summarized it better. Thanks Susan for explaining what I meant. That’s exactly it. Knowledge generation is a problem that I really care about. What about you guys? What do you think?

Credits to Dan.

Jane - We have that in the Design team. We always leave behind reasons and the discovery made to achieve a certain standard. I thought that you guys did that as well. I most certainly think we need to standardize how we decide things. This is key even within our team.

Imagine me and Christian finish some UI definition together and we want to share with you guys. I expect that you’ll want to know what were the assumptions and everything that led us to define the UI in the way it was defined, right? In order for that to happen there needs to be some mechanism to formalize knowledge. I really like this A3 thing, since I love sketching with pen and paper.

Christian - I don’t have much to add except that whenever I work in Open Source Projects, each project has its own way of preserving knowledge. Wikis, evolution proposals, docs, release notes, you name it. The key thing is that all successful projects share this trait in common. They all keep their knowledge at heart. I think we should do the same. I’d realy like to try this A3 technique, if we can change it later if we don’t like it.

Joseph – Hey, that’s brilliant. We agreed already on changing any process that does not work to something better, didn’t we?

All - YES!

John - Ok, we have a way to solve problems, but how are problems going to affect our work. I hear Susan has already worked here in the company using Stop the line methodology, right?

Susan – Yes, I did. And it was GREAT! The team used the motto: “The best time to solve a problem is RIGHT NOW!”. I learned later that this translates to the Jidoka principle in LEAN methodologies. It means that whenever we have a problem we stop working in whatever we are working to solve that problem. It seems counter-intuitive, since we’ll be “less” productive due to solving problems. The thing is even though this slows us down a little in the beginning, it speeds us up GREATLY in the long run.

Christian – What about bugs? Do we keep them in a bug tracker?

John - I reckon that if we keep solving bugs whenever we find them or whenever people report them, we should have 1 or 2 bugs open at any given time tops. Who needs a tracker to track 1 or 2 items?

Christian - Makes sense.

Joseph – So we as a team agree that whenever a problem arises the proper number of people in the team should stop as soon as possible to fix it and then find a way (at first an A3 report) to leave behind the knowledge on how it got fixed and why. Is that it?

All – Yep.

Joseph - Ok, I think we got our second value. The best time to solve any problem or defect is now.


Software Craftsmanship is a creative activity. As such we are confronted with problems and issues every day. It seems to be a good thing to just archive the issue in some way (bug tracker, tech debt card or any other way you can think of).

The problem with this is that the issues start building up and work starts to slow down. If you keep stopping the line whenever you find a problem, eventually the number of issues will decrease astoundingly. When the number of issues decrease, the speed of the team increases.

Refactoring code is one way to stop the line whenever you see code that is not clear. Fixing a bug you found while on another story is a way to stop the line. Acting on an integration problem with the customer is a way to stop the line. Introducing an improvement in the process is a way to stop the line. Anything that solves any problem RIGHT NOW is a way to stop the line.

There must be a way of publishing the results of problem solving in a way that people can benefit or refer to in the future. This leads to a better knowledge management and improved collaboration within the company. One suggested way of doing this is how scientists currently do: the scientific method. Since I already discussed it, I won’t say anything further.

If anyone has any suggestions on problem solving or stopping the line, please leave comments.