SharedBook: On Demand

Dog food to brag about :-)

If you have followed my blog posts, you have probably noticed that I am a great believer in the “Eat Your Own Dog Food” philosophy. I even found that sometimes dog food can be tasty.

Well, I have just received today in the mail another of my dog food experiments: a beautiful book I created including some articles, photos and stories and even my favorite inspirational quotes documenting my half-Ironman experience.

And I love it! I am so happy with it, and with the fabulous photos of me with my family and friends and all the people who were with me throughout this experience. I just can’t wait to show it off, and brag about it.

This is a completely new experience for me. When was the last time you bragged about dog food?

The Magic Formula for the Right Balance

Lately I’ve been reading about some new methodologies that claim QA resources should be reduced to a minimum.

These so called “advanced” methodologies, mainly related to Web 2.0, argue that although QA is a “necessary evil,” reducing it will allow the development process to be shorter and more dynamic and flexible, giving companies greater strength in the market.

IMHO these progressive approaches have progressed a bit too much. It seems to me they do not take into consideration all the risks involved in such an act.

They do present one proposed solution – developers should become more responsible for their code. They should strive to write without bugs and perform the minimal necessary tests by themselves.

This solution totally contradicts the main purpose of this approach – flexibility, dynamics and quickness – it will take a developer twice as much time to develop a new feature if he tries to fulfill the above tasks, and the development process will become even more complicated and slower as a result.

Although no one knows the feature better than the person who wrote it, a QA person is a trained professional and will be able to produce twice the productivity in half the time.

Our basic assumption is that not all bugs will be found. Therefore QA’s goal is to find as many bugs as possible in a designated time and make sure every bug gets the proper attention.

But as you reduce the QA effort, more and more critical bugs will slip through and find their way into the production site. Those bugs will never go away. They are only hiding, lurking somewhere in the system waiting for the first customer to find them. Such bugs have a tendency to reveal themselves at the worst place and always at the worst time.

Critical bugs need to be fixed at any stage, and it is a known fact that the later you find the bug, the more painful and expensive it will be to fix it.

My experience has shown me that whatever you save in QA you will pay in tech support, and big time. The equation is simple – the less QA you have, the more tech support you will need, and as a QA & tech support manager, I can see both sides of the equation very clearly.

Shorter QA time and effort will enable end users to enjoy a more dynamic and enhanced application BUT … a customer will always be less frustrated by an absent feature than by one that doesn’t work.

In conclusion, no matter how much QA time and effort you invest, you will always need tech support. But our main goal is to find the magic formulas that enable us to balance the equation between the two.

Risk Management and Cycling

"If you can't afford to take a risk, then you can't afford to compete." (Lee Iacocca, former Chrysler chairman)

If you want to succeed in the business world and be able to compete better, you have to go faster. This we all know. And if you want to go faster – you have to take risks. But you have to take risks cautiously; this is what is known as risk management. You go out and dare, and take the risk, only after making sure that if something goes wrong – you will be able to handle it.

If you’ve read some of my blog posts you probably know that I am hooked on cycling. I love the speed, the sense of freedom, the challenges, pushing you to the limit over and over again. And I also find great similarities between high tech management and cycling. Obviously, in cycling, if you want to compete better you have to go faster. Going faster on the bike requires strength and… you guessed it: taking risks. I learned this lesson last week.

We were doing another technique session. This time I learned how to brake properly on the bike. In order to be able to brake properly, without sliding and falling, you have to think about your body posture, apply your rear brake and front brake in perfect timing, and practice it over and over again, until you get it right.

Much to my surprise, the next time I had to go downhill, I went much faster than usual. Why? Because this time I dared taking the risk, after all, I knew that if something went wrong – I would be able to handle it. I would be able to brake real fast, without losing control of the bike.

Once again (you can read about my previous experience here: Want to Go Faster? Find Your Weakest Link), I discovered that the same rules apply to my favorite hobby and to the high tech world: Want to go faster? Do proper risk management.

And while I am playing with quotes, here is another one of my favorite quotes that applies to both bike races and high tech management:

"Only those who dare to fail greatly can ever achieve greatly." (Robert F. Kennedy)

Think about this the next time you are about to take a risk. I sure will.

Another Year of the Snake

In a blog post earlier this year I posted about Python's growing popularity in 2007. Since then the following events have unfolded:

• Last month Sun announced that they were hiring two key Python developers -  Ted Leung, an Apache Software Foundation (ASF) member and long-time Python developer at the Open Source Applications Foundation (OSAF), and Frank Wierzbicki, lead implementer of the Jython project. This is a similar move to the one Sun made in 2006, hiring 2 key Ruby/JRuby developers. Jython is an implementation of the Python language on the Java Virtual machine (JVM), and it was announced that the two new hires will be working full-time on Jython and paying particular attention to developer tools.
• On April 8th Google announced the Google App Engine which lets you run your Web applications on Google's infrastructure. Although controversial, this ambitious new project offers a full-stack, hosted, automatically scalable Web application platform that is attracting a lot of attention in the market. And the first programming language that this environment supports is of course - Python.
• New alpha versions have been released of the next revolutionary Python language version - Python 3000 and there are plans to release a beta version sometime this year.

With all of this activity around the Python programming language, it seems to me that its popularity will continue to climb in 2008 as well. Here at SharedBook we are thrilled by this since we are investing a lot in Python (alongside Java) and developing some cool applications using it. Besides Blog2Print we are using Python for some of our partner integrations.

Learning Python is easy. So go ahead and give it a try - the official (and highly recommended) tutorial can be found here. If you are new to programming or even if you've never programmed before you can go to this page and find some useful resources to learn programming using Python.

More "If" ...

This is my third and final observation of the poem "If" by Rudyard Kipling. You can read my previous post here and the first here. I believe the poem holds many truths that can be applied to life overall, as well as that within a high-tech company.

"If you can fill the unforgiving minute
With sixty seconds' worth of distance run,
Yours is the Earth and everything that's in it,
And-which is more-you'll be a Man, my son!"

A workplace, as home-like as it can be (SharedBook for example) inevitably involves human interaction. Add significant challenges to the equation that sometimes translate to tension and you get conflicts.

What if each one of us could take a few seconds before reacting toward our fellow man and think about the "right" reaction or what to say? Wouldn't we dissolve some of the conflicts before they occur?

Reading the poem made me take a few steps back and think about how I can improve my behavior in day to day situations.

I strongly recommend reading the entire poem. And if you do, I'd like to hear what you think.

What If? contd.

Last week, I posted an observation in regards to the poem "If" by Rudyard Kipling. I believe the poem contains many truths in respect to life in general, as well as life in a high-tech company. I would like to share two more thoughts. This is the first.

“If you can make one heap of all your winnings

And risk it all on one turn of pitch-and-toss,

And lose, and start again at your beginnings

And never breath a word about your loss;"

Software Development – Hmm ...

How many times have you worked hard on a specific design, thinking that it was a pretty good one, even “state of the art,” and implemented it … only to find that a few months later or even a few days later, the focus of the product changes and your development becomes totally obsolete? It all goes to the trash can.

Sound familiar?

But here’s the deal, even if the work is thrown away and no one will ever utilize the development – it will never be in vain.

Ask yourself: did you gain technical knowledge that cannot be erased? Are you advancing towards being adaptable to changes (Agile, XP). Are you doing what's best for your company? Are you being professional?

And also, I find that in our case, the faster we start working on the next project, the sooner we are filled with enthusiasm and the sooner we continue contributing to the system.

Feast of Freedom

Here in Israel we are getting ready to celebrate “Pesach,” or Passover. Passover is called the “Feast of Freedom” since it celebrates the Exodus of the Israelites from bondage in Egypt.

Today, as we had our traditional Passover toast in the SharedBook Israeli office, it made me ponder. I was thinking how much progress we have made here in SharedBook, and how much we have to celebrate with all the activity going on, with our new clients and partners and products.

We have introduced our API as a tool to “free the Web.” And we are seeing the fruits of this open API effort now, with a variety of clients using the API.

With several exciting new launches, the most recent of which is probably the personalized pocket travel guide that Ann mentioned yesterday; we have way more reasons than ever before to celebrate the “Feast of Freedom.”

Happy Passover!

What If?

I recently came across the wonderful poem "If" by Rudyard Kipling. In my humble opinion, it contains many truths both in respect to life as a whole and to one very specific aspect of my life. Let us take for example life in a high-tech company …

"If you can keep your head when all about you

Are losing theirs…"

How many times have you encountered a "crisis" situation? An important client requires an immediate update, one of the production servers is failing, or there is a demo planned with a client and the system is having some issues.

Sound familiar? The last thing we want to do as professionals is PANIC… If we are in a panic not only does our mind block and prevent us from getting to a solution, but we also project this state of mind in our surroundings and make it difficult for our colleagues to be productive. To paraphrase, if we are calm, it clears our mind to handle the task and strengthens our colleagues, reassuring that we are all up to the task.

To the point of actually solving the issue: assessing what we are all up against (as a team), having a brain-storming session, assigning people to the tasks and monitoring the progress of colleagues – all of these actions help to bring the situation to a happy ending.

And by the way, acting calmly doesn't necessarily have to mean moving slowly J …

Last week we had one of these “crisis” situations. A task force was assembled to handle the situation, and it was very interesting to see how the members of this task force, dealt with all the tension, conquered their fears and focused on solving the issue. And indeed after a few hours the issue was solved.

Kudos guys. J

More Riddles

A few months ago I described a bug blitz that we conducted in SharedBook in my post Riddle Time.

Well, this morning we just launched a new and improved version of the SharedBook application as a result of the latest bug blitz. Once again, our developers and QA engineers invested many hours, and showed great team work and much creativity in solving the little riddles, sometimes referred to as bugs. J

Bike Races and Release Management

Two interesting experiences happened to me during the past week or so: we launched a new release with plenty of exciting new features, and I had a road bike race – the season opening bike race. I spent a lot of time and energy planning and executing on these two projects, and once again was surprised to discover how similar bike races and software projects can be.

Planning, executing the plan, reacting fast to changes and of course: racing to the finish line, when you have to think fast – real fast, if you want to win the race or launch the new software release are very similar.

Planning
Before you start developing a set of features, you have to pay careful attention to what each feature entails. What does it do, what can go wrong, how are you going to implement the feature, etc.

Before you go on a bike race, you do exactly the same: carefully learn the race course, what does it entail, what can go wrong (sharp turns, hills where escapes are likely to occur, etc.), and prepare a race plan, specifying exactly what to do, and when.

Executing the Plan
Once the planning is done, the fun begins.

In software projects, coding is the most creative part. You can do it on your own, and it’s even better to do together (pair programming is an important practice in SharedBook). Teamwork is especially important in software projects. You work together with your teammates, brainstorm together on difficult issues, and you know that if something goes wrong (and it normally does in software projects) you can rely on your teammates.

Bike races are the same. The race starts, you follow your plan, and you keep looking around for your teammates. Working together with them, knowing that if something goes wrong (and it normally does in a race) you can rely on them.

Reacting Fast to Changes
In every software project, eventually there are changes to the plan. If you are smart and alert, you quickly notice them, and react fast. These two qualities: noticing quickly and reacting fast are essential for every successful software project.

Bike races are all about creating changes to someone else’s plan and reacting fast to someone else’s changes. So you have to be very alert all the time. Quickly noticing and reacting fast to every change: fast acceleration after a quick turn, or a break attempt at the hilly part of the course – if you don’t notice them quick and react fast – you’ve lost the peloton, and lost the race.

Racing to the Finish Line
Software projects tend to go wild towards the end. Suddenly, two days before launch – everything seems to break (did someone call Murphy?). This is the time when a manager has to analyze the situation quickly, assign priorities and act. Fast thinking is critical at this phase.

Road bike races are all about the finish sprint. And much to my surprise I discovered that if you want to win the race in a sprint, not only do you have to bike fast, but you have to think fast. Analyze the situation, find a lead candidate, draft on his wheel while carefully calculating the distance, speed, your energies, and physical power, and then go out sprinting at the right moment.

Sweet Victory
How sweet is the moment when you’ve realized that you’ve just successfully launched another software project? Watching your new features in production? Watching the beautiful books created using those features is an exhilarating experience!

In a bike race, till the very last moment, you can’t tell whether you’ve won a race or not. I still remember the surprise and excitement I felt to find out eventually that I won the race (by a fraction of a second). What a sweet moment.

And What Do I Do Afterwards?
All the focus and concentration required in managing a software project can leave me exhausted and mentally drained. All the focus and concentration required in a bike race can leave me exhausted and mentally drained. What do I do to relax afterwards? That is simple: in both cases, I just go out running. J

* Special thanks to the SharedBook team that makes it all happen, delivering one successful project after another.