Continuous Learning

Today’s web clipping has a shipping theme to it.

Shipping Isn’t Enough

Instead of measuring by shipping code, true success only comes from having users.  And that means developers should do things outside of "coding".

A smart software developer knows that there’s no point in writing code if it’s code that nobody will see, code that nobody will use, code that nobody will ultimately benefit from. Why build a permanently vacant house?

…

Things like documentation, interaction design, cultivating user community, all the way up to the product vision itself. If you get that stuff wrong, it won’t matter what kind of code you’ve written.

Great point, and one often missed in many corporate environment where no one is empowered to do anything, as pointed out by Mike…

We are not talking about Software as a Service here, but rather selling services to produce or customize software products. For tax purposes, government lumps anything that they have not categorized as services. It means just about anything can be called services, so we will not exhaust the possibilities. Instead, we will focus on the following - Add-ons, Consulting/Customization, and Custom Development.

Advantage

Compared to software product models, the enticing part of software service businesses is the lower barrier to entry and potentially steady revenue. You can start a service business as long as you have marketable skills and can find customers.

Disadvantage

There is almost no scale of economy in services models. Unlike software products, where you can build once and sell a million licenses, in software services, you pretty much get paid by the number of hours worked. There are some exceptions, of course, and we will discuss them below.

This is of course THE business model for the past decade. If you were are not on the internet, then you were not viable as a business

The best thing about internet is that there are no rules, and you can do anything you want. In fact, many internet companies are not software companies or even technology companies. Many do not even differentiate through technology and yet still makes money. Many do not even sell you anything and offer free service. Yet they flourish.

Formula

The general formula is to generate traffic. The more traffic you have, the more likely you will make money. Most follow the approach to give something for free first to generate the traffic. A good mantra is to “give first and you shall receive“.

A few different ways to generate traffics are

• Portal - offering wide variety of content
• Search engine - offer targeted content
• Content-led - specialized site offering specialized content to increase stickiness
• Community - let customers interact with each other to create a sense of online community via forums, newsgroups, or other type of social software
• Viral - leverage customers and use them to market your services; often build-into the software itself (such as hotmail)

This is the third article in the Software Business Model series.

While software by nature fits the mass volume model, some software are only needed by few individuals or companies. In such case we must sell the software at a high price point in order to recoup the cost. And this is why we have the business model of Enterprise Software.

The main difference between enterprise and shrinkwrap software is that enterprise software by definition is low volume and high price point. After all, there are just not that many corporations around. Furthermore, corporation generally protect themselves through myriads of procurement procedures, which drives up the cost of selling for vendors, and that add to the final price points.

One thing to note is that few enterprise software are used as is, because they just are not that useful by themselves and require customizations. We will talk about the customization aspect at a different article.

IMHO, there are two specializations under the Enterprise Software Business Model - Platform Software, and Business Process Software. While one can equate SAAS as an Enterprise Software Model, we will discuss it under the Internet Software Model in the next article.

Platform Software

While one might argue platform software are shrinkwrap software, I differentiate them not because the nature of the software but rather than business model of the software. For example, Microsoft Windows is sold both as shrinkwrap and as Platform software.

This is the second article in the Software Business Model series.

I will use the following template to discuss each of the business model that I am aware of. I do NOT have experiences with ALL of the models, so let me know if you found some information missing.

• Name of the model
• Overview & Synopsis
• Formula - how this model makes money
• Segment - under which general market segment can you sell the software
• Channel - how do you market and sell your software
• Advantages & Disadvantages
• Hidden Cost: Costs that startup founders might not be aware of
• Special Case: Any specializations of the model

Per Joel Spolsky, there are three pricing structures for software:

The models described in this article all fall into the second category.v

Shrinkwrap

This is the most familiar software business model since the early PC days. Since the advent of internet there are proliferations of many other models, but the traditional Shrinkwrap model is still going strong.

One of the first things that a budding entrepreneur must consider is a business model, i.e. how to make money.

Due to its amorphous nature, software can be adapted toward many different business models, and you can easily find success stories in just about any business models that you can think of. However, there are widely recognized, try-and-true models implemented successfully by many companies, and we will do ourselves a favor if we study these business models to understand how they work, what are the advantages and disadvantages of the model, and potential returns and pitfalls.

The nice thing is that many experts have talked about the various models at length, and there are tons of quality writings on the net. We can all learn from their wisdoms.

The challenge is that there seems not to be many articles that summarize the various models. I am sure they exist, but I just can’t find them

This series is an attempt to summarize the various common business models that I am aware of. As I come across good articles and new business models, I will add them to the series as well.

At a high level software businesses fall under two buckets for what they sell: Products or Services.

Products

This is when the business derive revenue direct from selling copies (generally called licenses) of the software. Because software can be cheaply manufactured (duplicated), one can sell many copies of the software easily, and the upper bound on the number of licenses is only limited by the market size. Keep reading →

This is the second article in the Software != Construction series. The first article focuses on why it matters:

• With construction metaphor, we assume software has properties of constructions that it does not have, namely
1. Construction building effort can be fully parallelized - so can software (this is the mythical man month myth)
2. Construction can be done by many cheap labors - so can software (this fuels the offshore movement)
• These thinking lead to the focus on reduction of software development cost, rather than focusing on adding value through software, focusing on the cost will cause outflow of technical skills in the company
• Business in the long run need to compete with technology as enabler, and outflow of technology skills will have drastic impacts in the long run

While the construction metaphor has enabled us to realize effective planning and management increases the likelihood of successfully delivering a complex software project, the problem with using a metaphor is that it draws your attention on the similarities, and conveniently hides away the differences. We can easily see where the similarities between software and building constructions, but many cannot articulate the differences.

The trouble is - these differences matter (shown in the first article). In this article we will focus on seeing the differences. As previously stated, the focus on this series is to provide the non-technical folks (a.k.a. business folks) with an appreciation of what software really is. If you are a techie, while you might already know this, you can benefit by letting the business folks you work with read this article. Because such knowledge only resides in technical folks, we must take the burden to education the business folks to help them understand software so everyone can benefit.

First Difference

First - let’s examine the physical characteristics of buildings and software. This should be obvious, software and buildings have very different physical characteristics - one is tangible and the other is not.

As promised, there are a couple of software myths that I think are not covered in Robert Glass’s book, and this post will talk about one of them - that software development equates to building constructions. This is a very popular metaphor - first you design, and then you build; just like when we are constructing a building.

Even though this metaphor is popular, in reality it actually is very dangerous and misleading, because it degrades the partnerships between the technical folks and the non-technical (i.e. business) folks and threatens to destroy the values that software projects should create in the first place.

Let me tell you why.

Now - Others have previously pointed out that Software is not similar to building construction, as well as pointing out the horror of command & control style of management. However, while these writings struck a chord with me, they are meant for technical folks rather than business and non-technical folks, when they should really understand the reason and the impacts. In the IT world, business folks matter a lot, both for the project successes and for the general well-beings of the project teams, and it is critical that they can understand the differences. So I will attempt to explain this in a different light. Either I will be successful, or someone else will continue to pick up the torch. This will not be a fast process, but I will do what I can to help.

Because this issue is very important.

We can easily see the similarity between software engineering and building constructions, especially if we are attempting to create something complicated. The famous software project management guru, Steve McConnell, draws a clear parallel when he emphasize the need for proper planning to ensure software success (paraphrased below):

Writing software is like building houses. (Steve actually provides a few different metaphors but appears to like this the best) If you are building a doghouse, you do not need a lot of upfront planning and you can do just fine. However, if you are building a skyscraper, you most likely will fail without proper upfront planning and preparation. (Code Complete, Second Edition)

His point is very well taken. Similar to building constructions, software projects require upfront planning to ensure success. But that is because planning is in general good for achieving any moderately difficult objective, not because software development is the same as building constructions. For example, proper financial planning will help us reach our personal financial goals easier (or so I have been told), and proper wedding planning will ensure the bride entering marriage happily (or so I have been told).

Steve points out that building constructions is a metaphor, and he puts it succinctly:

Using metaphor is a fuzzy business. You have to extend them to benefit from the heuristic insights they provide. But if you extend them too far or in the wrong direction, they will mislead you.(Code Complete, Second Edition)

The challenge here is that we have already extended the metaphor of building construction too far, especially in the IT world. This is something Steve probably could not have foreseen.

Now - why is building construction a popular metaphor? While I do not know the historical context, my guesses are: Keep reading →

by Yogi

Triage, originated in the battlefield medicine, is a time honored technique for determine the priorities for bug fixing in the software industry. As Steve Pavlina puts it succinctly in his article Triage, all of us only have so much time on our hand, and in order for us to gain the most out of our time, we need to ensure that we handle only the vital tasks. Some of these vital tasks may not look urgent, but without our attention and effort, it will never come to fruition. The goal of triage is therefore to ensure that we prioritize efforts that will give us the biggest bang for the buck. I believe most of us in the software industry can readily agree to such assessment, except I am a bit puzzled with the declarations that these vital tasks actually are not urgent, because in software, these tasks are.

A generic approach to classify the bugs is to rank their severities, with severity 1 (sev 1) being the highest. Sev 1 bugs generally cause the system to malfunction, crash, causing loss of data, or even lives if the software manages something critical such as heart regulation, airplanes, etc. There is no question that these bugs deserve the highest attentions from us. Sev 2 bugs generally are defects at lesser magnitude - the system is still not fully functioning, but the impact is less drastic, Keep reading →

For some reason, there are a lot of myths and misunderstandings about software development. Maybe this is the way it is for all fields, but that would be surprising. If it is just urban legends for outsiders, that makes sense and adds to the mysterious appeal. However, I would venture to say that most people in this field all have different views on what software engineering is, and many of them are simply incorrect understandings.

Robert Glass’s book - Facts and Fallacies of Software Engineering - happens to provide a good source for many of these myths and misunderstandings. Robert has been in the industry for a loooong time, and he has a lot to say on this matter, Keep reading →