wagnerblog.com

I have to admit that my post has nothing at all to do with the Dickens book “ A tale of two cities” from which the illustration has been borrowed. Yet I think there is some merit to this flight of creative association considering that the post does deal with a comparative account of two separate companies.

The following comparison is intended to illustrate several points of common sense business practices. I wanted to write this post because it is based on actual events and real companies whom I’ve watched for a few years. This account has been generizied in order to keep the lawyers away but make no mistake, millions of dollars were lost or gained as a result of people not following some plain old business principles.

1. First and foremost, it doesn’t matter what technology we developers love, a business can be plenty successful without the latest and greatest languages and methodologies. I know thats heresy in our community but it is true. If a business provides solid value using some old-school mechanism, and that mechanism has been shown to be profitable and customers are not beating down your door asking for changes, then relax.  An example of this is SpinRite by Gibson Research. Arguably it is a technology product and arguably it is old-school because the core product has been around for 17 years! My very first computer ( a 286 ) had trouble with its hard drive and I used Gibson about 15 years ago to fix it. I imagine this tool will be around for as long as hard drives follow the same base technology.

2. This a direct relation to the first point. Don’t take your core product in directions that aren’t requested by customers. I’m really sounding like Tom Peters now. But even Peters has been telling that bit of truth to anyone willing to listen for the past 20 years or so. One of the dangers we face in software development is that it can be so darn easy to fork our code and start work on what management perceives to be a fantastic new feature or solution. Remember if it hasn’t been requested by a customer, make sure its not some noise that waters down the core functionality of your product.

3. Take care of your people and they will take care of you. Many software companies are run by “suits” who have a marketing or sales background and do not understand the importance of human capital in a tech company. Somehow in discussing planned work the people needing to do this work become non-persons. They become resources. Cogs or pieces to a puzzle that can be moved around a schedule to meet some self imposed deadline. Typically a deadline that is based on some business need and often is not reflective of reality. Sound familiar? People are not resources. Developers are not cogs that can be moved around in a plug and play manner. Companies that attempt to save costs by homogenizing the tech work force will quickly find out how true this statement is. On the other hand, companies that realize the truth of individual contributions to the bottom line may have an experience like our friends over at 37Signals who allowed David to create RoR and as a result of this ONE persons creativity and genius ( ok he is a pretty bright fellow ), spawned an entire industry and have seen their customer base grow to over 500,000 at the time of this post. Yes I am idealizing things a little bit, but I have seen a company receive multi-million dollar investments to support a code base written by a single person. That’s correct one person, not a team of twenty. This was a learning management system and the person is my good buddy Dan.

4. Know what your company is about. Are you selling a product or a service? Especially in the software world there is nothing harder than resisting the urge to tweak your product endlessly to provide some sort of extra or different functionality. One of the greatest dangers is to get side tracked from your core business by doing endless project work that takes up your crucial resources and splinters the focus of your product. 37Signals has illustrated the core values of its business in a little e-book called “Getting Real” I recommend you read it. It contains an anecdote that I especially liked. “Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, “Does it do [x]?”, “Do you plan to add [y]?”. Finally Jobs said, “Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.”

As I said, this post is a comparison of two companies. Each followed a drastically different philosophy. One concentrated on the quality of its core product and user experience. The devs at Company A agonized over the speed of little things. Amazon had nothing on these guys. Management convened focus groups and lessons expressed by users were incorporated post-haste. On the other hand, Company B fancied itself more agile and quicker to respond to management requests. No focus groups were held and instead the product was incorporated with many partner sites making it more complex than it needed to be. Mainly because management was unable to focus on quality instead of a quick deal.

Come to think of it, maybe I should have named this post “the tale of the tortoise and the hare “ based on some of the characteristics exhibited. Some of the salient points in this comparison are:

• Company B built 1 core product and refined this product over the years to become a finely tuned money making machine. Between the two organizations, this was the tortoise approach.
• The hare solution was to form lots of partnerships that drove up the user base. Along the line though something that nobody anticipated happened. The core system in order to support these many partners was modified and tweaked and messed with until it became extremely complex. The complexity was partially due to deadlines attached to partnership deals that didn’t allow the developers to produce a better product. Greater complexity meant additional developers working on any given task, as well as a tremendous amount of overhead. At last count this company employed twice as many project managers as they did developers. That characteristic showed how much the organization had lost its way.
• Company B has no large partnerships to speak of. However, as you can see it had almost the same amount of users as A. These users were attracted to B simply on the basis of an easier user experience.
• Both companies employed old school technology. One was MS based, the other open source. B followed good coding practices and for the most part understood that a few devs can make a huge difference. A on the other hand did not.
• Both companies were managed by Sales and Marketing oriented people, not technologists.

As you can see, unless some miracle will come along, Company B is a much more viable organization. Granted the technology used is not very sexy, but customers don’t seem to mind. The company enjoys a better reputation among its users than A does, it is profitable and continues to grow. B on the other hand was creaking at the seams under the ballast of all the anti-patterns built into the organization. Do you think it is very likely that company A will continue to survive in its unprofitable state?

It all boils down to the same thing that I tell my developers – always always put quality first !

I am not the only one singing that tune. Here is a link to a presentation by Ken Schwaber that discusses this very same issue. Quality.

It is so tempting to take the easy way out and throw something together, That happens every day even on the grand scale of multi-million dollar businesses. Funny how software companies, especially web based ones, can get away with such poor quality. In this case poor quality of management on the part of Company A. By the time people woke up to these realities and how much unadulterated chaos the company was experiencing by trying to reach profitability through ever more exotic deals with crazy time lines it was simply too late. Both organization vied for the same investment money. Because A was a more sound organization on a few key points, it won the contest. It doesn’t take much to run a good software business. All things being equal, you need to have heart to take care of your people, courage to stay the course and not give into the easy fixes and most importantly you need to champion quality.