Learn to Price Software: 7 Links

I've recently become interested in software pricing, specifically for enterprise-scale solutions, and have found a lot of great information in the process. A lot of these articles were harder to come by then they ought to be, so I think it will benefit someone to collect them here.

1. There is nowhere else to start but Joel Spolsky's canonical software pricing article. There aren't a lot of solutions here, but it's a great primer on the problems and issues surrounding software pricing.
http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html

2. Part of Jason Cohen's five-part series about the joy of honesty in business, this post addresses trust and transparency in pricing. The upshot: offer discounts carefully; they erode trust faster than you think.
http://blog.asmartbear.com/discount-gambit.html

3. From OnStartups comes tips on pricing and the ramifications pricing decisions has on sales for enterprise software. This article is geared towards startups, but only in the sense that it offers basic, sound advice for someone who is not a career pricing expert.
http://onstartups.com/tabid/3339/bid/174/Startup-Tips-for-Enterprise-Software-Pricing.aspx

4. In spite of this article from Simon-Kucher & Partners being written so terribly it makes me want to remove my eyeballs, it is still incredibly informative. The discussion of price-as-value v. product-as-value v. solution-as-value gives a great mental framework to think about pricing at large, for software or anything else.
http://www2.simon-kucher.com/whitepapers/whp_pricing_professionally.pdf

5. Get a handle on some of the contemporary pricing issues facing companies today. In light of the economic events of the last two years, this article from Nielson argues that traditional pricing practices have to be reevaluated. This doesn't address software specifically, but will make you sound smart at your next cocktail party.
http://blog.nielsen.com/nielsenwire/wp-content/uploads/2009/07/six-keys-to_price-planning_whitepaper.pdf

6. Take a deeper dive into the practical realities of software pricing for large organizations. Runaway SKU counts, licensing strategy satisfaction, and SaaS considerations. For the hard-core enterprise software pricing enthusiast only.
http://www.accenture.com/NR/rdonlyres/A4A588CC-4DF2-46DB-B329-6C63F55EA47B/0/SoftwarePricingPOV_OnlineFINAL.pdf\

7. Want even more? Software Pricing Partners offers a ton of great content that will get you talking the talk of software pricing in no time.
http://www.softwarepricing.com/readingroom/content-basics.cfm

Special bonus link!
A brand-spanking new writeup from The New Yorker on price wars. It has nothing to do with software whatsoever, but is good reading nonetheless:
http://www.newyorker.com/talk/financial/2009/11/09/091109ta_talk_surowiecki

Coders at Work

A lot of buzz in blogland about Coders at Work, which came out last month. Jeff Atwood recently reviewed it, and Joel Spolsky mentioned it incidentally in the controversial Duct Tape Programmers post, which was then further referenced in an interesting post by Dare Obasanjo regarding software complexity.

The author, Peter Seibel, has a blog very much worth reading as well.

Branching Schemes

After trying all sorts of different branching schemes in source control (we use TFS), we have now gone down the road of one massive, highly volatile, development branch. Previously we had 8-10 active development branches within the company and all sorts of merging issues. After a big merge (which happened frequently, what with 10 active branches) it was often difficult to get a successful build for a few days. In addition, the merge itself took a lot of time and brainpower, and we quickly found that developers weren't getting the code they needed in a reasonable amount of time. We weren't quite to the point of absurdity that Microsoft reached, as (hilariously) documented here, but we were on that path.

We traded slow, occasional integration and painful merging for a much different system. We now have nearly all the developers in the organization working in one branch. This has its own set of issues. In brief:

Pros:

• No migration time between branches. I can get all checked-in code immediately.
• Continuous integration, and requisite benefits (we don't step on each others' toes).
• No more merge hell.
• Less strain on TFS (this seems like small issue until you realize that in addition to the 10 or so primary development branches, there were another 30 inactive dev branches and 10 or so production branches. With a multigigabyte codebase, this becomes unwieldy very quickly)
• Developers don't have to switch branches every couple months

Cons:

• If someone breaks the build, it affects a huge number of people.
• Code is changing so quickly that by the time you are ready to check in, your code is already woefully out of date.
• Very little code isolation. Other developers can jump into code that I just checked in that is still under heavy development.

The cons are few, but significant. As with everything, it's a trade off. We've only been doing this (one branch) for about a month, so it's too early to render a verdict. I deal with both the pros and cons on a daily basis, and one has yet to overtake the other.

I'm very interested to see what happens as we approach release. Specifically, I'm wondering what happens if just one or two developers fall behind and don't finish features on time. How do we get a stable branch down into production? Previously, the unfinished code would be fairly isolated in its own branch and we just wouldn't merge it to the integration branch. Now though, we have to either wall off that code programmatically, or merge around it.

For some more good reading on branching and source control management strategies, see these links:

Martin Fowler - Feature Branch

Paul Hammant - Branch by Abstraction

ACM - Making Sense of Revision-control Systems

Liquidation

This has nothing to do with software, but it's an interesting quote nonetheless. From the CEO of Bluefly.com:

“The most profitable retailers typically have the best final liquidation strategies”

After a bit of thought this makes sense, but it's not a conclusion I would have intuited on my own.