One project I have been working on recently is a code upgrade of an existing enterprise web application. It is not a re-engineering effort, but instead only consists of necessary code changes to get the application working with the latest versions of the system software. The application had been in use for several years, and the existing development effort was concentrated on new features and maintenance, and the customer only prioritized the shift as they recognized many infrastructure issues.

The project was an illustration of how good code written in the past can become terrible even if no one has touched it. As Lewis Carroll wrote through the mouth of the Red Queen, “it takes all the running you can do, to keep in the same place”. Here are some thoughts:

1. If you have the ability to choose a particular programming language and platform (your expertise being equal in the choices available), you would most likely make a different decision at different times. A choice made with good reasons years ago may seem bad today.
2. How some of the relative strengths of different languages change over time and others don’t. When it was a released, C# was a joke, an impostor to Java. Today, with Java’s stagnation, it is light years ahead. But when it comes to third party software (especially open source), Java still has considerable strength.
3. The progress of languages and availability of external packages and utilities makes new code look entirely different from older code, even though they are both written in the same language.
4. The increase in test-driven development (along with the network-driven popularity of some frameworks) has also driven changes in the organization of code, something that had to be previously driven by disciplined adherence to standards. In other words, falling into the pit of success.
5. How many millions of man-years have been wasted on writing code for complex frameworks designed by bureaucrats? Not to mention money spent on earning silly certifications to prove yourself competent in them. (You know what I am referring to!)
6. Convention over configuration. A simple concept that makes for incredible productivity.
7. In the short-term (as measured in months), it is probably less relevant. But when an application use spans years, the gains from better hardware makes a mockery of many code-level decisions for performance optimization. In the long run, it is always better to write better, decoupled code than have to write code that has to work around hacks.

The great moments in refactoring existing code are when you can simply delete vast chunks because they are superfluous or because you can drop in some external library to do the same work. But most changes require a scalpel instead of an ax. The typical approach is to build “scaffolding” by writing test cases that work against the existing code and then change the code as necessary while continuing to pass the test cases. This ensures that the upgraded product not only contains good code, but has been verified to exhibit the same behavior.

Codecademy has been gathering a lot of attention in recent times with many people, including Mike Bloomberg, pledging to learn code. The high-profile pledges shouldn’t be taken too seriously: they are just friendly endorsements for the well-funded startup that Codecademy is. And some of the others are perhaps well-intended, but the equivalent of New Year Resolutions, never to be followed up for any significant change in the person’s knowledge or skills.

For most people, not spending their time on learning programming is a good thing, because:

1. Most people are good at (and work on) something other than programming. It is a better use of their time to become better at what they do.
2. Programming may not even be a useful secondary skill. Many people would benefit much more from improvements in items like financial management, formal writing, presentations and so on, that help them in personal and business situations.
3. Experienced programmers have already created hundreds of thousands of programs to solve most needs that require programming. Just take a look at the App Store.
4. There are very few, if any, unsolved problems that can be solved with a cursory knowledge of programming.
5. Many people struggle with basic programming concepts that even programming as a hobby or entertainment is not an option.

Experienced programmers who have huge codebases floating in their brains all day, may find this strange, but many people find elementary algebra and logic too hot to handle. This is even true for those looking for work as programmers. Let alone things like recursion, polymorphism and pointers, people find it difficult to understand basic control flow constructs such as conditions or loops. Forget programming languages for a minute, think about something like Excel functions. Sometimes even smart business people find them challenging beyond the most simple formulas. To the extent that they can use brute force to solve some basic coding challenges, they will start drowning in code when they try to write larger programs beyond “Rock, Paper and Scissors”.

I am not sure where this falls on the nature versus nurture spectrum. Is it possible for someone who has not demonstrated any aptitude for programming-related skills to overcome those deficiencies and become a good programmer over time? Perhaps, though I have come across very few examples. Most people are happy doing what they have been doing and a combination of risk averseness and lack of time combine to keep them where they are. It works the opposite way too. I suppose a good programmer may, with hard work, become a good physician. I haven’t seen any.

A complicating factor in all this is that code is taking over jobs that people do. Think of the professions that have been made obsolete with increasing use of software. There are many people who would willingly trade their jobs to be in the shoes of the programmers writing the code to displace them. Unfortunately, the usefulness of tools like Codecademy is limited because not only do you need much more than an introduction to programming, you need solid experience plus a bunch of educational credentials. The latter usually means a computing diploma or degree (from an educational institution) that can get you in front of an interviewer.

The people who would most benefit from learning code or at least understanding how code is written are the people who interact with programmers in their professional life. Take designers, for example. Programmers love designers who understand how good layouts can be implemented well on the web. A designer who just knows Photoshop and cut-and-paste CSS/JS makes it difficult for everyone involved. Or other examples:

• A tester who can write a well-maintained set of automated scripts for functional and load testing.
• A project manager who understands how complex a particular task can be in code instead of measuring its impact solely by front-end changes.
• A recruiter with the ability to accurately appraise candidates through meaningful technical questions and doesn’t get fooled.

And so on. In technology, we are obsessed with programmers. But there is a much bigger set of people that deal with programmers directly or indirectly. It makes a lot of sense for them to improve their knowledge of programming as a secondary skill so that they can do their primary jobs in a much more informed way.

Bryan Caplan writes:

If I’d failed Spanish, I couldn’t have gone to a good college, wouldn’t have gotten into Princeton’s Ph.D. program, and probably wouldn’t be a professor. But since I’ve merely forgotten my Spanish, I’m sitting in my professorial office, loving life.

Most people can relate to this. During school and college, we have to study and pass several subjects. Nearly all of the knowledge imparted will never be used by the students in their professional or personal lives and most will be forgotten, though the specific pieces of knowledge forgotten or unused will vary from one person to another. Yet not learning the subjects at the time will ensure that the student does not graduate and ends up in a much worse place in life. Failing is far worse than forgetting, even though both indicate the same state (lack of knowledge or skills) albeit at a different point in time.

This reminds me of a recent successful Indian movie, “3 Idiots”. The protagonist (played by Aamir Khan) is a student at an engineering college who finds the teaching by the professors suffocating. He publicly criticizes teaching to the test instead of imparting education that can be used in practical ways. The exam results come out and we, the audience, expect him to fail. But it turns out that he has earned his way to become the top student in the class. What the student understood is that, you can criticize the rules, but while they are in effect, you have to play by them.

In many scenarios, people forget this. They don’t like the rules and invent an imaginary set of rules that suits them. Just as the student who unilaterally decides which subjects to study or which not, based on his assessment of what is appropriate, this generally ends in sadness when reality strikes. And there is also the case where people imagine that a written set of rules are in effect, where as the opposite is true in reality.

Take the copyright and piracy debate. De jure, we have laws that afford copyright protection and enforcement to creators. De facto, the enforcement is not total and the advancement of technology continually pokes new holes in that enforcement. On one side, we have copyright violators who don’t seem to understand (and are shocked to learn first-hand) that there are laws governing copyright and there are departments of the government that are in charge of enforcing those laws.

And on the other side, we have Andy Ihnatko:

The world does not OWE you Season 1 of “Game Of Thrones” in the form you want it at the moment you want it at the price you want to pay for it. If it’s not available under 100% your terms, you have the free-and-clear option of not having it.

Any business which has the same attitude is living in a dream world while more agile startups steal their customers. This is equivalent to saying, “If you want to hear this song, you can buy it along with ten other songs you have no interest in hearing on this CD. You do have the option of not buying it.”  Or to take the television series example from a few years back, “If you want to watch this episode, you can see it on Thursday at 11 pm. Or five months later as a re-run on this obscure channel which may or may not be available on your channel line-up. Or just before the next season on DVD along with the other episodes. You do have the free-and-clear option of not seeing it.”

Ihnatko scored some points capitalizing on the inter-generational divide by calling those who would object to the current status quo as people with a “smug sense of entitlement”. He misses that rampant piracy is indicative of a supply problem that producers should fix. Most people do exercise their option of not watching the series, with only so many hours in the day and with so many other entertainment choices. Piracy is a sign that there is a market to be tapped with better pricing and availability.

The point I want to make is that Ihnatko and others like him seem to think, “These are the rules. This is how you should think. This is how you should act.” And somehow the act of their believing it would make it true for the behavior of others. It doesn’t work that way, just like posting a speed limit of 55 mph does not mean that everyone is traveling under it. You have to look at actual behavior. Sometimes, you have to adjust your incentives. Sometimes you have to make new rules.

Dan Ostlund at Fog Creek Software talks about how they have got rid of commissions for sales people:

We did it because we were having a lot of the problems with commissions described above even though all of our salespeople are ethical and decent. Commissions just encourage certain kinds of behavior; dysfunction is built into the logic of the system. […] So we did it, and no catastrophes struck us. No earthquakes. No plagues, and no one quit. In the year since we dropped the commission system our sales have gone up. In fact, four of the last five months have been record months.

There are many problems with sales commissions, but by introducing a fixed salary, you are introducing newer ones:

First, why did no one quit in the last one year? Usually, if people don’t find themselves earning as much as they used to, they try to find a new job. What this sounds like is that every sales person was paid a salary that was equal or close to what they were getting before. Since it is not a commission model, I am assuming that salaries are tied to an annual review: a monthly or even quarterly salary review is really a commission model without the name. In a commission scenario, the sales risk is split between the company (salesperson’s base salary) and the salesperson (their commission). Now it has almost entirely shifted to the company.

Second, was any new salesperson hired in this year? What was their salary? If their salary is similar to that of an established salesperson, that means the company is taking a huge risk (paying too much money) on an unknown resource. A good salesperson in one company may not have the same performance in another (even if they have the potential), hence the risk. But if they are starting at a lower salary, are you able to attract a salesperson who has a proven sales record and is worth investing in? The way most companies structure this is that salespeople have a base salary and, if they switch jobs, they can regain their previous income by quickly selling more so that the commissions kick in sooner. With fixed salaries, the only way you can achieve it is to keep increasing the salary as the salesperson performs, which is once again like the commission model, but locking in the risk for the company.

Third, was anyone fired this year? What is the basis of measuring the performance of a salesperson? Is it the overall company revenue or the sales closed by the salesperson? If it is the company revenue, then poor performers could coast at the expense of better sales persons. If it is individual sales, you have introduced a new commission system. In that system, very poor performance means loss of job (zero revenue), average performance means retention (with no or little hike) and good performance means a good salary hike. This is once again shifting most of the risk to the company. Unless it is a really poor market, the salesperson is usually retained or can easily find a new job.

So, there are at least 3 possible ways that you are introducing greater risk to the company. The important thing to understand with risk is that it can be independent of the salesperson. A lot of sales has to do with external factors. For example, when the economy (or an industry) slows down, companies will reduce or eliminate purchases. Usually this happens gradually and a salesperson who had been running great sales numbers suddenly hits a plateau and starts going down, despite putting the same effort as before. With a commission system, the compensation system automatically adjusts. But in a salary model, it takes time to identify the situation with the market. By then, your losses could run in the tens of thousands of dollars (and more with a large sales team). And then, you have to decide whether to lay off people or reduce everyone’s salaries.

Finally, while Theory X is counter-productive, how you approach the topic of money for people’s efforts is very important. Specifically, giving people more money does not motivate them as much as you would like. In some circumstances, giving people more money can be insulting and counter-productive. But the contrary situation where you give people less than they think they deserve: that is an absolute no-no. When people think they are being denied the fruits of their labor, they get hopping mad and will either demand more or quit producing so much.

This needs to be understood carefully. Suppose you volunteer your time at the local hospital to help some elderly patients. You are doing it out of the goodness of your heart and don’t expect to be paid. In fact, if someone offered you some money, you would feel insulted. But suppose you were hired to do the job and were told you would be paid a salary, and when the time came to get your money, they tell you, “This work is its own reward and you are gaining pleasure from the work, so we are keeping back 10% of your paycheck.” You would be outraged and quite rightly so. Essentially, employees have expectations (financial and otherwise) and you need to meet them.

So suppose you have a salesperson who is paid a salary. You asked him to bring in 15 clients and instead he brought in twenty. Well, you have to give him a good hike. Next quarter, he outdoes himself and brings in ten for the quarter. What do you do? Do you wait till the end of the year to give a hike? Suppose he brings in fifty for the year. What kind of hike does he get? What happens?

As you can probably guess from human nature, this will not go that far. As soon as a sales person starts doing way more than you had asked them to do on the basis of their fixed salary, the first thing they will look for is greater compensation. They know that the money coming in is proportional to the company’s profits. If such compensation is not provided (either in the form of higher salaries or company shares), they will most likely quit or, if that is not possible for whatever reason, calibrate their efforts accordingly.

In sum, a fixed salary serves primarily to transfer greater risk to the company and create a trend for salespersons in the company to maintain a constant sales-to-salary ratio over time. That may be acceptable to you, especially when marketing can support sales efforts in a rising economy. It may not work at other times.

I am a little late to this party where Michael Arrington says that startups mean working hard and sleeping under your desk. But I will add a few words. I read a lot of commentary about how such death marches can be counter-productive and ultimately unsuccessful, and also the real dangers they pose to the well-being (short-term and long-term) of the lives of the programmers. But I didn’t see many people actually do a quantitative analysis. So here it is.

Your average working day is 8 hours and the average week has 40 hours. Now,  in the absolute best case (unworldly) scenario, your startup has a programmer who does nothing other than program, 24 x 7 (not even sleep). That translates to 168 hours, which means you have a programmer working 4 times harder than usual.

But of course, programmers are not machines running all the time and even those break down. They are subject to the same biological needs that other human beings have. Like, sleep. The optimal amount of sleep for human beings is between 7 to 8 hours. Now, you can survive a day or two with less sleep, but it will catch up and in the meantime, you are operating at below-peak efficiency and it is a wash. Using an estimate of 7.5 hours, we are down to 115.5 hours.

Then food. And you need to first get the food (order or cook) and eat it, at least three times a day. On average, let us say that takes 30 minutes per meal and 90 minutes overall. Now, if you are ordering pizza delivered all the time, maybe you can bring that down to 15 minutes per meal and cut that down to 45 minutes. So, let us average it to an hour per day. We are down to 108.5 hours. Hygiene? Brush your teeth? Take a shower sometime? Best case, let us say 30 minutes a day => Down to 105 hours. Commute from and to work? The average commute in 2007 was around 45 minutes round-trip. 5.25 hours per week => Down to 100 hours. Maybe you can reduce that by sleeping under the desk!

At 100 hours, that is just working two and a half times more. And we have not even talked about productivity, family needs, illness, having friends, non-work needs and activities, etc. For all intents and purposes, you are looking at somewhere between 10 and 14 hours of work 7 days a week.  And even that can only be sustained on a short duration (months).

So, here is the question: Is working about 2.5 times more going to make your startups yield the astronomical (i.e., 10 times or 100 times) returns expected? What is the value of the extra 150% put in by the programmer? Does 40 hours a week mean regular company returns, and 100 hours means Facebook-like valuation? And if that is the case, why not hire extra programmers while you are at it? Seriously, if putting in more hours means a huge guaranteed return, then surely adding more people gives you bang for the buck, right?

If not, why is it not? And why do people like Arrington and Jason Calacanis want people to work themselves to death? One possibility is that they don’t know how to count and seriously think that working a few extra hours suddenly translates into huge profits. I think there is something subtler happening.

The truth is that even with sophisticated metrics collection at work, you cannot properly gauge programmer productivity. There are ways to game the system, and even if people are not trying to game it, you have to spend time looking at the code in detail to see what is being churned out. People like Arrington don’t have the time or the expertise to do that. Instead they measure productivity by the number of hours the programmer is available to them. This means how much time the programmer is at work (they must be coding every second!) or how easily they can reach the programmer when not at work. If a programmer picks up a call from Arrington at 1 am, she is practically working all the time, regardless of the fact that it might only take her 10 minutes to answer the call and fix an issue.

So while Arrington and Calacanis say and even think that they want the programmer to work all the time, what they actually want is the person to be available all the time. More so because they cannot produce or fix anything without their help. This has nothing to do with startup success or failure. You can read similar stories in established companies with stupid bosses, where leaving one minute earlier than the boss has a whole different meaning than leaving one minute after.

So as I had planned, I watched the documentary “Helvetica” on Netflix. It is a well-made film consisting primarily of interviews with type designers interspersed with a zillion visuals of Helvetica font used all over the place. Not being from a graphics background, I was astounded to see how ubiquitous the Helvetica typeface is. Most corporations use it for the design of their name. Street signs are written in it. Even T-shirts!

The interviews were interesting enough with some of them having intensity and passion in their advocacy or criticism of Helvetica. Some of the type designers talk of Helvetica as the “perfect” typeface because every choice (such as the horizontal orientation of the edges in “C”) cannot be bettered. The critics say that because of this aspect and also because Helvetica is everywhere, using Helvetica implies conformity with the mainstream and when you are part of the counter-culture, you would want to go in a different route. Of course, this needs to be taken in context with the typefaces used before Helvetica in print advertisements.

If you are creating web applications, you cannot use Helvetica as a font as it is a commercial font and for some licensing issues, it doesn’t come bundled with every operating system (apart from Macs). So instead of Helvetica, we have Arial that is on everyone’s computers. If you had asked me to compare the two fonts sometime back, I wouldn’t have cared, nor would I have known the difference. But there it is. At some point, Microsoft decided to actively promote Verdana (instead of Arial) on the web, using it for everything, including the MSDN site. On the desktop, the default on Microsoft Word for Sans Serif fonts is Calibri, which strangely was a replacement for the Serif font Times New Roman.

I like Calibri for documents as it is very readable on a monitor. But for regular text on the web, I prefer Georgia, which is the default font on this blog theme (Thesis) — again a very readable font, and it does seem to be very popular online. For mono-spaced fonts for code, I like Consolas, a big improvement from Courier New. Headings — I am not so sure. Georgia looks fine, but headings are very significant in conveying the mood of a website, so doing something different and unique can be worth the effort.

Martin Fowler re-posted this article from 2004:

Tests are always going to be incomplete, so they always have to be backed up with other mechanisms. Being the twisted mind that I am, I actually see this as a plus. Since it’s clear that Specification By Example isn’t enough, it’s clear that you need to do more to ensure that everything is properly communicated. One of the most dangerous things about a traditional requirements specification is when people think that once they’ve written it they are done communicating.

So I guess it is time to dig up my older posts about documentation. Here are some things to remember:

1. Documenting the behavior of software involves effort and is not free. Like other activities in software development, you have to mark time out to do it. Otherwise it will not get done.
2. If you allocate this activity to someone who is already assigned other tasks (coding, testing, etc.), chances are they will consider it a lower priority than their other tasks, unless you specifically ask them not to do their regular tasks and solely work on the documentation task.
3. But when you do that, those persons still think they are not getting “work” done. There is no visible output apart from a documentation file, and there is less progress on functionality released to customers, even though there may be better quality.
4. It helps to assign a dedicated person to work on the requirements, so that the programmers and testers can go back to doing what they are best at. A technical writer or a business analyst can do a faster and higher quality job.
5. Unfortunately, this raises the cost of software development and may not work for everyone.

The last point is something that I find some people unwilling to accept. It is better to BOTH write good specifications AND write good tests, because they will cover most gaps in your understanding of the requirements. You could write specifications in different formats to target different audiences (say more graphical for customers and more structured for your programmers). You could write manual acceptance test cases, automated unit tests, performance tests and so on. They are all useful at the margins.

But everything costs time, money and effort. If you cannot afford it, that is fine. You or your customers may have to live with a little less quality. In smaller teams, this is the reality. For example, a small team of 2 developers will not have the time (and money) to thoroughly test every aspect of their web application on all possible browsers (and different versions) on different operating systems and hardware. But you have to accept that when you do so, there comes the risk of bugs in the field. Some people find this too real to handle. Instead, they want to have (keep?) their cake and eat it too. They want to get rid of something without accepting that there is a cost to doing so.

In general, in software development, more money available and spent wisely on people, tools, infrastructure and processes = higher quality software delivered at a faster pace. People are not always wise with money and you can gain some efficiency with intelligence, hard work, perseverance, and discipline, but not beyond a point. If some reasonably smart software company has hundred times the money you have, chances are high that you are going to lose.

Nope, this has nothing to do with software development. But for regular readers, a few things to note:

If you have subscribed to the RSS feed, please validate if you have subscribed to http://feeds2.feedburner.com/thoughtclusters. There is a digit “2” at the end of the “feeds” sub-domain. Apparently, the “new” FeedBurner wants it that way. If you are using the older feeds.feedburner.com link or http://www.thoughtclusters.com/feed, you should probably change it.

In case you like getting your updates through social media sites, here are the links:

• The Facebook Page
• Twitter
• Google+

Likes, Shares, Re-tweets and +1s will be highly appreciated!

Thanks and regular programming will continue.

John Gruber posts a photo of this misleading 2007 presentation for the original iPhone:

This is true as far as phones go. But back in 2004, there was the Tungsten T5:

The Tungsten T5 cost around $400, less than what the first iPhone debuted for. It was a sophisticated device doing almost everything you needed, with some limitations on certain file types based on DRM. The Palm Desktop Manager did synchronization with Microsoft Outlook via a USB device. There was a stylus, but you could also touch the screen to open applications.

If you look at what Palm had in 2004, they had the engineering necessary to come out with something near to the technical specs of the original iPhone in 2007.  But they were not confident enough to stick the phone guts into a device like the Tungsten T5. And I am not sure I would blame them. The Apple iPhone cost $599 at launch and there were crazy queues outside every Apple shop. That is what happens when you have a fanatic following of your products. That is something you cannot imagine with a Palm device, not now, not then either.

There is another aspect that is kind of misleading. If I remember correctly, the most popular phone around 2007 was the Motorola RAZR. The RAZR, while not a touch phone or smartphone, sold 130 million units and is apparently still a record today. The RAZR was amazingly light (99 grams — compare to 140 grams for the iPhone 4S) and had a very sleek design.

But you see, what the iPhone did in 2007 was bring all of these together. You suddenly had a device that combined the power of the PDA, the sleekness of the mainstream phone and the utility of the existing smartphone, not to mention adding the functionality of the iPod. Combine that with a fan base that was ready to snap up anything you served in the initial release and suddenly, you could recoup your costs and bring down the unit cost $200 within two months.

As for the theme of Gruber’s article, I agree with his final analysis that Steve Jobs was a “large-scale visionary”. Simply look at Palm again. Why couldn’t they do what Apple did three years later? Because Palm did not believe and became a follower instead of a trend-setter. Compare that with Jobs who entered several markets with entrenched vendors and still bettered them, because he got Apple to come out with the right product that had the right ingredients for its fans to set the market on fire.

I think the beauty of Apple products sometimes makes people forget other important decisions made by Apple. For example, while the iMac G3 did not result in Macs displacing PCs, they captured the imagination of the market enough to set the stage for newer products. The iTunes Store (with individual songs for sale) was a huge factor in the success of the iPod. Similarly, the success of iPhone apps that made quick and easy riches for many software developers is still driving the iPhone and the iPad.

These were huge decisions, risky ones, that ensures that Steve Jobs is in the upper echelons of visionaries, way above the moniker of “tweaker”.

I was reading this amusing post on the Fog Creek blog by Rock Hymas illustrating Clayton Christensen’s disruption concept through the story of a cake shop owner in Siberia (!) who has some competition in the form of an ice cream stand. It is a good analogy, but it fails to explain why the cake shop owner makes the mistake in the first place. Let us take the example in the story and work through it.

The value proposition that the cake shop owner is offering is, “People want something sweet to eat after dinner. And this is Siberia. So it cannot be cold.”  But this proposition caters to only a subset of “People want a sweet dessert” because some of them don’t care whether it is hot or cold. So of this market, the cake shop owner is able to satisfy the people who want something sweet and not cold, and the people who want something sweet and can afford the cakes that are being sold. The ice cream vendor has an untapped segment of the market, i.e., the people who want dessert, but cannot afford cake. As long as he can sell ice cream at a cheaper cost, he will have some of those customers.

Here is where the blog post misses the boat a bit. Hymas assumes that the cake shop owner should recognize that many of his customers will like the ice cream because it is so much cheaper. To understand why this is wrong, think of a third vendor opening an M&M store. M&Ms are way cheaper than ice cream and cake. And a fourth vendor opening a Turkish Delight shop, not as cheap as the M&Ms, but cheaper than the cake. The question is, should the cake shop owner also add cakes sprinkled with M&Ms and sell Turkish delight confectionery?

There is no straight answer to that question because we have to ask other questions. First, how many price-conscious customers now decide to have dessert because cheaper options are available? Second, how many existing cake customers will decide not to have cake because some of their friends are now having ice cream? Third, is it profitable to provide ice cream options from within the cake shop? Fourth, will there be new ice cream competition that will undercut you by lowering even cheaper ice cream prices + less expensive cakes?

Or, in other words, why doesn’t every expensive restaurant offer fast food burgers and onion rings?

Courtesy NASA

If you are a business, there are many good reasons why you don’t want to offer an inexpensive product just because you will miss out on some customers. One important reason is that those customers are your least profitable ones. Every product or service has costs associated with developing and maintaining it (including customer service, returns, etc.) With lower-priced products, your margins are wafer-thin and sometimes negative, thus eating into the gains generated by your more expensive products.

Also, the way society works is that people segregate themselves along the fault-lines of product affordability. Some people don’t shop at less expensive places (such as Wal-Mart) because “people like them don’t go there”. Take a look at the charts in this post and ask yourself why if Apple is so profitable, is sitting on tons of cash and is trailing far behind in market share, can they not sell iPhones at a much steeper discount and make huge inroads into Android users? Well, Apple is an exclusive brand because once it ceases to be, Apple products don’t have rabid fans anymore. You don’t hear anyone brag about their iPods anymore, do you?

But the post was about how Trello is meant to disrupt FogBugz. So here are the questions that Fog Creek should ask themselves? Since Trello is free, what is paying for the development of Trello? (Answer: FogBugz/Kiln) If there is a new feature that could be added to both FogBugz and Trello, and you have to choose, which one will get the feature? (Answer: FogBugz) If a developer was previously working on FogBugz and is now working in Trello, what are the chances that he will be disrupted for some FogBugz question? (Answer: High) Vice versa? (Answer: Low) During Fog Creek management meetings for the next one year, what will be the ratio of time spent on discussing FogBugz versus Trello? (Answer: Low, and even lower if Trello doesn’t gain much traction) And finally,

Will Fog Creek introduce any feature in Trello that will make a paying customer of FogBugz abandon it for Trello? (Answer: Not consciously, but the first time they know that has happened, there are going to severe restrictions on what features are going to be introduced in Trello.)

To sum, disrupting yourself is a lot harder than it sounds, especially when it hurts the bank account.