Soronthar' Book of Days

Why is almost every conventional wisdom wrong?

2012-01-13T21:50:22Z

This seemingly inocent question on twitter got me thinking a lot. 'Conventional Wisdom' and 'Common Sense' are often quoted to reject a novel idea, because we all know they cannot be wrong, right?
]]>
'Conventional Wisdom' is built the same way as traditions: over time, as a recollection of people experiences. And the same as traditions, they outlive their originator until nobody that quotes it knows the why's anymore. And that is the problem: conventional wisdom used to be true for someone, but some things are lost and it failed to evolve with time.

For example, it used to be Conventional Wisdom that if someone started coughing blood, dead would come pretty soon. Today, Conventional Wisdom says to bring the person to the hospital and will be recovered in no time ( or so we hope).

Another more radical example: 20 years ago, Conventional Wisdom said that cancer was a death sentence. Today, thanksfuly that is not true anymore.

Outside the realm of medicine, after the industrial revolution it was Conventional Wisdom that a worker should be busy 100% of the time. This belief have carried over the modern times. It used to make sense at the time for some factories, because demand was greather that the production capacity. It ceased to make sense as soon as the production capacity grew, surpacing the demand. But the Conventional Wisdom haven't catched up with modern times.

Does this mean that we should disregard 'Conventional Wisdom' as always wrong? I don't think so. We should understand the why's behind it, we may even learn something that may help us later on. And, who knows, it may even be right.

A here you have the tweets that inspired this post:

RT @tobi: Why is almost every conventional wisdom wrong?
-- Yves Hanoulle (@YvesHanoulle) Jan 8, 2012

@soronthar @tobi I don't agree, I think a lot of conventional wisdom never "used to be right" in all circumstances
-- Yves Hanoulle (@YvesHanoulle) Jan 9, 2012

(with thanks to@YvesHanoulle and @tobi for the though provoking tweet)

A case of Blog Spam

2011-08-27T01:14:09Z

This blog has been recently the target of a blog-spam attack. I'm shutting down the comments for all posts until further notice.

UPDATE: Futher notice :) Blog-spam attack contained, I'm reopening the comments again.

What does Agile means? (My point of view)

2010-02-25T15:30:30Z

As I said somewhere else in this site, I'm passionate when it comes to programming, seeing it as a craft to be perfected. It is no surprise, then, that I became a confessed Agilist.

Something happened today that made me think about what I think is the meaning to be Agile. The quick answer would be "To value the Agile Manifesto", but somehow I felt that there is more to Agile than that. This is the end result of my musings

]]>
Being Agile means to embrace uncertainty, accept change. It means to work on what is actually needed, to produce actual value. It is not measured by the number of practices being followed, or by tagging your process with a methodology. It can be measured by how much we value the manifesto, but the best measure should be the smiles in our users and our team.

Being Agile is more than having a tag or following a procedure. It is a way of thinking, a professional lifestyle, that must be ingrained in the core of the corporate culture, from the C level to the developers, including all the departments.

To become Agile you must be ready to break some paradigms, to challenge the status quo.

Are you ready?

Freezing specs, Agility and the lack of trust

2009-10-06T14:10:13Z

Johanna Rothman, in in her product development blog talks about when a spec should freeze. She basically said "specs never freeze, people communicate about what they want all the time".

What caught my eye was one commenter that said "There is always a point at which the spec must freeze; otherwise, either quality will suffer in some way, or the wrong functionality may not be delivered". That's kind of true, but the problem is not with the lack of spec freeze.
]]>
One thing about freezing specs is very unusual: it is one of the very uncommon points where all the actors involved agree that must be done. Why? Because it adds an illusion of predictability (we know what is going to be delivered way in advance), and is a shield to deflect blame. This blame deflection eagerness can make the act of changing the spec a very expensive process. The irony is that by protecting themselves, they are increasing the chances of failure.

In my experience, assuming that the team is able to deliver whatever is on the spec, the problems is not the act changing of the spec that brings the problem, but the lack of focus when changing it and the unwillingness to change the schedule.

If the team has the golden pair of good Product Owner and Project Manager, both will make sure that the changes to the spec are really needed and will negotiate any change in the scope.

If all the actors trust each other, and all the changes to specs and schedule are visible to everyone, there is no need to freeze the spec.

I have seen all scenarios: I had an spec that was "open" for about 6 months. It grew in scope. We even rewrote complete parts of already implemented the functionalities (early stories) because the business side discovered that they got it wrong the first time. And it was ok. The business side was deligthed with the end result.

On the other (darker) side, I had a spec frozen that covered a 3 month development. We required 2 more requirements after that (frozen, of course) to get to what the business needed. It took us 6 months, we delivered what was on the spec, by the letter. But the business was not deligthed.

And finally, I witnessed (as an outsider, thanks God) specs changing weekly, in an uncontrolled way, adding scope and changing functions that where implemented the week before in a radical way... without changing the schedule.

In short, trust each other. Then you won't need a spec freeze, only a "we have enough to start working" flag on the spec.

Fear and Safety

2009-06-06T15:29:41Z

Again, another quote from Slack:

"Paradoxically, the fear of breaking your neck (translation in corporate terms: losing your job) does not make changes impossible. It's a much more insidious kind of fear that interferes with change: The fear of mockery. If you want to make change in your organization utterly impossible, try mocking people as they struggle with the new, unfamiliar ways you have just urged upon them. There is no surer way to stop essential change dead."

Go and Buy the book if you haven't already.

The Divine Gift (of Fear)

2009-05-30T17:31:29Z

That is a subtitle in chapter 13 of Tom DeMarco´s excellent book Slack, dedicated to the Culture of Fear in our organizations.
These are the characteristics of an organization with the Culture of Fear that are listed in the book:

It is not safe to say certain things. And truth is no excuse for saying them.
In fact, being right in your doubts proved that you must be the reason that the fondest wishes of those above you did not come true.
Goals are set so aggresively that there is virtually no chance of achieving them.
Power is allowed to trump common sense.
Anyone can be abused and abased for a failure to knuckle under.
The people that are fired are, on average, more competent than the people who aren´t.
The surviving managers are a particulary angry lot. Everyone is terrified of crossing them.

Tom finish that section with the following:
"I hope that as you read these points you're inclined to think thy present a truly extreme picture. I hope this, since it suggests that yours is not a Culture of Fear organization. (If the portrait I'have drawn does not seem extreme to you, you have my sympathies.)"

So, if these points target close to home, do yourself a favor and buy the book. It is a real eye-opener.

Do not confuse "duty" with what other people expect of you

2009-02-17T04:36:38Z

That phrase started what may be one of the most life-changing fragments I ever read. It is from Robert Heinlein book "Time Enough for Love".
]]> Here is the whole paragraph:

Do not confuse "duty" with what other people expect of you; they are utterly different.

Duty is a debt you owe to yourself to fulfill obligations you have assumed voluntarily. Paying that debt can entail anything from years of patient work to instant willingness to die. Difficult it may be, but the reward is self-respect.

But there is no reward at all for doing what other people expect of you, and to do so is not merely difficult, but impossible. It is easier to deal with a footpad [a thief] than it is to deal with a leech who wants "just a few minutes of your time, please - this won't take long"... Time is your total capital, and the minutes of your life are painfully few. If you allow yourself to fall into the vice of agreeing to such requests, they quickly snowball to the point where these parasites will use up 100 percent of your time - and squawk for more!

So learn to say no - and to be rude about it when necessary.

Otherwise you will not have time to carry out your duty, or to do your own work, and certainly no time for love and happiness. The termites will nibble away your life and leave none of it for you.

This rule does not mean that you must not do a favor for a friend, or even a stranger. But let the choice be yours. Don't do it because it is "expected" of you.

There you go. Think about it. May it helps you to have a better life.

More Heinlein quotes can be found here

Crunch time

2008-04-22T05:48:50Z

I have been in a very unique position, seeing crunches that worked and crunches that didn't on the same team (same people, same project).

Those that didn't work, started with the management saying (nearly at the end of the plan) "we are late, crunch time". People felt that things were poorly planned, deadlines where imposed from above, and all those things developers think at those times. End result: we made the dates... with a lot of effort, a lot of "burn down", and alot of defects.

Later on the same project but different release, priorities changed, new requirements came, and the deadline was no longer "achievable", We negotiated a new reduced scope, but even the reduced scope was not possible under normal circumstances (scope could not be reduced further because monetary penalties for the client were at stake). Result? We told that to the team, and curiously enough the TEAM declared "cruch time, let's hit that deadline!". High morale, High energy. One month later, we made it. With a lot less errors than the last time.

Yes, crunches work some times. The interesting thing is identifying why those "some times" it works.

My guess?

When management declares "crunch time", and the team feels that the plan was impossible to begin with and that it was a known fact since the beginning, the crunch will fail (low morale, low productivity, etc,etc,etc). But if the team feels that the plan was achievable, and that what happens is just a roadblock in an otherwise clean road, they will "do their best" to hit the deadline anyway (programmers are stubborn optimistic beasts). Management must just take care that no one burns out due to overwork, the sense of purpose will give the morale and energy needed.

So, at the end, if you manage your project correctly and "crunch time" is due to an unforseen cause the team will help you to hit the deadline. If you mismanaged the project, the team may save you once or twice. After that, they lose trust and will eventually leave.

Good luck, and Happy Blogging!

Another proof that I'm a geek

2007-12-21T13:19:46Z

I stumbled upon a site with some fun quizzes. I could not resist, and did the "How Geek Are You" (hint: if you want to score high in this test, you're a geek).

So, here is the result:

94% Geek
See my other quiz results here

Overcoming Bloggers Block

2007-11-25T22:03:28Z

Here I am, sunday afternoon, trying very hard to produce some posts for the blogs I created, to fulfill my self-made promise to blog something meaningful every other day.

Of course, my mind went blank. Nothing regarding Java, or OOD (for the tech blog), no history from my role-playing past (for the RPG blog), nothing in general for this blog. I was suffering what is called "Writer's Block" or "Blank Page Syndrome"

This is very ironic, given that I'm currently teaching a course on creative thinking and idea generation.

That thought was my salvation.
]]> Jerry Weinberg (of Secrets of Consulting fame) saying "Writter's block is an idiotic idea".

So, if I'm not blocked, why is that I cannot write a blog post? For the very same reason that a lot of people cannot generate ideas: I was trying to find the "right post" at the first pass. Trying to model something "perfect" at the first run. This is one of the main killers of creativity.

So, how did I end up with a blog post? I used one of the techniques I teach. It's a very simple one, and it's used to warm up the brain and trigger the unconscious process of linking facts: Write up a phrase. Any phrase. Then write whatever comes to your mind. Continue doing this until you have enough material to refine a blog post. By that time, your brain will be on fire, and you should be 'on the flow'.

In general, this technique can be used to generate any kind of written material. Just follow these steps:

Write up a phrase. Any phrase.
Write some other phrases (ideas) related to the original one, as many as your brain gives you. Even those that you think are 'idiotic', 'bad' or 'not related'.
Try to link these ideas, and to build some paragraphs with them. As you go, write down if you need to find a reference, or to validate a fact, or to insert a link, but don't stop the flow just yet.
When you think you're "done", take another pass to find that missing reference or link, and validate the facts. If another idea pops up, write it down.
Repeat the above steps until either you run out of ideas, or you feel satisfied with the length of the writing.
Read the whole writing again. Refine it until you feel satisfied with the result.

My first phrase? "I cannot produce a blog post for today". The end result, you're reading it.

Happy Blogging

Newbie ScribeFire Tip

2007-11-24T17:09:04Z

The first post I made with ScribeFire, had "Powere by ScribeFire" appended at the end. I wanted to turn that down, so I started to browse the site. In one Comment for the release note i found this tip:

To disable the "Powered by ScribeFire" message, click on the << simbol at the top left of the ScribeFire panel, go to "Settings" and uncheck the "Automatically insert Powered by ScribeFire" setting.

Happy blogging.

Time for an introduction: Who am i?

2007-11-14T22:59:30Z

My (real) name is Rafael Alvarez. I was born July 8, 1975 in Caracas, Venezuela.

When I was really young (around 5 or 6, IIRC) I wanted to me a Chemist, like my Mother and my Grandfather. That was until my mother gave me a Commodore Vic-20 as a present when I was 7... From that very time I knew what my future was: Programming. Latter I broaden my views and put myself a higher goal, to be a Software Developer, so I could not only bend the computer to my will and create beauty from nothingless but to create complexity through simplicity.

I got a degree in Computer Engineering at Universidad Simón Bolívar (Caracas, Venezuela) with minors in Computer Language Theory (Focus on Virtual Machines and static optimizations like Partial Evaluation), Artificial Intelligence (focus on Planning and rule-based systems) and Benchmarking (focus on Web-based Applications)

According to the Jung-Myers-Briggs test, I'm a INTJ person. It describes me pretty well, so perhaps they're not that wrong.

I have been always passionate about programming: I see it more as a craft than as a science.

Over the years, I have taken several online tests for fun, you can see the results here

To Blog or Not To Blog

2007-11-07T03:30:26Z

Some time ago, when I first read about weblogs/blogs I thought "Why on earth would someone want to keep one?". Now, after reading blog after blog, I found the answer: You can put your thought there, ideas too small or irrelevant to form a paper, but relevant enough so you want to write or tell them.

So, this is it. My collection of ideas, spread across three blogs (Personal, Technology and Pen-and-Paper RPG).

If at least one other people like what can be found here, I'll feel satisfied.

... And thus, a Blog was born

2007-11-04T19:07:17Z

Over the years I have toyed with several free hosting providers and blogs provider. Several times I have lost data due to the service trashing, getting acquired by a major player, going out of business or removing my account due to 30 days of inactivity without previous notice.

So, I bite the bullet and decided to take command of my information and put it in a place I know will be secure and reliable.

This is a "stub" post, as soon as I learn the internals of MT I'll start creating my personal website.

In the meantime, these are the blogs I'll be maintaining:

Diary of Pyros, an Elder Tremere
RPG Stories
Software Development Diary

I hope you all enjoy them