Soronthar' Book of Days

My Journey with Jerry Weinberg

2013-02-27T20:04:49Z

It started from a tweet from @andreachiou

Anyone out there who feels that @jerryweinberg 's books and career had a material positive impact on their own career? (Yeah, rhetorical :-)
-- Andrea Chiou (@andreachiou) February 26, 2013

I went down the memory lane, to the time I first heard of a guy named Gerald M. Weinberg from the book "Are your Lights On?". Up until that point, I was a rabid "Solution Seeker", jumping at every opportunity to propose solutions to problems. After that book, I was changed. I realized that it is more important to actually solve the root problem than to propose solutions. I became a "Problem Solver", who started to treat the illness instead of treating the symptoms.

And then, "Secrets of Consulting" happened.

]]> That book opened a whole new world to me. The Orange Juice Rule, Rudy's Rutabaga Rule, The three laws of consulting, all of them simple principles with catchy names so I would never forget them. I still remember from that book the most valuable lesson about "leading" people: "You can make buffaloes go anywhere, as long as they want to go there". Even the "bibliography" section is worth reading (and the books listed, useful). My toolbox grew, my opinion on some things changed, and overall I grew professionally.

Shortly after I bought the series that has brought more satisfaction and "stress" to my life than any other book: the "Quality Software Management" series. With them I started to understand how systems work (specially people systems), but most importantly I discover what congruency is, and what it is important to be congruent. It sank on me that we are all different, and why, and how understanding those differences make us better persons. It taught me to stop optimizing locally, and to look at the big picture for the long term benefit. It was my first look at the work of Virginia Satir.

"More Secrets of Consulting" gave me some useful tools to understand me, understand others and increase Self-esteem. Tools that I'm still learning how to use, a process I think will never end. Then "Psycology of a Computer Programmer" helped me understand why we are the way we are, and why it is difficult for other people to work with us. "Becoming a Technical Leader" gave me insights and advice on how to become one.

"Rethinking System Analysis and Design" taught me that most of the time, technology is neither the problem or the answer, and no "system" exist in isolation from the rest of the organization and their people, that there were good reasons at the time to do the things the way they did and that we technologist should not refuse to learn the "business" side of things.

"Weinberg on Writting: The Fieldstone method" changed both the way I write and the way I read. I joke sometimes that now I always see "stones" everywhere.

I discovered his fiction work and it appealed to the geek side of me. I really enjoyed them all, being the AREMAC Project, Freshman Murder and First Stringers my favorites.

The climax of my journey was the AYE conference of 2011 when I got to meet the man, among other authors that I deeply respect and admire (Johanna Rothman, Don Gray and Esther Derby). Words are not enough to describe the learning experience at that conference. I was a bit sad when I heard that AYE 2012 was the last one.

I revisit his book from time to time, discovering new things and rediscovering old things on each read. I talk about them all the time. The truth is that if you have know me for more than a year, chances are that I mentioned Jerry Weinberg to you at least once.

If I had to summarize the learnings in my journey with Jerry Weinberg, I just couldn't. At the very core of what Jerry have taught me all these years are things that I already knew. I was changed as a person anyway, not because I learned things like "to help others you must help yourself first" but because I learned tools (like the Rutabaga Rule, the concept of congruence, the mirror and telescope) that helped me help me, then learned tools to understand others, and tools to help them if they want. It has been a slow and long process, but somehow satisfying.

I'm sure the journey is far from over. I'm yet to read "Perfect Software" and "Experiential Learning", and he keeps producing knowledge in his blog and tweets.

I you want to start your own journey with Jerry, head to his site, browse his books and pick the one that appeals you most. I'm sure you won't regret it.

Story Points as an Abstraction for Estimation

2012-08-28T16:14:09Z

Story Points have been one of the favorite method of estimation in the Agile circles (even if there is a group that ditched them altogether in favor of micro-sizing or continuous flow). But somehow they are a concept that is difficult to grasp to some, specially those entrenched in the Gantt field. The truth is that planning with Story Points is no much different than planning in hours, if we were planning properly (ie, using ranges or estimates, adding buffers to the critical chain and at the end of the proyect, etc,etc,etc).
]]> Story Points provide a nice abstraction over hours/days, because it takes into account several things:

Estimates, at the time the Story Points are decided, may have a margin of error of as much as 100% (well, actually the margin would be +/- 50%)*. That's why we say that all 3 point story are roughly the same, even of one takes 1 day and other take 2 days. If one 3 point story takes1 day and another take 5 days then something went wrong, either in the estimation or in the execution.
When estimating in hours, a buffer needs to be put at the end of the plan just in case. By estimating in Story Points, the buffer is created when setting the initial Velocity of the team, and then adjusted on each iteration.
Speed of team members are different. A 3 points story can be implemented in 1 day or 2 days depending on the people involved.

A 3 person team saying "we can deliver 12 story points per 2 week iteration", is the same as if they were saying "we can deliver these features that are estimated for a total of 150 hours work in 80 hours of duration, leaving 90 hours of buffer in case that the estimates are wrong or some problem comes along the way".

At the end, estimating in Story Points and estimating in hours has exactly the same basis: Both depends on Gut Feeling. But it is easier to sell Velocity than to sell buffers and estimates with confidence range. And it is a lot easier to think in the size of the task ("hmm, this may involve changing 3 modules, but the change is simple") than to think in the time to execute it ("hmm, this may take about a week").

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.