Code to $

I'm convinced that most people think about software companies in an upside-down way. The common belief is that when you're building a software company, the goal is to find a neat idea that solves some problem which hasn't been solved before, implement it, and make a fortune. People sometimes call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works. If you understand this, it's easier to make the right strategic decisions.

The trouble with build-a-better-mousetrap is that there's not a lot of evidence that it works. First of all, many of the most successful software companies (Microsoft and Oracle, for example) don't really "innovate" in the sense that they are not really solving problems that haven't been solved before. In any market, it is exceedingly rare that you get to keep your invention to yourself. Everybody has competition. Wall Street Weenies and lawyers starting high tech companies tend to think they can protect themselves from this with patent protection. Ha! I can hardly think of a single case of a company successfully protecting themselves from competitors because of a patent. (Stac is the only case I can think of, and where the heck are they?)

The next problem with build-a-better-mousetrap is that we've reached a state with Internet software where there is too much money around chasing the same lame ideas. Call it the idrive-xdrive-swapdrive-freedrive phenomenon: suddenly thirty-seven companies pop up offering exactly the same service for free. There are a zillion examples of this. Petshops-on-the-net. Urban-video-rental-delivery. Cosmetics websites. When this happens, the business challenge switches from being a technical challenge that needs good programmers to being a marketing challenge that requires, somehow, the ability to break through the pack and establish a brand name, something that is vanishingly improbable. Not only that, but VC money is impatient. That means that investments which take a really long time to develop won't get funded, which is why anything really interesting or hard to copy won't even get funded. One reason that there are over thirty companies whose entire goal is providing free hard drive space on the Internet is that writing the code for such a service is so easy.

I'll talk later about a different way to think of software development. That's it for today... Come back tomorrow...

Biz Growth

I constantly get asked and more constantly, I ask myself what rules are involved in business growth. After thoroughly think about it, this are the governing dynamics :

1. Rule 1: Establish and maintain a strong sense of purpose
2. Rule 2: Thoroughly understand the marketplace
3. Rule 3: Build an effective growth planning system
4. Rule 4: Develop customer-driven processes
5. Rule 5: Put the power of technology to work
6. Rule 6: Attract and keep the best and the brightest
7. Rule 7: See the future more clearly

I'll post more on each one on subsequent posts, as I don't want my readers get lost in kilometric posts each day. Easy, right?

AJAX, GreaseMonkey, Bloglines and Firefox

Yes, I confess, this post's title will bring me a lot of traffic due to its high profile words. I say, bring 'em on!

After that said, I've been playing around with Greasemonkey lately, looking to see what all the hype was about.

The cool thing about Greasemonkey is how easy the scripts are to write and how it opens the door for anyone who can do simple javascript to tweak things that bother them.

One thing that bothers me about Bloglines is that it doesn't show the number of unread items in the title like GMail does. I leave GMail and Bloglines open all the time in tabs, so it would be convenient if I could just look at the titles to see if I should switch over and pay attention to them.

I looked in the greasemonkey script repositories, but I couldn't find this tweak :(

So I set out to write a Greasemonkey script to fix this annoyance. You can do Ajax stuff with Greasemonkey via the GM_xmlhttprequest function, so I combined that with the Bloglines API for getting the number of unread items.

and voila, here it is:

// ==UserScript==
// @name          Bloglines Unread Items Title
// @namespace     http://rodolforuiz.blogspot.com
// @include       http://bloglines.com/*
// @include       http://www.bloglines.com/*
// ==/UserScript==
(function() {
GM_xmlhttpRequest({                                                
 method: 'GET',                                                  
 url: 'http://rpc.bloglines.com/update?user=email@email.com&ver=1', onload: function(changeTitle) {
    var unreadItems='';
    var i=1;
    while (changeTitle.responseText.charAt(i) != '|') {
       unreadItems = unreadItems + changeTitle.responseText.charAt(i);
       i++;
    }
    if (unreadItems == '0') top.document.title = 'Bloglines';
    else top.document.title = 'Bloglines (' + unreadItems + ')'; }
 });                                           
})();

Note, you must edit this script to input your email address.

If you happen to have a + or special character in your email address, you'll have to URL encode it.

Please, let me know if it worked for you or any other enhancement that you code yourself. Remember, thsi script is GNU protected - meaning, copy it and do to it whatever your will is :)

Open Source's next crusade

This is a big question; I am going to take a stab at it. It’s no secret that open source has conquered the lower layers of the stack namely the operating system layer with Linux, the App/Web server layer with Apache and JBoss, and of course the DB tier with MySQL and PostgreSQL. Some proprietary vendors have embraced open source to their advantage and sometimes used it to hurt their competitors (like IBM’s commitment to Linux to hurt Microsoft or SAP’s support for MySQL to annoy Oracle) while other vendors have a very hard time finding a new source of revenue such as BEA.

It doesn’t take a genius to figure out that open source’s next crusade will take place. The first obvious area is enterprise applications and some people believe strongly that the second one is IT management. Open source software usually thrives where systems take forever to implement and require big upfront software licensing fees charged by large proprietary vendors making it inaccessible to SMBs. I believe that CRM, ERP and PBX are definitely in this category. In that order there are strong open source projects that are trying to claim market shares namely SugarCRM, Compiere and Asterisk. I could have added the popular Nagios project for the IT management space which extended and supported by companies like GroundWork. Obviously, today these companies are no match for Oracle, SAP, IBM, Microsoft or Cisco but they are gaining ground every day and their popularity is a clear indication of where OSS is going next.

I also believe that the penetration of open source in the enterprise application world might be even faster than its penetration in the underlying layers simply because there is a big market opportunity for services and the open source community will be much more enthusiastic about developing enterprise applications to solve real world (sales automation, HR, billing, supply chain, health records…) problems for themselves and their clients than developing operating systems which can be boring at times.

An interesting debate would be: How can large proprietary vendors continue to make money and grow? My modest and personal answer is that, among other things, they have to invest heavily in R&D to always stay ahead of the curve and change their licensing model. IT buyers are much more educated, they are willing to spend money as long as there is a demonstrable and durable ROI. Salesforce.com is a good example; they offer more functionality than SugarCRM and they don’t charge licensing fees upfront. It’s an affordable monthly fee that customers pay as they go. By the time Siebel realized they had to offer a subscription-based offering, Salesforce.com was already public. It was too late.

Impossible and difficult

I've been thinking a lot about impossible schedules. I'm talking about the project schedules that no matter how you organize the project, it's not possible for this group of people to cram that set of features into this much time. At least, the developers don't think so.

If people are up against impossible schedules, in my experience, they stop thinking. They cannot imagine a new technique or tool will help them. So even if their configuration management is in the pits, they will limp along instead of acquiring and using a new tool. And a change in technique is even worse. People who can't imagine any way to success resist any ideas like iterations, implementing by feature, test-driven development, or even peer review of code. (This happens to testers too, it's just that my examples here are for development.)

People aren't stupid. When they're up against an impossible schedule, they will hunker down and do what they can, so they won't be fired. That's all.

But with merely a difficult schedule, people will consider alternatives. They know that with alternatives they could make this into a not-so-difficult schedule, and they may be willing to take the chance on a different technique or tool -- or even both.

So if you have an impossible schedule, don't try to change anything. Or, change enough of the schedule that people have a little breathing room to try something new. But don't expect people to try something new in an impossible schedule. The personal risk is too high. It's much safer not to take a risk and miss the schedule than it is to take a risk with something new and miss the schedule.

So if you want your project staff to think, make a difficult schedule, and then set a personal challenge: "How can we make this schedule more reasonable?" In my experience, this is the kind of challenge many of us thrive on. But don't set a stretch goal. That discourages thinking and will encourage people to throw out any good ideas that have not yet become good habits.

Kudos to myself on my new role

So now you are a technical program manager. You climbed from trainee, senior engineer, team lead, project manager to program manager. You planned your career and made the sacrifices.
When staff set up the office pool, you went back to night school. While colleagues went to the local bar, you were in class with the statistics tsar.
While teammates looked for the easy chore, you volunteered for the quality program de jour. When colleagues were on the slopes, you kept the project off the ropes.
While your rival hatched political schemes, you were leading tiger teams. While the boss was on the links, you discovered how the customer thinks.
You endured staff meetings, suffered cubical seating, and dodged performance review beatings.
As you don your coveted title of the Geek Godfather, you will realize the job is poles apart from your aspiration. Even the best-prepared engineer can be blindsided by the realities and limitations of the job. The stakes are high and rife with risk. Here are a few misdemeanors to avoid. First, you have little time to run the program. Even though you are the Big Kahuna, the daily work is now out of your hands. Your time and influence will shift from direct to indirect: articulating and conveying strategy, institutionalizing rigorous processes, and setting value and tone for projects – not the typical skills of an engineer.
Ironically, the transition from engineer to program manager leaves a sense of lost control. Initially, you feel more like Seinfeld’s Kramer – restless, disjointed, and sketchy – than like his alter ego Peter Von Nostrand: cool, calm, and collected. New program managers tend to gravitate back to the comfort and familiarity of daily operations at the expense of mounting strategic, financial, legal, personnel, and stakeholder demands.
It is critical that you learn to relinquish responsibility and manage through delegation and accountability. Like the bridle, the keel, and the fulcrum – it’s about leverage. Without leverage, you will lose control.
Second, you are always sending signals. The high profile of a program manager is viewed as a perk of the job. Au contraire. The extent of scrutiny and interpretation of your every move can be vitiating. The stealthy days in the lab, computer room, or office are gone. Your microphone is always on and the cameras constantly rolling. Also gone are speculative discussions with managers, employees, and the public. One day you explore the intrigue of open source software and the next day you wake up with a new Linux server farm. One day you complement the use
of rate monotonic analysis and the next day you are listening to a briefing on vacation scheduling via rate monotonic analysis.
Consider carefully your actions, conversations, and messages. Strive for simplicity, clarity, consistency and master analogies, metaphors, and allegories to communicate your message.
Third, beware of shooting stars. Like the grass on the other side, it is tempting to reach for another’s guru. Do not be blinded by that light. Shining stars in one environment fade in others. Ask the Yankees about Alex Rodriguez’s playoff performance. Moreover, stars do not stay with
organizations long. Supernovas that jump, like free radicals, to your program are susceptible
to other enticements. Ask the Cleveland Cavaliers where Carlos Boozer is playing this year.
Bringing in a superstar resembles an organ transplant. The new body rejects the prized organ. This battle consumes resources that take away from the healthy parts of the body that soon cause other health problems. Transplanting a star into your organization will no doubt cause resentment, conflict, and impede team morale.
My advice: grow your stars from within. Internal stars know the culture, garner employee support, and are more loyal. If you do star search, assure the luminary can shine in your program.
Finally, issuing commands can be costly. The consequences of orders expand proportionally to the breadth of command. Unilateral commands that overrule thoughtful decisions trigger resentment, insecurity, and perplexity.
Excessive intervention, inquisition, and supersession create bottlenecks as employees are excessively inclined to consult you before acting.
As program manager, you will have to make decisions and give orders. When doing so, be selective, deliberate, and inclusive with a broader plan of action in mind. If not, your
office will resemble the lines at Seinfeld’s famous Soup Kitchen – no funding for you! Next!