Open eyes Working brain

We live in times of complexity, and even though neat technologies and elegant software can be found at times, the market is still definitely dominated by absurdly heavy solutions. Enterprise is imploding and a wind of change towards more sustainable approaches is blowing all around us, yet the mainstream scene is comparatively stagnant and all the pain inflicted to people is not really causing the deserved rebellion.

Why is that? Why when confronted by the possibility of rewriting their untestable bloatware, customer’s reply is almost always invariably “No, we don’t need it. We’ll just have to fix known bugs and add a couple of features, because right as it is, the software works ok…”?. What does “works ok” really mean? In my experience, it translates roughly to “The software does not physically blows up our office, it does some of the things we need to do, and over the years our employees have developed a thick skin against all the nuisances and a baggage of manual tricks, passed on by mouth, to get the rest of the work done anyway. Oh, and we already paid a lot for it”.

Recently, i got a taste of this mindset myself, when i booked online 2 tickets to Avatar at the local cineplex

“Hello this is my reservation code”

“Sorry Mr, those seats are reserved”

“Sure, by me”

“No, actually by others”

“What? see, i made this online reservation…”

“I see, but we take reservations both online and by phone, sometimes they overlap and phone is given priority”

“Overlap?! No trust me, i am a programmer, overlapping reservations are not supposed to happen, because your system has to take care”

“Oh, but evidently it doesn’t”

“WTF?!?!”

“Please, don’t get mad, i am gonna give you other seats. Today is not even bad. You should see how many angry people we must manage during christmas holidays when all movies are sold out!”.

Now, given that reservation means “An arrangement by which accommodations are secured in advance”, how would you rate a reservation system that does not guarantee secure accommodations? Like a fish unable to breathe underwater, yet they live with it, and this takes me to the point.

First, humans are best when it comes to adaptation. That means we naturally adapt to pain so that we don’t feel so bad, and adapt to pleasure so that we don’t feel so good. Perception of any external stimulus in the end comes to balance. Barry Schwartz in the Paradox of Choice says:

respondents were asked to rate their happiness on a 5-point scale. Some of them had won between $50,000 and $1 million in state lotteries within the last year. Others had become paraplegic or quadriplegic as a result of accidents. Not surprisingly, the lottery winners were happier than those who had become paralyzed. What is surprising, though, is that the lottery winners were no happier than people in general. And what is even more surprising is that the accident victims, while somewhat less happy than people in general, still judged themselves to be happy.

Second, humans are also very bad at admitting sunk costs. The idea of having spent money on something not worth is the ultimate inconvenient truth. Again Barry

Aversion to losses also leads people to be sensitive to what are called “sunk costs.” Imagine having a $50 ticket to a basketball game being played an hour’s drive away. Just before the game there’s a big snowstorm—do you still want to go? Economists would tell us that the way to assess a situation like this is to think about the future, not the past. The $50 is already spent; it’s “sunk” and can’t be recovered. What matters is whether you’ll feel better safe and warm at home, watching the game on TV, or slogging through the snow on treacherous roads to see the game in person. That’s all that should matter. But it isn’t all that matters. To stay home is to incur a loss of $50, and people hate losses, so they drag themselves out to the game.

Third, as brilliantly pointed out by Ryan Brush’s “Code is Design” in 97 Things Every Programmer Should Know and by Gabriele’s “Waterfall Pitfall #1″ (italian), uninformed most people understand software construction in terms of the better known building construction. Now, since programs are built out of bytes (not bricks), which are practically nothing, using mind (not excavators), which has no physical constraints, actual construction must be very cheap. This gives them the false hope of having an easy exit strategy at their disposal: fixing the software when an emergency comes up. Would they wait for a defective bridge to show the first cracks before attempting to fix it? Their unconstrained minds seem to be unable to realize that story construction aka book writing, built out of words, might represent a more fitting comparison and that The Divine Comedy took Dante, a renowned genius, more than ten years to finish.

Last but not least, mainstream has made a really good job at covering mistakes of incompetent programmers. From the almost sandboxed life cycle of a php script, to the rigid syntax of java and its self-correcting IDEs, to the plethora of useless certifications, great efforts have been devoted to make any primate with opposable thumbs able to program with very limited competence. Many and cheap, that’s how economy of scale is supposed to fail work, and that’s how we got this horde of unprofessional programmers sacking the best projects.

All of these points help to explain proliferation of crappy software. Maybe, they get it from some body rental which pays more for advertising than for the army of juniors that actually does the job. At the beginning it hurts, but they spent good money and cannot afford to accept failure, so lies are told and more time and money are invested to improve the situation. Then workarounds, albeit inefficient, come and direct suffering somehow decreases. Eventually, the pile of workarounds becomes part of company culture, and all is back to balance: the software starts working ok.

Unfortunately, this means that the quest for better software workflows can hardly come out of necessity, it must come out of vision, and vision takes inspiration fed to working brains then time for the masses to catch up. With Universe hopefully taking care of latter two, i like to think we, professional programmers, are those in charge of the former.

During my holidays, on a beautiful spot by the river, i had the opportunity to finish The Talent Code. This nice book brings empirical evidence and scientific foundations to something i have felt for quite some time:
Talent isn’t born, it’s grown.

Actually this has been something known to humanity for at least a century and it’s best explained by this quote from Thomas Edison:

Genius is 1% inspiration and 99% perspiration

The point is that becoming great at something is largely a matter of the amount and quality of practice one does. While God given talent can only boost this process, but it’s by no means the most influential factor.

About the amount of practice, there’s the old “Ten Years Rule” and a more refined study by Anders Ericsson who sets in 10000 hours of committed practice the time taken to achieve expert level. From the Pomodoro Technique, we know one can do about 5 hours/day of efficient work (10 pomodoros). That means 5 years and a half, 5 hours every day of hard work could be a good guess to the question “How long does it take?”.

About the quality of practice, the book calls the good one “deep practice”

working on technique, seeking constant critical feedback and focusing ruthlessly on shoring up weaknesses

So deep practice has a pretty simple recipe:

• practice just beyond your current ability
• focus on errors
• fix them
• repeat

Basically, it’s tenacious, steady continuous improvement, so it’s not surprising Kaizen is mentioned in the book.

In the end, we are left with two news: one bad, one awesome. The bad one is if you fail to reach master level in a discipline you care of, there’s no one to blame but yourself. Sadly, you got to take responsibility even for that. But the awesome news is you can really become what you want be. Just keep working.

Let’s close with this sweet advice from great italian poet Giovanni Papini

Chiunque, purché sappia chiaramente cosa vuol divenire e non perda un solo secondo della sua vita, può issarsi al livello di coloro che dettano le leggi alle cose e che creano vite più degne. (Da “Diventar Genio” – 1912)

and my rough translation

Anyone, as long as he clearly knows what he wants to become and doesn’t waste a single second of his life, can raise himself to the level of those who lay down the law of things and create more worthy lives (From “Becoming Genius” – 1912)

The more i read about psychology the more i feel it’s compelling knowledge to anyone especially in the software business.

The Paradox of Choice by Barry Schwartz is enlightening on this respect. Humans inherently crave control, autonomy, self determination and so choices which are natural means to express this essential demand of freedom. Yet, humans used to have simple lives with limited amount of choices. Now, in these days of exponential growth and exploding options, they just can’t cope anymore. They’re overwhelmed by escalating possibilities in all fields of life ending up paralyzed, frustrated, dissatisfied if not plain depressed.

Schwartz comes to the conclusion that, to relieve distress, they have to fight back their inner impulse and learn to accept some constraints are good, that simplicity, more often than not, can be the golden path to well-being. In a later talk at Google, he goes as far as pointing out that software/product makers should embrace libertarian paternalism, which in a nutshell means: give them choices but also apply soft contraints to ease their path to “good” decisions. Those that will probably make them better.

Greek Diners in New York City. Their menus are about a thousand pages. There is no dish anyone has ever eaten it isn’t somewhere on those menus and tucked in the front cover of the menu there’s a little piece of paper with “today’s specials” – four or five items. Inadvertently you create an insoluble problem by giving people 10,000 things to choose from and then you solve it for them by giving them today’s specials and people are driven to choose, take your advice, take your recommendation.

This sheds new light on the company vs customer, simple vs full featured software picture i’m still trying to figure out. As Don Norman puts it “People want the features” and “Features win over simplicity” and as Joel Spolsky notices “With six years of experience running my own software company I can tell you that nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features. Nothing.”. That’s obvious. That’s what people naturally do, the way society drives them to do: Manifest control by claiming more options, more variety.

But then there’s the other side of the coin. Many of them will reject using such software or at least defend themselves by restricting to very basic usage and, in the end, they’ll feel bad about it. Empirical evidence is already there in stats about unused features. People also seem to feel it as the great success of “for dummies” books and simplicity buzzword in advertising underline. Using Schwartz words:

A majority of people want more control over the details of their lives, but a majority of people also want to simplify their lives. the paradox of our times.

Customers bombarded by never ending stream of choices and responsabilities are to me much like children in need of a good parent. So companies as anyone really or virtually in charge of other human beings are subjected to the same old ethical question:

Do we care for us or for them?

Are we in the business of making money or in the business of making happy customers?

If you like me value the latter, then maybe, it’s time to start acting as a lovely father who takes best choices for his offspring but as they grow safe, empower them day by day. Instead if money drives your actions, i just got one more question for you:

Do you think such economy is REALLY sustainable?

I’ve finished reading “Perfect Software and other illusions about testing” by Gerald Weinberg. A short, easy to read, low technical book, full of anecdotes which drive you through illusions and challenges of software testing. The nice thing is when the author of a small well written book about testing happens to be the father of software testing himself, epiphany becomes possible.

But beware developers, that’s not about automated software testing, it’s from perspective of the person who leads the testing process. One who knows the true nature of testing and answers to the big questions:

What’s testing? Why do we test?

These naive answers particularly stuck to me:

1. Humans are irrational, emotional, imperfect thinkers
2. Humans have to make decisions (ie. about software)
3. Those decisions are risky (because we make mistakes)
4. Testing is gathering information to reduce risk

So testing is about taking less risky, more informed decisions.

Also, by this definition, testing is much bigger than what you do in front of your computer:

…let me tell you about a job i turned down at a large insurance company before taking the job here. It paid more money, but it failed The White Glove Test. I asked my prospective manager whether the company used a defined testing process for its testers. ‘Oh, yes,’ he said. ‘All one-hundred-fifty use the defined test process.’ I then asked him what that process was, and he said, ‘It’s defined in our testing process manual, which is kept with the CMM library.’ I next asked him if it was the only copy. He said yes, so I asked him to show me the library. In the library, i put on my white glove and dragged my finger along the top ot the Testing Process Manual. I came away with a quarter-inch of dust. Was i testing? It gave me an estimate of how long it had been since any of the company’s one-hundred-fifty testers touched the manual. I performed a meta-test of the testing organization. I decided i didn’t want to work there.

In other words

The number one testing tool is not the computer, but the human brain in conjunction with eyes, ears, and other sense organs.

Another interesting point is that information you get by testing is neutral, which means it’s not implicitly good or bad until it impacts on us, emotional thinkers, bringing new reactions. If you want to properly assess and report information from and to others, you have to understand how humans think and behave…ehm… let me search wikipedia:

Psychology is an academic and applied discipline involving the scientific study of human mental functions and behavior.

Ouch, so as weird as it can seem, testing is also about psychology. It’s about understanding what others really mean and make them understand what you mean, because information without proper communication can turn out useless…

People listen selectively. A tester may say, “At the current rate we’re finding and fixing bugs, there’s very little chance that we can ship by the first of September.” The project manager whose job is on the line is likely to hear, “Blah blah blah blah we can ship by the first of September.” Only give and accept dates in written form.

I definitely recommend this reading for anyone who wants to really understand testing. I’m leaving with some more gems.

Major Testing Fallacies

• The Blaming Fallacy: The more time and effort someone spends looking for someone else to blame for a problem, the less the chance of solving the problem.
• The Exhaustive Testing Fallacy: The only real kind of exhaustive testing is when the tester is too exhausted to continue.
• The Testing-Produces-Quality Fallacy: Quality is a product of the entire development process. Poor testing can lead to poor quality, but good testing won’t lead to good quality unless all other parts of the process are performed properly.
• The Decomposition Fallacy: Test the parts and you’ve tested the whole.
• The Composition Fallacy: Test the whole and you’ve tested the parts.