Creative Chaos

Vinicius Gomes

New Address

Hi. I’m blogging from a new address. Update your RSS reader:

Thank you!


The Democratic Republic of Flat Earth

As proposed in a previous post, I believe that democracy does not properly lead to optimal social outcome because of a couple of fundamental issues:

  1. Democracy, as pointed out by Kant, is a despotic system, meaning that the opinion of the majority is generally imposed to the minorities.
  2. In a democratic system, the power dispute is pretty much open to whatever group is interested and there is no distinction between passional ideology and rational methodology.

As a consequence, democracy exposes the society to potential damage risk as it gives the opportunity to erroneous/malicious ideologies to influence the public opinion and grow political power. In 1940, the British philosopher Bertrand Russell wrote:

Some forty years ago, in the town of Durban, a member of the Flat Earth Society challenged the world to public debate. The challenge was taken up by a sea captain whose only argument in favor of the world’s being round was that he had been round it. This argument, of course, was easily disposed of, and the Flat-Earth propagandist obtained a two thirds majority. The voice of the people having been thus declared, the true democrat must conclude that in Durban the earth is flat.

As Russell points out, one’s propaganda capacity is directly proportional to his effectiveness on influencing the public opinion. This condition is logically reinforced when the educational level of the population is lower.

Having said that, it seems the political power in a democracy is dependent on sophistry skills associated with some level of broadcasting media control. Not surprisingly, the actual political scenario of modern democracies endorses this view, as demonstrated by Lawrence Lessig (thanks to @vbandrade).

Overall, the assumption of collective wisdom and method-free political discussion that founds democracy proves itself to be not only conceptually incoherent but also actually harmful.

Collective wisdom, alas, is no adequate substitute for the intelligence of individuals. Individuals who opposed received opinions have been the source of all progress, both moral and intellectual. They have been unpopular, as was natural. Socrates, Christ, and Galileo all equally incurred the censure of the orthodox.

Many of the social innovators throughout the history, as Russell mentions above, were representatives of minorities and they have been usually rejected by the common sense. In the modern times, this scenario can be as well observed quite frequently. Freedom from slavery, feminism, gay rights, freedom of creed are examples of complex struggles minorities fought.

Given those problems, how a more reasonable social system would look like? In my previous post, I’ve already proposed *consensus* as an alternative to democracy, giving the Scientific Community as a success case of it. Could you think of other alternatives or improvements on the current state of affairs in democratic nations?

Democracia não funciona.

Em tempos de protestos pelo Brasil, a “defesa da democracia” virou moda. Pois bem. Através de um exercício lógico simples, é possível concluir que a democracia, além de não ser o sistema social ideal, ainda oferece riscos potenciais à sociedade.

Kant, em seu livro sobre direito internacional, afirma que a democracia, assim como a tirania, é um regime despótico. Se por um lado na tirania o interesse de um pequeno grupo é imposto ao resto da sociedade, na democracia o interesse da maioria é imposto às minorias. Portanto, em diferentes escalas, ambos são regimes que não oferecem justiça social de forma plena.

Contudo, quando se trata de uma república democrática, os diferentes grupos e seus interesses têm a chance à disputa livre pelo poder. O que se observa, no entanto, é que essa disputa é predominantemente baseada em ideologia e crença – o que acaba abrindo o precedente para consequências bastante negativas. A “cura gay”, Mitt Romney, Enéias e sua bomba atômica, são só os exemplos mais caricatos.

Desta forma, ainda que a democracia seja fundamentalmente baseada em campos do conhecimento científico (sociologia, ciências políticas, economia, história…), o que parece faltar à discussão democrática é metodologia, racionalidade – rigor científico. Quando abrem-se as portas do poder público para o pensamento dogmático e irracional, anula-se a possibilidade de discussão construtiva e expõe-se a sociedade a sérios riscos – violação dos direitos humanos e homofobia são exemplos recentes.

Assumindo-se essas circunstâncias, vamos analisar um modelo alternativo: a comunidade científica. Neste modelo, ao invés da democracia, a sociedade baseia-se no *consenso*. Ou seja: determinada teoria, quando aceita, é reconhecida por 100% da população como válida. No entanto, esta é uma concordância temporária, e o debate de ideias que refutem ou melhorem a teoria corrente é encorajado e visto como progresso. Mas ao invés de militância, discute-se através de raciocínio lógico, observação, experimentação e evidência. Como prova de que este modelo é bem sucedido, não é a toa que a comunidade científica é, muito provavelmente, a organização social que mais gerou benefícios ao resto da sociedade até hoje.


São visíveis os perigos da nossa atual estrutura democrática. E esses perigos baseiam-se predominantemente na falta de responsabilidade técnica e metodológica no que diz respeito ao interesse público. Religiões, crenças, ideologias devem ter o seu espaço. Mas bem longe das decisões que afetam 100% da população. É exatamente nessas decisões que precisamos de razão.

Opinion on Music

Simply put, this is my list of favorite albums all times.

  • Sargent Peppers Lonely Hearts Club Band (The Beatles)
  • White Album (The Beatles)
  • Abbey Road (The Beatles)
  • Revolver (The Beatles)
  • Magical Mistery Tour (The Beatles)
  • Let It Bleed (Rolling Stones)
  • Sticky Fingers (Rolling Stones)
  • Are You Experienced (Jimi Hendrix)
  • The Velvet Underground & Nico (Velvet Underground)
  • Led Zeppelin IV (Led Zeppelin)
  • The Dark Side Of The Moon (Pink Floyd)
  • The Wall (Pink Floyd)
  • Machine Head (Deep Purple)
  • A Night At The Opera (Queen)
  • The Who Sings My Generation (The Who)
  • Who’s Next (The Who)
  • London Calling (The Clash)
  • Unknown Pleasures (Joy Division)
  • Hatful Of Hollow (The Smiths)
  • Marquee Moon (Television)
  • Entertainment! (Gang Of Four)
  • Ocean Rain (Echo & The Bunnymen)
  • Definitely Maybe (Oasis)
  • What’s The Story Morning Glory (Oasis)
  • OK Computer (Radiohead)
  • The Great Escape (Blur)
  • Urban Hymns (Verve)
  • Tigermilk (Belle & Sebastian)
  • A Sétima Efervecência (Jupiter Macã)
  • White Blood Cells (White Stripes)
  • Elephant (White Stripes)
  • Turn On The Bright Lights (Interpol)
  • Funeral (The Arcade Fire)
  • Is This It (The Strokes)

Where do you see yourself in five years?

Frequently, when you find yourself in a situation like a job interview, or your company’s performance review, it’s pretty common to face a quite interesting question: Where do you see yourself in five years? In fact, I do believe that’s an interesting question – not based on its relevance, but actually based on its complete irrelevance.

By planning ahead to reach a goal, you also have to deal with the inherent risk of failure. From Production Engineering we learn that this risk is usually increased by three major factors: (a) the level of control you have over your environment variables, (b) the amount of variables you have to control and (c) the amount of time you have to keep those variables under control.

Turns out it’s virtually impossible to map all the possible variables in life given its subjective nature. There are so many unpredictable factors (like nature, human feelings, markets, death), that even planning in the short-term is reasonably risky. Therefore, it’s very likely that a five-year plan is fated to frustration, and nobody smart enough would think it’s a good idea.

Given that backtracking wrong decisions is frequently not an option, it feels more intelligent to adopt the Greedy Algorithm approach in life. The idea here is always to take the best possible option in short-term decisions based on facts, rather than speculation. So, instead of trying to forecast the future, you simply keep figuring out a good path gradually, facing almost no risk of frustration. Of course, the greedy approach does not necessarily lead to the optimal outcome. However, it is likely to lead to a good result, which can eventually be the optimal.

In summary, I believe to establish a five-year goal is not something a smart person would consider. Instead, my hypothesis is that planning short-term, down to earth – without big expectations – leads to a less frustrating, more light and enjoyable life. Having said that, I wonder if the people who ask us this question are, in reality, trying to trigger just this kind of thought about its irrelevance, or do they truly believe it’s a reasonable question?

Life can provide you wonderful surprises sometimes. I definitely prefer to stay open to them rather than stick to a bigger plan. Where do I see myself in five years? Here is a nice answer.

More Testing. Less Testers.

I believe the more we take QA and testing related activities as a full-time role, and the tester as a person, the more distant we are from being agile. Based on the common sense on the software development nature, old-fashioned testers are not exactly suitable to our reality. However, mostly because of cultural inheritance reasons, many companies keep pushing for the tester role while calling their process as agile.

Inspired by what Kent Beck mentioned about 10 years ago, testing, as well as development and business analysis are skill sets, rather than individual roles. Not only can I reach that conclusion by logical induction based on common knowledge, but also by empirical experience: the most successful teams I’ve seen, share the fact that people are multi-functional and self-managed, in a sense that every single member would be actively involved in a) helping the business to figure out and define requirements, b) directly work on the development of features, and c) directly work on testing related activities. As a consequence, people in this kind of team always grow in skill diversity through knowledge sharing. They tend to care more about the overall goal rather than their individual performance.

On the other hand, a number of companies (including well-known agile consultancies) have been failing on that regard in many ways. It’s pretty common in those companies the idea of QA, BA, dev individuals, working for entire projects strictly in their given role. Also, the idea is usually sold to most of their clients, persuaded to believe they need specialized people. Recruiting efforts also have been contributing to this kind of RUP-like culture, by conducting interview process by role and sometimes (even worse) by technology.

In contrast, I tend to believe whenever you have a QA, a BA, or a Dev person in your team you’re a big step behind from what a lean production system looks like. In addition to that, this role separation frequently generates a number of direct and indirect problems in the process, like communication overhead, bottlenecks, super-heros and blaming culture. (and it’s boring… who really likes to do the same kind of thing for weeks, months, years?)

Overall, I feel that most companies are heading the wrong direction on that and they could rather encourage people towards multi-functional skills, given the proven benefits it brings to the whole software business. It’s clear, though, that specific knowledge is definitely valuable. But for a more adaptable, self-managed, risk-less and (the most important) money saver team, that specific knowledge must be shared and leveraged by as many people as possible.

Besides that, there are still some strong cultural barriers to be overcome. In fact, we may agree it’s not really difficult for testers used to automation to evolve their dev skills as well as for devs to evolve their testing skills. Also, it’s not that hard for testers and devs to develop business analysis skills (that’s pretty common, actually). However, for manual testers and old-fashioned BA’s getting into technical knowledge can be a long way to go. Specially for the ones that are in the market for a long time and have already incorporated a wrong sense of maturity. Overcoming that kind of barrier is still more a personal will than anything else, though.

The Plain Old Function Call

During a design storm session one of these days, we got into a discussion on alternative approaches for an api interface. The main point in debate was basically the level of simplicity of each solution.

# first idea
choose('color', ['red', 'black', 'green'], 'ie7')

#second idea
choose('color').from('red', 'black', 'green').ignore('ie7').any

To set the context, the intention behind the hypothetical example above is to randomly select one of the options ('red' or 'black' or 'green') for a given aspect of the application ('color') in order to perform some sort of A/B testing. Besides that, we also want to prevent this thing from running in some specific browsers ('ie7' in this example).

Conceptually, the main difference between the two ideas is that the first one is based on a plain old function call with explicit ordered arguments, while the second one uses objects and method chaining (AKA Fluent Interface).

For some teammates, the first idea is the simpler one. They believe that approach describes more explicitly the api usage and is less complex to implement, since less data structures and language resources are required. It’s just a plain old function call, there is no magic in there. they say.

On the other hand, there was another group which was supporting the second idea. Their central argument was about readability: It is simpler because it just reads better. Additionally, they believe it eliminates any ambiguos interpretation on the last parameter role as well as in the statement side effect.

Well, even though both sides have their valid points, they are not really talking about the same kind of simplicity. Of course the first approach is simpler to implement because its grammar is restricted to limited set of very simple rules. And everybody pretty much knows how a function works in programming.

But turns out the second approach can be simpler on maintenance, since it gives more information about what’s going on without exposing implementation details. Also it requires less mental mapping between the computational representation and the real world thing (it’s closer to the natural language).


Overall, if our goal is to get something working as fast as we can using a very simple approach to create stuff, investing in old-fashioned function calls works fine. However, if the intention is to build something that would be easier and faster to understand and, consequently, maintain, the fluent approach sounds better.

Lastly, there is an important implication in that decision we should consider: the monetary cost. The Software Engineer history has shown us that maintenance is the most expensive phase of the software life-cycle. And we all know that a given piece of code is usually read several times more than it is written. So, if the maintenance is the real bottleneck, it sounds smart to adopt an attitude towards simpler maintenance.

Become a User

There is a single technique to get inside your users’ requirements that isn’t used often enough: become a user. Are you writing a system for the help desk? Spend a couple of days monitoring the phones with an experienced support person. Are you automating a manual stock control system? Work in the warehouse for a week. As well as giving you insight into how the system will really be used, you’d be amazed at how the request May I sit in for a week while you do your job? helps build trust and establishes a basis for communication with your users.


The requirements mining process is also the time to start to build a rapport with your user base, learning their expectations and hopes for the system you are building.

From The Pragmatic Programmer, by Andy Hunt & David Thomas.

Although I have had few opportunities to practice such technique, I strongly believe invest some time with the actual user can be way better than spend lots of hours in verbose and boring meetings with managers.

One Line If

I believe that every block inside an if/else statement should have one line length. Even if you have a simple three lines block logic, it could be named and extracted to a helper method, in order to improve readability and cleanness.

The more conditional blocks an algorithm has, the greater is its cyclomatic complexity, which means the number of possible paths that algorithm can follow. Then, when you’re reading and understanding a piece of code, everytime you face an if statement, you have to save the current flow in your mental stack and then start to read the conditional block till its end in order to figure out what that block is about. The bad news is that, as my friend Filipe Sabella says, unfortunately, you can store no more than seven things in your mental stack. Let’s take a look at the following code:

function guess(letter) {
  if(hiddenWord.reveal(letter)) {
    if(hiddenWord.isEverythingRevealed()) {
      alert('You win!');
  else {
    if(--chances == 0) {
      alert('You lose!');

The above Javascript function implements a guessing procedure in a Hangman game. You probably didn’t figure it out before to finish reading the entire code. That’s because you had to understand the implementation details in order to figure out the intention behind each conditional block. In the end of this process, you have probably named those blocks implicitly in your mind.

Now, let’s take the more external if/else blocks and give them names according to the intention behind them. Thinking about the Hangman game, when the player guess a letter, two things can happen:

  • If the hidden word has that letter, he did a hit;
  • Otherwise, he did a mistake.

So, let’s say the same thing using Javascript language instead of English:

function guess(letter) {

function hit() {
  if(hiddenWord.isEverythingRevealed()) {
    alert('You win!');

function mistake() {
  if(--chances == 0) {
    alert('You lose!');

The new version of the guess function has explicit names for each alternative computation. We can now read and understand it more quickly, in a single flow, without to store things in our mental stack. Observe that in this new version, the reader get the intention before to enter in the implementation details (actually, we don’t even need to know the implementation at this point).

We can go further and use the Javascript ternary conditional operator to make the guess function more straightforward.

function guess(letter) {
  hiddenWord.reveal(letter) ? hit() : mistake();

Pretty simple, don’t you think?

We can also keep going on this process and apply the same technique on the hit and mistake functions. So, let’s take the conditional blocks inside these functions and think about their underlying intentions in order to be able to give them proper names:

  • The hit function has a conditional block describing the behaviour the game should follow when the player wins the match;
  • The mistake function has a conditional block describing the behaviour the game should follow when the player has no more chances and then loses the game.

Using those names to represent the conditional blocks, we gonna achieve the following result:

function guess(letter) {
  hiddenWord.reveal(letter) ? hit() : mistake();

function hit() {

function mistake() {
  if(--chances == 0)

function win() {
  alert('You win!');

function lose() {
  alert('You lose!');

Now, as you can see, the whole code has only one-line ifs, and the intention behind each conditional path is explicitly named. As well as giving a better reading, we have improved the maintenance by giving a very clear place for each chunk of work. For instance, if you need to change the win behaviour, you just go directly to the win function and do your changes.


I believe that by using one-line ifs you can make your code more literate and descriptive, allowing readers get the overall picture at first and get deeper in details only if they need. Compare the above version of the whole code with the first single guess function. Note that in the last version the reading flows more naturally, as if the code was telling you a story.

Moreover, this approach makes software development cheaper and programmers more productive. Given that the major cost is software development is the maintenance, reading and understanding code in a more effective way could give you significative financial improvements.

Finally, an additional award one-line ifs give us which I love is, for languages based on C syntax (like Java, Javascript, and C#), you don’t need to use curly braces. As well as helping to reduce the syntax noise (and give your code a Python flavour), it also makes the code more aesthetic and comfortable to the reader eyes.

Don't use XML: build a DSL instead

Knowing about computer languages and language technology such as ANTLR will make your coding life much easier. Don’t be afraid to build a human-readable configuration file (I implore everyone to please stop using XML as a human interface!) or to build domain specific languages to make yourself more efficient. Designing new languages, when appropriate, is the hallmark of a sophisticated developer.

Terence Parr, in his ANTLR book.

To develop an external DSL can be fun if you have a great tool like ANTLR in hands.